Outsourcing Coordination and Management of Home Wireless Access Points through an Open API Ashish Patro Prof. Suman Banerjee University of Wisconsin Madison {patro,

Outline Introduction COAP Framework Cooperation Across APs Learning from prior

Dense residential WLANs today… Apartment Building Apt 202 Apt 201 Access PointsWiFi Clients Non-WiFi devices

Dense residential WLANs today… Apartment Building Apt 202 Apt 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 COAP Controller ISP x ISP y Internet Last Hop ISPs Cordless Phone Laptop Wireless TV Smartphone Laptop Microwave Oven Measure API Config 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 BasicStats Reporter & 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 – 14 Individual Access Point per apartment Building 1: APs 1 – 14 Individual Access Point per apartment Building 2: APs 25 – 30 Deployment in common areas Building 2: APs 25 – 30 Deployment in common areas Others: APs 15 – 24 Across different homes Others: APs 15 – 24 Across 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 Configuration

Full view of the spectrum… Can the controller leverage spatio-temporal locality of nearby APs for better channel selection? 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-series per-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_b itmap, 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 n based COAP APs clients hidden terminal client-side interference channel congestion experienced by APs Two scenarios

Testbed evaluation n 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 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 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 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 observed by 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, traffic source id, time of day, day of week AP ID, client device id, traffic source 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 & A Thank you!