Outsourcing Coordination and Management ofHome Wireless Access Points through an Open API

Ashish Patro

Prof. Suman BanerjeeUniversity of Wisconsin Madison

{patro, suman}@cs.wisc.edu

Outline

• Introduction• COAP Framework• Cooperation Across APs• Learning from prior

Dense residential WLANs today…Apartment Building

Apt 202Apt 201

Access Points WiFi Clients Non-WiFi devices

Dense residential WLANs today…Apartment Building

Apt 202Apt 201

Static Config

High Interference

Non-WiFi

Main observations

• Inefficient spectrum usage due to static configurations– Most APs use a single channel

Main observations

• High WiFi Interference– Average airtime utilization at the neighboring APs

increased upto 70% due to low PHY transmitters– Some links experience hidden terminal

interference from nearby APs

Main observations

• Non-WiFi interference– Non-WiFi devices do not backoff– Result in packet losses due to overlapping

Our Goal: A management framework

Determine the wireless context at its neighboring APs and WiFi channels

Determine the best remedial measure

Our Goal: A management framework

• A vendor-neutral API• A centralized framework • A cloud-based management service• Using Software-Defined approach

How to manage different residential wireless APs from different vendors?

Outline

• Introduction• COAP Framework• Cooperation Across APs• Learning from prior

Coordination framework for Open APs

Apartment Building

AP

AP

COAP Controller

ISP x

ISP yInternet

Last Hop ISPs

Cordless Phone Laptop

Wireless TV

Smartphone

LaptopMicrowave

Oven

Measure

Measure

API

API

Config

Config

COAP framework

COAP framework

Implemented OpenFlow modules

APConfigManager: Receive configuration commands from the controller

DiagnosticStatsReporter: Report detailed wireless statistics to the controller

BasicStatsReporter: Report aggregate wireless statistics to the controller

COAP controller modules

Access Points Controller Wireless OpenFlow

COAP framework implementation

Access Points Controller Wireless OpenFlow

COAP framework implementation

Airshark (IMC 2011)

Packet capturing & parse the packet headers to obtain link level statistics

Non-WiFi device detection capability using commodity WiFi cards

BasicStatsReporter

&DiagnosticStats

Reporter

COAP framework implementation

Access Points Controller Wireless OpenFlow

COAP framework implementation

Access Points Controller Wireless OpenFlow

COAP framework implementation

• Transmit wireless configuration updates from the controller to the APs– switch channel– throttle airtime

AP

Controller

COAP deployment

• 12 OpenWrt based COAP APs– Used as private APs– Use a secondary NIC on the APs to collect airtime

utilization information across all channels in a round robin fashion.

• 30 WiSe APs

WiSe deployment (30 APs)

Building 1: APs 1 – 14Individual Access Point

per apartment

Building 2: APs 25 – 30Deployment in common

areas

Others: APs 15 – 24Across different

homes

Ran deployment over 8 months

Outline

• Introduction• COAP Framework• Cooperation Across APs• Learning from prior

Cooperation across APs - Channel

Controller

Configuration

Administrator

Cooperation across APs - Channel

COAP Controller

Measure MeasureConfiguration

Full view of the spectrum…Can the controller leverage spatio-temporal locality of

nearby APs for better channel selection?

feasibility

feasibility

COAP Controller

Full view of the spectrum…Can the controller leverage spatio-temporal locality of

nearby APs for better channel selection?

CDF of the Pearson’s correlation coefficient for time-seriesper-channel airtime utilization observed by neighboring AP pairs

more than 60% of nearby AP pairs (RSSIs > -55 dBm) exhibited a high correlation coefficient

Performance improvements

It shows that the dynamic "airtime-ware“ scheme performed better than a random channel assignment scheme for 10 out of the 12 APs

Cooperation across APs - Airtime

SetAirtimeAccess( transmit_bitmap, slot_duration)

Channel congestion caused by nearby AP traffic

Hidden terminal style interference

API

Problems

To mitigate these scenarios by controlling the airtime access patterns of the interfering APs

Airtime management - API

Controller divides time

into small "slots"

Enable/disable transmissions of COAP APs on a per-slot

basis

API

Limit a COAP AP’s access to certain slots

Avoid overlapping

Throttle(APx)

Slot( Apx, APy)

Airtime management - API

Testbed evaluation

802.11n based COAP APs

clients

×𝟔

×𝟔

hidden terminal client-side interference

channel congestion experienced by APs

Two scenarios

Testbed evaluation

802.11n based COAP APs

clients

3 links consisted of HTTP based video traffic

3 links using iperf traffic

6 links

TCP throughput Metrics?MAC loss rates Frame drop rate

Hidden terminal scenario

×𝟑10 Mbps HD video

×𝟑10 Mbps traffic

802.11 DCF Slot(APx,APy)VS

Hidden terminal scenario

DCF scenario: all three video flows experienced high MAC layer losses

Slot scenario: throughput improved of all video links

Mitigating channel congestion

10 Mbps 5 Mbps5 Mbps

DCF scenario: the high bitrate video link experienced high frame drop rates

3 links consisted of HTTP based video traffic

3 links using iperf

traffic

Mitigating channel congestion

10 Mbps 5 Mbps5 Mbps

the performance of high bitrate video link improved due to the higher throughput achieved by the link

3 links consisted of HTTP based video traffic

3 links using iperf

traffic

throttled to 50%

Outline

• Introduction• COAP Framework• Cooperation Across APs• Learning from prior

Learning to predict

COAP Controller

Prior wireless activity

logs

learning "context-related"

information

Predicting future non-WiFi activity

Predict traffic characteristics

Modeling non-WiFi activity

Airshark

activity vector

Each element (ci) in the vector records the average number of daily instances of non-WiFi activity observed during a time "bin period"

Modeling non-WiFi activity

"Activity vectors" for microwave oven activity observedby three different COAP APs (2 weeks).

Predicting non-WiFi activity

• For a given time span of k days, using per-AP activity data (total of d days), we obtained a sequence of activity vectors ( e.g., k = 30)

• Computed the per-AP Pearson’s correlation coefficient between consecutive activity vectors and averaged them

Predicting non-WiFi activity

• For a given time span of k days, using per-AP activity data (total of d days), we obtained a sequence of activity vectors ( e.g., k = 30)

• Computed the per-AP Pearson’s correlation coefficient between consecutive activity vectors and averaged them

Used these sequences of activity vectors to determine the predictability of future non-WiFi activity based on

the most recent record of non-WiFi activity

Learning client and traffic context

• Bias in traffic usage profile by device type• Impact of device usage characteristics• Platform specific traffic behavior

Client and traffic context information can be helpful

Learning client and traffic context

Burst properties

Session properties

consecutive active periods with a gap less than 10

seconds

a sequence of consecutive traffic bursts with a gap of

less than 5 minutes

duration, downloaded bytes, the average and maximum download speed

gaps, duration, bytes downloaded and download speeds

Predicting traffic characteristics

COAP AP context a collection of the following traffic and device related features

AP ID, client device id, trafficsource id, time of day, day of week

Machine learning tool, Weka …

predict the burst and session related properties

compared with non-context predict

Predicting traffic characteristics

Q & AThank you!