Toward Open and Programmable Infrastructure for Smarter Wireless Network PhD Thesis Proposal by Mostafa Uddin Old Dominion University

1. Toward Open and Programmable
Infrastructure
for Smarter Wireless Network
Mostafa Uddin
Advisor: Dr. Tamer Nadeem
4/2/15

2. 2
80% of Enterprise Apps
are Deployed in the
Cloud
Smart devices reach
30% of the global
population by 2013, it is
expected to grow 60%
by 2019
We have been seeing tons of
innovation in applications,
devices, computing and storage,
Growth of Network Usage
Unending, exponential growth in the people, devices and servers connecting
to the network requires a new approach
Data Center Enterprise Network

3. 3
Rapid growth of mobile data traffic
Higher Volume of
Wireless Traffic
Large Number of
Mobile devices

4. 4
Better Visibility and Control
Wireless Traffic
+
Wide verity of traffic
Provide optimal performance and high
quality of experience (QoE) to the end-user

5. 5
Wireless Network Services
Air-time resource
management
Interference
Management
Mobility
management
Managing multiple
wireless technology

6. 6
Pushing SDN to Network Edge
Internet
SDN Controller
Extend standard SDN framework to the end-devices. Provide extensible
and programmable abstraction of the wireless network.
weSDN
+
Shared medium
Control + Manage

7. 7
Contribution

Extend SDN framework all the way to the end-
devices (i.e., mobile devices, APs)

Create open modules and APIs to provide
extensible and programmable abstraction of the
wireless network.

Create new services based on the extension of the
SDN framework
– Application-awareness networking, WLAN
virtualization, Security at network edge, Mobility
management.

8. 8
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services.

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

9. 9
SDN Background: Data Plane and
Control Plane

Data Plane:
→ Fwding state + Packet header → forwarding
decision
→ Fast(nano-scale) and local.

Control Plane:
→ Compute the forwarding state for the data plane.
→ Routing, Isolation, Traffic engineering.

Control Plane mess is the root cause of
SDN.

10. 10
SDN Background: Traditional Network
and SDN
Network OS
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet Forwarding
Packet
Global Network View
Dijkstra IS-IS New!
Customized Hardware
Customized Network
OS
Dijkstra
Distributed
system
IS-IS
Distributed
system Open Interface to
Packet forwarding
(OpenFlow protocol)

11. 11
SDN Background: Traditional Network
and SDN
Network OS
Forwarding
Packet
Forwarding
Packet
Forwarding
Packet Forwarding
Packet
Global Network View
Dijkstra IS-IS New!
Customized Hardware
Customized Network
OS
Dijkstra
Distributed
system
IS-IS
Distributed
system Open Interface to
Packet forwarding
(OpenFlow protocol)

12. 12
SDN Background: Decoupling is the
solution

13. 13
SDN Background: SDN Architecture
Control Plane (SDN Controller)
Application plane ( Routing , Access
Control etc.)
Southbound-API (e.g.,
openFlow protocol)
Data Plane
Northbound-API (e.g.,
Network topology)
OpenFlow
switch

14. 14
SDN Background: OpenFlow
OpenFlow Switch (i.e., OVS)
OpenFlow
Protocol
(SSL/TCP)

15. 15
SDN Background: Flow Table

16. 16
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

17. 17
Related Work: SDN in Cellular
WHY?WHY?
John Donovan (Senior executive VP of AT&T) says
“75% of network will be SDN by 2020.”

18. 18
Related Work: Objectives in Cellular
Efficiently and
seamlessly
Mobility handling
Adding new services
Easily,
Fast, inexpensive
Real-time updates of
fine-grained packet-
handling
Different subscriber
3G, LTE, Wi-Fi, Femtocell

19. 19
Related Work on Cellular SDN: SoftCell
Internet
No change
Controller
Commodity
hardware
+ SoftCell
software
No change
Scalable Support of Fine-Grained Service Policies

20. 20
Related Work on Cellular SDN: OpenRadio
Wireless Network OS
Global Network View
Open interface to heterogeneous
wireless infrastructure
Connectivity/Mobility Netflix/CDN
If pkt = x: forward to WiFI AP
If pkt = y: forward to LTE AP
and allocate speed
1Mbps
If pkt = x: schedule low priority
If pkt = y: schedule high
priority and allocate 40%
airtime
3G Wi-Fi
LTE

21. 21
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

22. 22
Related Work: SDN in Wi-Fi

Centralized solution of WLAN from industries (e.g.
Cisco Aruba, Meru)
– Channel Allocation, Radio resource management,
interference reduction, authentication
Closed and Proprietary
Ajay Malik (Senior VP of Aruba) says
“Wireless network must truly embrace
open standards for enterprises to reap the
performance benefits of Software-Define
Networking”

23. 23
Related work on Wi-Fi SDN: Odin
Complex for traffic
management, apply policies
and create new service
Do not use OpenFlow
Don't have fine-grained
Control over traffic
SWAN, similar work as Odin
Maintain a virtual AP for each client device

24. 24
Related work on Wi-Fi SDN: Dyson
Clients and APs uses open APIs to
send pertinent information such as
radio channel conditions to a central
controller.
Controller create global view of the
network.
The global view and historical
information allow the controller to
apply policies.
Not flexible and general as SDN
Only works on MAC layer
Services:
Associations, handling VoIP clients, reserving
airtime for specific users, and optimizing
handoffs for mobile clients
Can not have fine-grained
Real-time traffic managemnt

25. 25
Related work on Wi-Fi SDN: COAP
A cloud-based centralized framework to configure,
coordinate and manage individual home APs using
an open API implemented by these commodity APs.
Can not have fine-grained
Real-time traffic managemnt Control Plane is not flexible

26. 26
Summary of the related work

No generalized framework, only targeting to solve
specific problem using SDN concept.

No extension on the OpenFlow, for supporting the
wireless network devices.

No intension of bringing the client devices under the
control of SDN framework.

Not providing any new NB-APIs for the
development of third-party network applications.

27. 27
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

28. 28
weSDN: Overview
Extends control capability all the
way to end device
1. In OpenFlow ext., we extended
the standard OpenFlow to provide
new APIs for wireless network.
2. In OpenFlow protocol ext., we
extend the OpenFlow protocol to
support new statistics and
action/configuration cmd for
wireless.
3. In client devices, we use Local
Controller to reduce in-band
communication between Client
device and weSDN controller.
4. Extend the NB-API to provide
wireless network topology
including client devices.

29. 29
weSDN: Architecture
OpenFlow extension components of the AP and Client devices

30. 30
weSDN: Flow Manager
FlowManger is a Software OpenFlow Switch with extension for wireless
1. Collect traffic flow statistics
2. Ensure correct QoS marking.
3. Collect per-client or per-flow
wireless statistics such as RSSI,
data rate, TX mode and drop
count.

31. 31
weSDN: Scheduler
Scheduler is Linux Qdisc with the capability of starts/stops
dequeueing of the outgoing flow based on the airtime schedule.
1. Starts or stops dequeueing of
the outgoing flow based on the
airtime schedule.
2. Interact with the wireless
driver to control the dequeueing
event based on the number of
packets exists in the driver
buffer.

32. 32
weSDN: Local Controller
Local Controller is a user space software that interact with the
Flow Manager, Scheduler, and Linux wireless driver.
1.Provides application-awareness and
generates flow-to-application
mappings.
2.We extend the OVS APIs (i.e.
netlink APIs) so that local controller
can read per-flow wireless stats from
the flow manager.
3. The local controller inserts
a flow rule corresponding to each
socket into OVS.
4. Interact with wireless driver
(weSDN ext.) to configure power-
save settings, transmission
(TX) rate, TX power.

33. 33
weSDN: SDN Controller
The interaction between wireless AP and the SDN control plane happens through
OpenFlow protocol ext. over out-band wired control channel
The interaction between weSDN controller and the Local Controller happens over
In-band wireless control channel
1. Provide per-application
policies and QoS profile.
2. Local controller aggregate
running application resource
and QoS requirement to the
weSDN controller.
3. weSDN controller provide
proper action to the Local
controller for resource
management

34. 34
weSDN: Features of the Framework

Cohesive framework in managing both wire and
wireless network.

Real-time, fine-grained control over the wireless
resource management.

Ensure end-to-end QoS policy.

Enhance the guaranteed network performances of
the client devices.

35. 35
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

36. 36
weSDN Services: WLAN Virtualization
WLAN virtualization enable effective sharing of wireless
resources by a diverse set of users with diverse requirement
employees
guest
Enterprise WLAN
parents kids
Home WLAN
weSDN provide virtualization capability through controlling
both uplink and downlink wireless resource

37. 37
weSDN Services:Application-Awareness
Networking
application type +flow type → middleboxes (QoS, Policy,
Resource Management)
weSDN Control Plane
App-awareness
weSDN use the OpenFlow ext. to collect real-time traffic flow features and
identify the flow types.
QoS Policy
Various mobile applications with
various traffic types (e.g Skype,
Facebook)

38. 38
weSDN Services: Securing Network Edge
weSDN framework provide transparent and configuration technique
of securing the wireless traffic between the mobile and the AP.
weSDN Control Plane
Security App
Securing
Unencrypted
traffic
Obfuscating
Eavesdropping
Sensitive apps
(e.g. Health app)

39. 39
weSDN Services: Multiple Network
Interfaces
Require a Dynamic and
Programmable system to
leverage all network
interfaces
TCP/IP
OVS
WiFi LTE
vp
Wi-fi Driver
WiFi firmware
LTE Driver
LTE firmware
qdisc
Local Controller
Flow Manager
In client devices, Flow
Manager with local
controller can provide to use
multiple network interfaces

40. 40
weSDN Services:
Mobile ↔ SDN ↔ Cloud
In wireless, network condition between
Mobile (Client) ↔ SDN (network) are highly dynamic
Mobile cloud application require guaranteed network
Performance.
SDN controller need to provide performance guarantee
to clients knowing the app demand from the cloud
server.

41. 41
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

42. 42
pTDMA: WLAN Virtualization
#42
Now-a-days People bring their own devices in the
workplaces (i.e., BYOD)

Require new WLAN management and BYOD Policies
• pTDMA is a simple prototype of weSDN for WLAN
virtualization service.
– Manage airtime share between network instances (their clients) that
collocate in space and channel.
– Assigning separate airtime slices among different network instances.
WLAN Virtualization is a popular solution
in enterprise for BYOD concept

43. 43
pTDMA: Scheduling
43

Allocate large enough time window to transmit and receive
multiple packets.

Schedule multiple clients in a common slot to maximize
channel utilization.

The interval between consecutive time windows should be
based on applications’ traffic pattern & demand.

50:50 airtime share between employee
network and guest network.

Every time window is fixed of 10ms.

44. 44
pTDMA: Implementation

Flow Manager:
– OVS Stat extension: burst duration, burst rate and inter-burst time.

Scheduler:
– Receive time window from the local controller to start/stop dequeueing.
– Time Window: e.g. [Start time, active duration, sleep duration]
(e.g. 05:30:30, 10ms, 30ms)

Local Controller:
– Identify flows correspond to each application.
– Read per-flow statistics from Flow Manager.
– Control the scheduler.

Global Controller:
– provide per-slice, per-user, per-application policies and QoS profiles.
– Collect 'aggregated' airtime demand of the running applications and
QoS requirements.
– Apply proper action back to the local controller(e.g. Scheduling )
#44

45. 45
pTDMA: Experiment
#45
We formed two network slices
“employee” network with 2 devices
“guest” network with 6 devices
Applied following pTDMA
schedule with 50:50 airtime share
between two slices
– 3:1 airtime ratio btw an employee and a
guest.
(but all devices are connected to one AP)
E1
E2
G2
G3
G4
G5
G6
E1
E2
E1
E2
E1
E2
G1
G2
G3
G4
G5
G6 ....
0ms 10 20 30 40 50 60
G1
~3x In non-pTDMA, client sleeps 28% of
the time.
In pTDMA, client sleeps 80% of the
time

46. 46
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

47. 47
TrafficVision: Application-awareness
Dynamic Port Number
SDN Control Plane
DPI
Engine
Different Application
and different flow
types
Require different QoS,
Security, and resources
Real-time identifying of
Apps and its various
flow types
Application-awareness
Networking

48. 48
TrafficVision: DPI
SDN Control Plane
DPI
Engine
OpenFlow mirror
packets from data
layer and send to SDN
control plane.
Most applications now use
HTTPs
Application encryption
DPI uses packet signature to detect application
Significant Overhead

49. 49
TrafficVision: SDN solution to
Application-awareness
Real-time and fine-grained “application-awareness” system at Network edge
Wi-Fi/Cellular AP
(extended openflow switch)
weSDN
Controller
Network Service
(TV Engine)
Application
Plane
Traffic
Management App
NB API
ML learning technique
With new features.
Flow type detection accuracy
75-89% to 85-98%

50. 50
TrafficVision: TV Engine
weSDN Controller
Wi-Fi
/ Cellular
OpenFLow
ext.
TV Engine
OpenFlow
protocol ext.
OpenFlow
ext.
Feature collected at network edge: Light traffic Volume
No overhead of packet mirroring (i.e., don not use
packet capture tools).
Real-time features collection.

51. 51
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

52. 52
Proposed Work Plan: weSDN Testbed

Cross-compile and deploy OpenFlow switch in the
Android smartphone and tablets (linux based
platform). [complete]

Run Floodlight SDN controller in a laptop.
[completed].

Cross-compile and deploy OpenWrt including
OpenFlow switch in wireless router (Linksys E3000,
a/b/g/n). [not completed]

53. 53
Proposed Work Plan: Flow Manager
Extend “netdev provide”
And “datapath” for
supporting
Wireless network interfaces
[completed]
Extend the kernel module
“mac80211” and “cfg80211”
To create API for Flow Manager
To collect Statistics.
[not completed]

54. 54
Proposed Work Plan: Local Controller

Use the Traffic Control (tc) tool to control the enqueue/dequeue
action of the scheduler. [completed]

Develop interaction with the SDN controller to get policies,
actions, and QoS settings for the traffic flows. In addition provide
network requirement and traffic statistics to the SDN controller.
[partially completed]

Create new APIs for the mac80211 to allow local controller to
interact and configure the wireless driver. [not completed]

Make the local controller interact with the wireless configuration
tools such wpa supplicant, iw. [not completed]

55. 55
Proposed Work Plan: Scheduler

Extend the scheduler to interact with the wireless driver to
control the dequeue event based on the number packets in the
driver buffer. [partially complete]

Implement the Linux multiq qdisc as a basis of the scheduler to
support the four 802.11 QoS queues in the driver while
preventing head-of-line blocking. [completed]

Provide APIs to the local controller for configuring the qdisc and
wireless driver. [completed]

56. 56
Proposed Work Plan: SDN Controller
(Floodlight)

Extend the Northbound API to have new APIs for controlling and
programming wireless APs and client devices. [not complete]

Extend OpenFlow protocol to collect wireless channel statistics per-
device from wireless APs. [completed]

57. 57
Outline

SDN Background

Related Work

SDN in Cellular

SDN in WiFi

weSDN: Wireless Extension of SDN

weSDN services

pTDMA: WLAN Virtualization

TrafficVision: Application-awareness networking

Proposed work plan

weSDN Framework

weSDN Services

58. 58
Proposed Work Plan: TrafficVision
1. Evaluate and compare our system with OpenDPI,
which is a open source DPI based solution for detecting
the applications from the packet’s signature.
2. Develop and evaluate a traffic load-balancing or traffic
management application that uses our TrafficVision
system.

59. 59
Proposed Work Plan: Security at
Network Edge
weSDN Control Plane
Security App
Securing
Unencrypted
traffic
Obfuscating
1. Leveraging the weSDN
framework to apply security policy
on the sensitive app's traffic.
2. Real-time detection of
unencrypted traffic from sensitive
apps and apply IPsec tunneling
between AP and client device
using Flow Manager.
3. Transparently apply traffic
obfuscating or traffic shaping
technique to hide the side-channel
information of the apps..

60. 60
Proposed Work Plan: Multiple Wireless
Interfaces
TCP/IP
OVS
WiFi LTE
vp
Wi-fi Driver
WiFi firmware
LTE Driver
LTE firmware
qdisc
Local Controller
Flow Manager
1. Monitor Wireless channel status
in real-time by the local controller.
2. Develop an algorithm in the
local controller on utilizing
different wireless interfaces, based
on running apps requirement.
3. Evaluate the system using real-
world application based on users'
QoE.
qdisc

61. 61
Proposed Work Plan: Network
Diagnosis at end-devices
1. The OpenFlow has very extensible and programmable
way of logging events of packet handling and network
activity.
2. We plan to extend the OpenFlow logging system to log
wireless network activity.
3. Thus, based on the logging messages, we plan to build a
network diagnosis system for the end-devices.

62. 62
Timeline
Task Task Status Expected Schedule
WeSDN testbed Completed (75%) Spring'15
WeSDN implementation Completed (80%) Spring'15 -Summer'15
TrafficVision Completed(90%) Spring'15-Summer'15
Security App Not Completed Fall'15
Mobility Management Not Completed Spring'16
Thesis Writing Not Completed Spring'16-Summer'16

63. 63
Publication List
1. Mostafa Uddin, Ahmed Salem, Ilho Nam, and Tamer Nadeem, ”Wearable Sensing Framework
for Human Activity Monitoring.” ACM WearSys, MobiSys 2015.
2. Mostafa Uddin, and Tamer Nadeem, ”Harmony: Content Resolution using Acoustic Channel.”
IEEE INFOCOM 2015.
3. Jeongkeun Lee, Mostafa Uddin, JeanTourrilhes, Souvik Sen, Sujata Banerjee, Manfred
Arndt, Kyu-Han Kim, Tamer Nadeem, ”meSDN: mobile extension of SDN.” ACM MCS
2014.
4. Mostafa Uddin, and Tamer Nadeem, ”SpyLoc: A Light Weight Localization System for
Smartphones.” IEEE SECON 2014.
5. Mostafa Uddin, Ajay Gupta, Kurt Maly, Tamer Nadeem, Sandip Godambe, Arno Zaritsky,
”SmartSpaghetti: Accurate and Robust Tracking of Human’s Location.” IEEE-EMBS
International Conferences on Biomedical and Health Informatics, 2014.
Papers

64. 64
Publication List (Cont.)
6. Mostafa Uddin, Ajay Gupta, Kurt Maly, Tamer Nadeem, Sandip Godambe, Arno Zaritsky,
” SmartSpaghetti: Use of Smart Devices to Solve Health Care Problems.” International
Workshop on Biomedical and Health Informatics, 2013.
7. Mostafa Uddin, and Tamer Nadeem, ”RF-Beep: A light ranging scheme for smart devices.”
IEEE PerCom 2013.
8. Mostafa Uddin, and Tamer Nadeem, ”A2PSM: Audio AssistedWi-Fi Power Saving Mechanism
for Smart Devices.” ACM HotMobile 2013.
9. Mostafa Uddin, and Tamer Nadeem, ”MagnoTricorder: What You Need To Do Before
Leaving Home.” ACM HomeSys, UbiComp 2012.
10. Mostafa Uddin, and Tamer Nadeem, ”EnergySniffer: Home Energy Monitoring System
using Smart Phones.” IEEE IWCMC, 2012.
Papers

65. 65
Publication List (Cont.)
1. Igor Pernek, Mostafa Uddin and Jack Fernando Bravo Torres, ”Report of HotMobile
2012” IEEE Pervasive Computing.
2. Mostafa Uddin and Tamer Nadeem, ”HotMobile 2012 Poster: MachineSense: Detecting
and Monitoring Active Machines using Smart Phone.” ACM SIGMOBILE MC2R.
3. Mostafa Uddin and Tamer Nadeem, ”HotMobile 2012 Poster: Audio-WiFi: Audio Channel
Assisted WiFi Network for Smart Phones.” ACM SIGMOBILE MC2R.
ArticlesArticles

66. 66
Publication List (Cont.)
1. Mostafa Uddin, Ashish Kshirsagar, and Tamer Nadeem, ”SafeWLAN: A WLAN-based
SDN Approach for Securing WLAN Traffic.” ACM HotMobile 2015.
2. Mostafa Uddin and Tamer Nadeem, ”SpyLoc: a Light Weight Localization System for
Smartphones.” In Proceedings of MobiCom’13.
3. Jeongkeun Lee, Mostafa Uddin, Jean Tourrilhes, Souvik Sen, Sujata Banerjee,Manfred
Arndt, Tamer Nadeem, ”Extending SDN for mobile device.” ACM HotMobile, 2014 .
4. Mostafa Uddin and Tamer Nadeem, ”Audio-WiFi: Audio Channel AssistedWiFi Network
for Smart Phones.” IEEE INFOCOM, 2012 .
5. Mostafa Uddin and Tamer Nadeem, ”EnergySniffer: Home Energy Monitoring System
using Smart Phones.” IEEE INFOCOM, 2012 .
6. Mostafa Uddin and Tamer Nadeem, ”MachineSense: Detecting and Monitoring Active
Machines using Smart Phones.” ACM HotMobile, 2012 .
Posters/Demos

67. 67
Timeline
Task Task Status Expected Schedule
WeSDN testbed Completed (75%) Spring'15
WeSDN implementation Completed (80%) Spring'15 -Summer'15
TrafficVision Completed(90%) Spring'15-Summer'15
Security App Not Completed Fall'15
Mobility Management Not Completed Spring'16
Thesis Writing Not Completed Spring'16-Summer'16
Thank You

68. 68
Back-up Slides

69. SDN enable AP
Replace with openflow
switch(OVS)

70. pTDMA: Downlink Control and Power
Saving
#70
1. pTDMA leverage WMM-PS to indirectly confine the downlink traffic to
the time window.
2. pTDMA allows to efficiently utilize the WMM-PS to have more sleeping
time without sacrificing the throughput performance.
WMM Power Save in a Wi-Fi Network Wi-Fi legacy power save

71. TVEngine: TrafficVision Control
Layer
Core Idea:
Classify network traffic based on flow statistics, not on the payload content
Three major task:
1) Collect and store flow statistics of packet sizes and packet arrival time from OVS.
2) Extract high order statistics and spatio-temporal features.
3) Apply ML classifier to identify application and flow type.