Towards Software-Defined Wireless Networks Network Infrastructures Tommaso Melodia E-mail: tmelodia@eng.buffalo.edu Based on Slides from Ian Akyildiz, Sachin Katti, Jennifer Rexford and Li Erran Li 1 Outline CellSDN: Towards Software Defined Cellular Networks OpenRadio: Taking Control of Wireless SoftRAN: Software Defined Radio Access Networks 2 1
Towards Software Defined Cellular Networks 3 Outline Critiques of LTE Architecture CellSDN Use Cases CellSDN Architecture Related Work Conclusion and Future Work 4 2
LTE Data plane is too centralized Data plane is too centralized enodeb 1 Cellular Core Network enodeb 2 S-GW 1 UE 1 UE: user equipment enodeb: base station S-GW: serving gateway P-GW: packet data network gateway 5 UE 2 enodeb 3 S-GW 2 P-GW Internet and Other IP Networks GTP Tunnels Scalability challenges at P-GW on charging and policy enforcement! LTE Control plane is too distributed No clear separation of control plane and data plane Control Plane Data Plane Mobility Management Entity (MME) Home Subscriber Server (HSS) Policy Control and Charging Rules Function (PCRF) Problem with Intertechnology (e.g. 3G to LTE) handoff Problem of inefficient radio resource allocation User Equipment (UE) 6 Base Serving Packet Data Network Station Gateway Gateway (enodeb) (S-GW) (P-GW) 6 3
Advantages of SDN for Cellular Networks Advantage of logically centralized control plane Flexible support of middleboxes Better inter-cell interference management Scalable distributed enforcement of QoS and firewall policies in data plane Flexible support of virtual operators by partitioning flow space Advantage of common control protocol Seamless subscriber mobility across technologies Advantage of SDN switch Traffic counters enable easy monitoring for network control and billing 7 Flexible Middlebox Support SDN provides fine grained packet classification and flexible routing enodeb 1 Easy to control flow to middleboxes for content adaptation, echo cancellation, etc Reduce traffic to middleboxes enodeb 2 Middlebox UE 1 UE 2 enodeb 3 SDN Switch Internet and Other IP Networks 8 Path setup for UE by SDN controller 4
Flexible Middlebox Support (Cont d) SDN switch can support some middlebox functionality enodeb 1 enodeb 2 Easy to satisfy policy for traffic not leaving cellular network Reduce the need for extra devices UE 1 UE 2 enodeb 3 SDN Switch Internet and Other IP Networks Path setup for UE by SDN controller 9 Monitoring for Network Control & Billing Packet handling rules in SDN switches can efficiently monitor traffic at different level of granularity Enable real time control and billing Rule Action Stats Packet + byte counters 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline 10 10 Switch Port + mask MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP TCP sport dport 10 5
Seamless Subscriber Mobility UE 1 enodeb 1 enodeb 2 SDN Control Plane X+1-Gen Cellular Network X-Gen Cellular Network SDN provides a common control protocol that works across different cellular technologies Forwarding rules can be pushed to switches in parallel UE 2 enodeb 3 Path setup for UE by SDN controller SDN Switch Internet and Other IP Networks 11 11 Distributed QoS and ACL Enforcement enodeb 1 LTE s PCEF is centralized at P- GW which is Access policy checked inflexible In SDN switches distributedly enodeb 2 UE 1 UE 2 enodeb 3 Path setup for UE by SDN controller SDN Switch Internet and Other IP Networks 12 12 12 6
Virtual Operators Flexible network virtualization by slicing flow space VO 1 enodeb 2 enodeb 1 Virtual Operator(VO) (Slice 1) Slicing Layer: CellVisor Virtual Operator (Slice N) Virtual operators may want to innovate in mobility, billing, charging, radio access UE 1 VO 2 UE 2 enodeb 3 SDN Switch Internet and Other IP Networks 13 13 13 Inter-Cell Interference Management Central base station control: better interference management enodeb 2 enodeb 1 Radio Resource Manager Global view and more computing power Network Operating System: CellOS LTE distributed interference management is suboptimal UE 1 UE 2 enodeb 3 SDN Switch Internet and Other IP Networks 14 14 14 7
CellSDN Architecture CellSDN provides scalable, fine-grain real time control with extensions: Controller: fine-grain policies on subscriber attributes Switch software: local control agents to improve control plane scalability Switch hardware: fine-grain packet processing to support DPI Base stations: remote control and virtualization to enable flexible real time radio resource management 15 15 CellSDN Architecture (Cont d) Central control of radio resource allocation Radio Resource Manager Mobility Manager Subscriber Information Base Policy and Charging Rule Function Network Operating System: CellOS Infrastructure Routing Translates policies on subscriber attributes to rules on packet header SCTP instead of TCP to avoid head of line blocking Cell Agent Cell Agent Cell Agent Offloading controller actions, e.g. change priority if counter exceed threshold Radio Hardware Packet Forwarding Hardware Packet Forwarding Hardware DPI to packet classification based on application 16 16 8
CellSDN Virtualization Network OS (Slice 1) Network OS (Slice 2) Slicing Layer: CellVisor Network OS (Slice N) Slice semantic space, e.g. all roaming subscribers, all iphone users Cell Agent Cell Agent Cell Agent Radio Hardware Packet Forwarding Hardware Packet Forwarding Hardware 17 17 Related Work Stanford OpenRoad Introduced openflow, FlowVisor, SNMPVisor to wireless networks Stanford OpenRadio Programmable cellular data plane NEC base station virtualization Slicing radio resources at the MAC layer Ericsson CloudEPC Modify LTE control plane to control openflow switches 18 18 9
Conclusions CellSDN advantages: Simple and easy to manage Simple and easy to introduce new services Easy to inter-operate with other wireless technologies Future work: detailed CellSDN design 19 19 OpenRadio: Taking Control of Wireless 20 20 10
Three Dissatisfied Parties Applications Carriers Users 21 21 Frustrated Users 22 22 11
LTE Femtocell 3G WiFi Paradoxically, surrounded by wireless APs (WiFi, 3G, 4G, picocells, femtocells, whitespace.) 23 23 LTE Femtocell 3G WiFi Why can t I seamlessly connect to the best AP available? 24 24 12
Femtocell 3G WiFi LTE Why can t I seamlessly connect to multiple APs if I want more speed? 25 25 Applications Perspective 26 26 13
LTE Femtocell 3G WiFi User experience with rich cloud services over mobile wireless is poor 27 27 LTE Femtocell 3G WiFi To cope, resort to reverse engineering Probe for bandwidth/latency Resort to hacks (e.g. multiple TCP connections, ) 28 28 14
LTE Femtocell 3G WiFi Why can t applications directly ask the network its current state, or directly request the connectivity they need? 29 29 LTE Femtocell 3G WiFi More generally, why isn't the network a partners for apps rather than an opaque bit pipe? Network knows user location, connectivity, billing. Well positioned to host & enhance applications 30 30 15
Carrier s Perspective 31 31 Carrier s Dilemma 350000 8 300000 250000 200000 150000 6 4 Shannon Shannon (3dB) 4G 100000 50000 0 2010 2011 2012 2013 2014 2015 2 0-15 -10-2,5 2,5 7,5 12,5 17,5 32 32 16
Cooper s Law PHY Improvements Increasing Spectrum Shrinking Cell Sizes Capacity Improvements come from increasing cell density 33 33 Capacity Dense/Chaotic Deployments Dense Higher SNR/user Higher Capacity Femtocells, dense Wi-Fi deployments, etc. 34 34 17
Dense & Chaotic Hard to Manage Limited spectrum + Dense Intercell Interference Many, chaotic cells Variable Load & Backhaul Operators need to dynamically manage how their traffic is routed, scheduled and encoded on a per packet level to manage inter-cell interference & variable load in a chaotic infrastructure Hard to build at scale 35 35 Everyone is Dissatisfied! Underlying Cause: Lack of control Infrastructure does not scalably expose state Hard or infeasible to find available APs, their speeds, user locations, fine-grained network/load information etc Infrastructure does not provide granular control Hard or infeasible to granularly control traffic E2E across all layers and network infrastructure 36 36 18
What does it take to.. Open the wireless infrastructure to provide users, applications and carriers control over their traffic across all layers end to end across the entire infrastructure? 37 37 OpenRadio: Taking Control of Wireless Wireless network architecture that provides unified software interfaces to: 1. Query wireless networks about availability, quality, location, spectrum, interference 2. Control granularly how individual user or application traffic is handled by the network across the entire stack 38 38 19
OpenRadio: Control Interface Match/Action interface for the entire stack Match: Identify and tag flows of individual users and/or applications Action: Control how packets are routed, what speeds & priorities they get, and how they are scheduled/encoded at the AP 39 39 OpenRadio: Architecture Control Program Control Program Global Network View Wireless Network OS Open interface to heterogeneous wireless infrastructure X X If pkt = x: forward to LTE AP If pkt = y: forward to LTE AP and allocate speed 1Mbps 40 40 3G WiFi AP LTE If pkt = x: schedule low priority If pkt = y: schedule high priority and allocate 40% airtime 20
E.g: Seamless Connectivity to the best APs Connectivity/Mobility Control Program Global Network View Wireless Network OS X X LTE 3G WiFi AP Control program to automatically route user traffic to the best available AP 41 41 E.g: Dynamic High Speed Pipe for Video Connectivity/Mobility Netflix/CDN Global Network View Wireless Network OS X X 3G WiFI AP Applications stitch a high speed pipe from available APs for HD video streams LTE 42 42 21
Connectivity CDN Load Mgmt Internet of Things Global Network View Wireless Network OS X X 3G WiFI AP Complex network services as pieces of software running on the network OS LTE 43 43 OpenRadio: Design Data Plane: Access, backhaul & core network Can we build a programmable data plane using merchant silicon? Control Plane: Modular software abstractions for building complex network applications What are the right abstractions for wireless? 44 44 22
OpenRadio: Radio Access Dataplane 45 45 OpenRadio: Access Dataplane OpenRadio APs built with merchant DSP & ARM silicon Single platform capable of LTE, 3G, WiMax, WiFi OpenFlow for Layer 3 Inexpensive ($300-500) Forwarding Dataplane Control CPU Baseband & Layer 2 DSP Exposes a match/action interface to program how a flow is forwarded, scheduled & encoded RF RF RF 46 46 23
Design Goals and Challenges Programmable wireless dataplane using off-the-shelf components At least 40MHz OFDM-complexity performance More than 200 GLOPS computation Strict processing deadlines, eg. 25us ACK in WiFi Modularity to provide ease of programmability Only modify affected components, reuse the rest Hide hardware details and stitching of modules 47 47 47 Wireless Basebands OFDM Demod OFDM Demod OFDM Demod Demap (BPSK) Demap (BPSK) Demap (64QAM) Demap (BPSK) Demap (64QAM) Deinterleave Deinterleave Deinterleave (WiFi) Deinterleave (UEP) Viterbi Decode Descramble CRC Check Hdr Parse Decode (1/2) Descramble CRC Check Hdr Parse Decode (3/4) Decode (1/2) Descramble CRC Check Hdr Parse Decode (3/4) Descramble Hdr Parse WiFi 6mbps WiFi 6, 54mbps WiFi 6, 18mbps and UEP 48 48 24
Modular declarative interface A 49 49 Composing ACTIONS A B D F H I J Demap (64QAM) Demap (BPSK) OFDM Demod B C E D Deinterleave (UEP) Deinterleave (WiFi) F Blocks A D H C G G H I Decode (3/4) Decode (1/2) J CRC Check Descramble Hdr Parse I I 6M J 54M J J A H Actions: DAGs of blocks F C E G H Inserting RULES A B D F H I J 6M A B D F H I J C G 6M, 54M Rules: Branching logic Data flow Control flow State machines and deadlines Rules and actions encode the protocol state machine Rules define state transitions Each state has an associated action Deadlines are expressed on state sequences Start decoding B F Finish decoding A D H I C G J 50 50 deadline 50 25
Design principle I - Judiciously scoping flexibility Provide just enough flexibility Keep blocks coarse Higher level of abstraction High performance through hardware acceleration Viterbi co-processor FFT co-processor Off-the-shelf heterogeneous multicore DSPs TI, CEVA, Freescale etc. Algorithm WiFi LTE 3G DVB-T FIR / IIR Correlation Spreading FFT Channel Estimation QAM Mapping Interleaving Convolution Coding Turbo Coding Randomization CRC 51 51 51 A Design principle II - Processing-Decision Separation Logic pulled out to decision plane Blocks and actions are branch-free Deterministic execution times Efficient pipelining, algorithmic scheduling Hardware is abstracted out Regular compilation Instructions Heterogeneous functional units OpenRadio scheduling Atomic processing blocks Heterogeneous cores B D A C F G H I J 6M, 54M Known cycle counts Argument data dependency Predictable cycle counts FIFO queue data dependency C B D 60x E 52 52 52 F 26
Prototype I/Q baseband samples RF signal (Digital) (Analog) Baseband-processor unit (BBU) Layer 1 & 2 Radio front end (RFE) Layer 0 & 1 Antenna chain(ax) Layer 0 COTS TI KeyStone multicore DSP platform (EVM6618, two chips with 4 cores each at 1.2GHz, configurable hardware accelerators for FFT, Viterbi, Turbo) Prototype can process 40MHz, 108Mbps 802.11g on one chip using 3 of 4 cores 53 53 53 Software architecture BBU RFE AX (Digital) (Analog) 54 54 data in monitor & control data out OR Wireless Decision Plane protocol state machine, flowgraph composition, block configurations, knowledge plane, RFE control logic OR Wireless Processing Plane deterministic signal processing blocks, header parsing, channel resource scheduling, multicore fifo queues, sample I/O blocks Bare-metal with drivers OR Runtime System compute resource scheduling, deterministic execution ensuring protocol deadlines are met 27
OpenRadio: Current Status OpenRadio APs with full WiFi/LTE software on TI C66x DSP silicon OpenRadio commodity WiFi APs with a firmware upgrade Network OS under development 55 55 To Conclude OpenRadio: Taking control of wireless through SDN Provides programmatic interfaces to monitor and program wireless networks High performance substrate using merchant silicon Complex network services as software apps 56 56 28
SoftRAN : Software Defined RAN Aditya Gudipati, Daniel Perry, Li Erran Li *, Sachin Katti 57 57 LTE - Radio Access Network Client1 Client2 BS1 BS2 S-Gateway 1 P-Gateway I N T E R N E T Client3 BS3 S-Gateway 2 Core Network Client4 Radio Access Network High Capacity, Uniform Coverage Wide-Area Wireless Network 58 58 29
RAN Actions: Radio Resource Management 1. Assign each client to a base station Flow 1 Flow 2 db time time db db db db frequency 2. Assign resource blocks (timefrequency slots) to each flow frequency 3. Assign transmit powers to be used for each resource block 59 59 RAN Challenges Increasing demand on wireless resources Dense deployments of small cells Radio Resource Management gets coupled across base stations 60 60 30
Coupled Radio Resource Management: Interference Power used by BS1 affects interference at Client 2 Interference at Client 2 affects power reqd. at BS2 BS1 BS2 Client1 Client2 61 61 Coupled Radio Resource Management: Mobility Dense deployments Higher frequency of handovers More candidate base stations Coordinating handovers critical BS1 BS2 Client1 Client1 62 62 31
In dense deployments, Radio Resource Management needs to be tightly coordinated 63 63 LTE-RAN: Current Architecture Distributed control plane Tight coordination becomes infeasible with density Huge demands on the backhaul network Inefficient radio resource management Hard to manage in a dense network 64 64 32
SoftRAN: Big Base Station Abstraction Radio Element 1 65 65 SoftRAN Architecture CONTROLLER Periodic Updates Controller API RADIO ELEMENTS RAN Information Base Bytes Rate Queue Size Network Operator Inputs Interference Map Flow Records QoS Constraints Radio Element API Radio Element 3D Resource Grid POWER FLOW Frequency Radio Resource Management Algorithm 66 66 33
SoftRAN: SDN Approach to RAN Coordination : X2 Interface Control Algo OS Packet Tx/Rx Control Algo OS Packet Tx/Rx Control Algo OS BS1 Control Algo OS Packet Tx/Rx BS3 Control Algo OS Packet Tx/Rx Packet Tx/Rx BS5 BS2 BS4 67 67 SoftRAN: SDN Approach to RAN Control Algorithm Operator Inputs Network OS Packet Tx/Rx BS1 Packet Tx/Rx BS3 Packet Tx/Rx BS5 Packet Tx/Rx Packet Tx/Rx BS2 BS4 68 68 34
SoftRAN: SDN Approach to RAN Efficient use of wireless resources Global view on interference and load Simplified network management Plug-and-play control algorithms 69 69 Challenges: Backhaul Latency controller time 70 70 35
Challenges: Backhaul Latency Refactor control plane based on latency - Low latency ( < 1 ms) => No refactoring Principles for refactoring: - Controller manages global network state - Radio Elements leverage frequently varying local network state 71 71 Implementation Incrementally deployable on current infrastructure No modification to Base Station client interface New API definitions for Base Station Femto API: Standardized interface between scheduler and L1 * *http://www.smallcellforum.org/resources-technical-papers 72 72 36
Future Vision Expand SoftRAN to include 3G and Wifi networks Coordinated management of all available radio resources 73 73 Virtualized Wireless Networks AT&T Verizon Wireless Network OS Open interface to heterogeneous wireless infrastructure X X 74 74 Shared physical wireless infrastructure 3G decoupled from network service WiFi AP LTE 37
Future Work: FASET 75 75 Concept Improve resource management by including optimized and fine-grained applicationawareness How? Separate the control plane from the data plane Optimize the control plane decisions from a global network perspective 76 76 38
SDN: BENEFITS All control plane resides in the SDN Controller Data plane (i.e., forwarding) resides in the SDN switches SDN controller propagates forwarding rules to SDN switches Avoids conflicting configuration among NW devices Reduces the number of human configuration of NW elements; reducing errors and network downtime 77 77 SDN: Benefits SDN Controller contains all SW, functionality, & features needed by the NW: Single point of configuration Simplifies deployment, maintenance and reconfiguration SW can be developed without vendor involvement (i.e., faster innovation) 78 78 39
SDN FOR CELLULAR NETWORKS Major scalability and cost limitations of current cellular networks arise from: Centralized data-plane functionalities implemented at the gateways Vendor-specific configuration interfaces that communicate through complex control-plane protocols and Inefficient and non-flexible network architecture 79 79 FASET: Enabling Self-Evolving Wireless Networks via Software-defined Architecture Objective: study fundamental principles underlying a new generation of software-defined wireless network architectures and algorithms, to lay a foundation for future self-evolving wireless systems that will be far more evolvable and flexible than current ones. 80 80 40