Software Defined Wireless Networks (SDWN): Unbridling SDNs Leonardo Linguaglossa & thanks to Salvatore Costanzo, Laura Galluccio, Giacomo Morabito, Sergio Palazzo Università degli Studi di Catania Dipartimento di Ingegneria Elettrica, Elettronica, e Informatica Consorzio Nazionale Interuniversitario per le Telecomunicazioni (CNIT) April 30, 2013 L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 1 / 47
Lesson three: Software Defined Wireless Networks 1 Introduction 2 SDN in the wireless domain 3 SDN for Wireless Sensor Networks 4 SDN and Mobile Ad Hoc Networks 5 An empiric assessment 6 Conclusions and future work L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 2 / 47
Introduction and motivations L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 3 / 47
Motivations and contribution Increasing number of wireless and mobile communications companies are investing in SDN. Examples: Verizon, Nokia Siemens Networks, Ericsson, and Netgear are members of OpenNetworking Foundation. However, large effort is still required: What are the advantages of SDN in the most common wireless networking scenarios? How should the SDN concept be expanded to suit the characteristics of wireless and mobile communications? In this lecture we will: analyze the advantages of the SDN approach in low rate wireless personal area networks (LR-WPAN)s. Example: IEEE 802.15.4; identify the differences in requirements between traditional wired networks and LR-WPANs; present Software Defined Wireless Network (SDWN) (98% implemented). show ongoing activities on SDN & Smartphones. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 4 / 47
SDN in the wireless domain L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 5 / 47
Advantages of SDN in LR-WPANs SDN is about simplification and evolvability. This applies to any networking environment. Almost universal consensus on the first two layers of the protocol stack IEEE 802.15.4, but several alternative candidates often incompatible for the higher layers 1. For example: 6LOWPAN vs. ZigBee; Difficult for a node to move from one network to another. 1 This is valid for other relevant domains: vehicular networks, mesh networks,... L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 6 / 47
Advantages of SDN in LR-WPANs SDN solves this problem: allowing to change the behavior of a node on the fly. In most implementations SDN applies a centralized management through the controller: easier optimization in the use of network resources; crucial problems: which element(s) run the network control operations; how to communicate with such element(s). L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 7 / 47
Requirements for SDN solutions in LR-WPANs In traditional wired networks, transmission speed is the major performance measure rigid definition of rules. In LR-WPANs scenarios, priorities change: energy efficiency is the primary requirement for a Software Defined Wireless Network (SDWN) solution; Accordingly, SDWN must support: Duty cycles: an appropriate action 2 must be defined; In-network data aggregation: an appropriate module must be introduced in the protocol architecture and a new action must be defined; Flexible definition of the rules: this is achieved in two ways: Any byte of the packet should be considered as a possible part of the rule; Other relation operators (not just equivalence) can be considered for the matching of rules. Other obvious requirements: support of node mobility, link unreliability tolerance, robustness to the failure of generic nodes and the control node. 2 We use the OpenFlow approach and notations L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 8 / 47
Software Defined Wireless Networks (SDWN) L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 9 / 47
Architecture L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 10 / 47
Architecture - Example of our implementation L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 11 / 47
Generic node Standard IEEE 802.15.4 (layers 1 and 2); Forwarding layer: treats arriving packets as specified in the flow table... Control packet: given to the Networking Operating System (NOS); Data packet: Two cases: Match in the flow table action; No match send to the NOS; Aggregation layer: Aggregates information flowing through the network. Currently, One of the possible actions is to include the packet in an aggregation equivalent flow (AEF) Concatenates packets of the same AEF. Network Operating System (NOS) layer: Collects and sends local information to the Controller; Controls the behavior of all layers as specified by the Controller; L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 12 / 47
Sink node Embedded system Adaptation layer: formats messages as needed by the device; Virtualizer: uses the local information collected by the generic nodes to build a consistent representation of network state; Topology, nodes battery level, link quality, etc Currently it is implemented as a Java Map; The Virtualizer allows several logical networks to run over one physical network. Device Controller(s): implements the desired network management policy. In our implementation Controllers interact with the Virtualizer through a UDP socket. Same as a generic node... L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 13 / 47
Flow table and flow table entries A flow table is composed by several flow table entries. A flow table entry contains the following information: A rule: description of the characteristics of all packets belonging to a flow and that must be treated by the node in the same way; An action: operation to be executed for all packets of the flow; Some statistic information: number of packets received for the flow; Further details later... L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 14 / 47
Some design and implementation details L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 15 / 47
Collection of topology information NOS in generic nodes need to communicate with the NOS in the sink how reach the sink without the controller intervention? The sink periodically generates a beacon packet, which is broadcast in the network The beacon packet contains information about the current distance (number of hops) from the sink and the battery level of the last relay node Generic nodes use information in the beacon to decide the most convenient next hop to reach the sink Information contained in the beacon is used to build the neighbors table: It contains the list of neighbors and the corresponding RSSI 3 values; It is periodically sent to the sink through a report packet. The sink receives the neighbor tables by all nodes and infers the global network topology (at the Virtualizer layer). 3 Received signal strength indication L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 16 / 47
Specification of rules and actions In our scenario: Major goal: flexibility; Major limitation: small memory; A rule operates on (up to) three windows of 1-2 bytes of the incoming packets Each flow table entry contains three group of blocks: 1 Window blocks: related to the three windows; For each window: size, operator, position of the first byte of the window, value 2 Action block: two fields Action type (e.g., forward, modify, drop, aggregate, turn off radio) and the Action value (meaning depends on the type of action) 3 Counter: number of packets received so far satisfying the rule. Figure: Exemplary table. Example: consider Entry 1 if bytes 2 and 3 are = 170 and 24 and bytes 4 and 5 are 170 and 11 forward to node 170.23 17 packets have been classified with this rule L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 17 / 47
Packet format Entry 1: All packets generated by node 170.24 and that are not directed to node 170.11 must be forwarded to node 170.23. Packet types: Type 0 - Data packet: packet generated by the application layer; Type 1 - Beacon packet: broadcast periodically by the sink; Type 2 - Report packet: generated periodically by generic nodes and sent to the sink; Type 3 - Rule/action request: generated by a generic node and sent to the sink upon receiving a packet not matching with any flow table entry; Rule/action Response: Generated by the sink in response to a Rule/action request. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 18 / 47
A working Use Case L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 19 / 47
SDN and Mobile Ad Hoc Networks Challenging with Android s open features L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 20 / 47
Current Cellular Architecture L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 21 / 47
Why SDN and Smartphones? Let s think about: Data Sharing; Internet Connection Sharing; Service Sharing; L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 22 / 47
Why SDN and Smartphones? Data Sharing Figure: Current Mobile + Clouds Mobile Clouds for Opportunistic Networks; Green Mobile Clouds; L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 23 / 47
Why SDN and Smartphones? Internet Connection Sharing Fred has a 3GB per month connection; Jim should pay 2 to connect to the internet. Fred can share its connection! Maybe he ll gain some credits; Game Theory Approach It s ok for Users: they win. What about Operators? L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 24 / 47
Why SDN and Smartphones? Service Sharing We could use one (or more) controller(s) as a Service Manager: Operators: provides the infrastructure; Controller(s): third party; it manages services within its subnetwork Service Level Agreement with Providers; Users: they can subscribe to one or more services; Figure: Operators Figure: Service Managers L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 25 / 47
Why SDN and Smartphones? Service Sharing We could use one (or more) controller(s) as a Service Manager: Operators: provides the infrastructure; Controller(s): third party; it manages services within its subnetwork Service Level Agreement with Providers; Users: they can subscribe to one or more services; Figure: Users L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 25 / 47
Would SDN fit for Smartphones? L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 26 / 47
Simulator Class Diagram L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 27 / 47
Controller Class Diagram L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 28 / 47
Deployment Diagram L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 29 / 47
A simple Use Case Features: Multiple nodes (i.e. Smartphones); Single Cell; One SDN Controller, attached to the BTS; A Content Centric 4 Domain: each node advertises its contents! Behaviour: 1 A node can request one conent; 2 The request is forwarded to the Controller UMTS channel; 3 The controller look-up for this content within its maps. 4 If the item can be found inside the cell, it makes a path between the source and the destination node WiFi channel. 4 cfr. http://en.wikipedia.org/wiki/named_data_networking L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 30 / 47
Packet Format Control Packets L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 31 / 47
Packet Format Instruction Packets L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 31 / 47
Simulator Elements Simulator Main entry point: it creates the nodes of the simulated network: int id, posx, posy, mode; id=mode=0; posx=posy=77; MyNode node = new MyNode(id, posx, posy, mode); Simulator creates the Environment from an initial set of nodes: Environment env = new Environment(new ArrayList<MyNode>(){{ add(node); //... }}); Then it creates the Simulator Frame, and let nodes start their behaviour: SimFrame s = new SimFrame(); for (MyNode n : nodes){ n.start(); } L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 32 / 47
Simulator Elements Node(s) Main structure of nodes: /* Managers and executors */ MovementManager move; TransmissionManager transm; ExecutorService receiver = Executors.newCachedThreadPool(); /* Environment: is shared */ private Environment env; /* Physical Interfaces and lock objects*/ private UmtsInterface umts = new UmtsInterface(); private WiFiInterface wifi= new WiFiInterface(); private final Object lockumts = new Object(); private final Object lockwifi = new Object(); L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 33 / 47
Simulator Elements Node(s) /* Tables and related lock objects */ //Content table: Content Name -> Content Data Map<String, Content> contentstore = new HashMap<String, Content>(); private final Object lockcontent = new Object(); //Flow Table: Content Action NextHop(s) Map<String, FlowRule> flowtable = new HashMap<String, FlowRule>(); private final Object lockflow = new Object(); Start method: public void start(){ move= new MovementManager(this, mode); transm=new TransmissionManager(this, env); } L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 34 / 47
Simulator Elements Node(s) UMTS and WiFi APIs: public void umtssend(packet p){ synchronized(lockumts){ umts.send(this, p); } } public void wifisend(packet p){ synchronized (lockwifi) { wifi.send(this, p); } } L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 35 / 47
Simulator Elements Environment It acts as an Event handler. We can have two Event types: Uplink Event; Downlink Event; It is implemented with a (not yet) sophisticated Propagation Model. Thanks to this model, the Environment can dispatch Events (i.e. packets) only to the nodes that would be involved in the communication in the real world. Models: Isotropical Free space: L 1 200m Coverage Radius; d 2 ( Young model (large cities): L = G B G hb ) h 2 M M d 2 Okumura: L = 69.55 + 26.16log f 13.82log h t A(h r ) + (44.9 6.55log h t)log d By changing just the propagation model, we can develop algorhitms considering several kind of scenarios. We could even invent our model. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 36 / 47
Controller Elements Controller Controller runs in a different process, within a different PC. It is connected with the Controller Entry Point within the simulator, to act as if it was connected to a Base Station inside a Cell of a Mobile Network. Controller sends: SETUP PACKET, INSTRUCTION PACKET; Controller receives: INFO PACKET, REQUEST PACKET. Thanks to our simple protocol, Controller is able to learn both topology of the physical network and the Content Map inside the Cell. Using these maps, controller is able to instruct nodes (in the SDN way using flows) and let nodes forward packets as requested. Forwarding and Routing are made by name and not by host. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 37 / 47
Controller Elements Processes HelloSetupProcess Every 120 s, Controller sends a SETUP PACKET; It indicates it address, and so nodes will be aware about the presence of a Control Node. When nodes understand that there are no more controllers, they set the boolean hascontroller to false; NeighbourCalculationProcess It consists of two subprocesses: In addition to the Topology map, Controller builds also a neighbour map. This map needs to be pruned periodically. Two nodes that have been neighbours could have lost their connection. SteinerGridProcess Steiner Tree calculation; Multicast: multiple nodes can subscribe to the same content. It will reduce transmission rate. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 38 / 47
Controller Elements Steiner Tree Problem description: N nodes; Connected by lines of minimum total length; Nodes should be connected to each other either directly or via other nodes. It may be shown that there may be points added to the tree: Steiner Points; They must have degree of 3, and angles of 120 deg. Open Source Algorhytms for Steiner Tree calculation: www.flywings.org.uk/findsteinertree L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 39 / 47
Controller Elements Steiner Tree Our Steiner Tree Problem has some more constraints: Steiner points, which are not part of the original set, must be real nodes S1 and S2 should be nodes involved in communication even if they re not interested in that content. Links does have to make sense in the real world: a link between A and S1 could exist only if they are within the same coverage area otherwise, our custom steiner tree must involve other nodes as relays. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 40 / 47
Controller Elements Steiner Tree Solution: Controller builds a steiner grid; In this matrix it stores the Nodes that currently are approximately in that range. r 200m A node can create a link with another node within a one-square distance. Approximated Steiner Tree: hop by hop, there should be a relay. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 41 / 47
An empiric assessment L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 42 / 47
Challenging three students A simple assignment: write the SDWN controller for a sensor network imposing the following policy If the payload value is lower than x deliver the packet to node A If the payload value is higher than x deliver the packet to node B If the payload value is equal to x deliver the packet to B but avoid routes passing through C The challengers: Good Computer Engineering MSc students Two lessons about SDN and OpenFlow Good Java programming skills The rule: complete the assignment within 24 hours maximum vote (i.e., 30/30), no further exam! L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 43 / 47
Challenging three students A simple assignment: write the SDWN controller for a sensor network imposing the following policy If the payload value is lower than x deliver the packet to node A If the payload value is higher than x deliver the packet to node B If the payload value is equal to x deliver the packet to B but avoid routes passing through C The challengers: Good Computer Engineering MSc students Two lessons about SDN and OpenFlow Good Java programming skills The rule: complete the assignment within 24 hours maximum vote (i.e., 30/30), no further exam! Started on September 4, 2012 at 9.30 and...! L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 43 / 47
L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 44 / 47
Challenging three students A simple assignment: write the SDWN controller for a sensor network imposing the following policy If the payload value is lower than x deliver the packet to node A If the payload value is higher than x deliver the packet to node B If the payload value is equal to x deliver the packet to B but avoid routes passing through C The challengers: Good Computer Engineering MSc students Two lessons about SDN and OpenFlow Good Java programming skills The rule: complete the assignment within 24 hours maximum vote (i.e., 30/30), no further exam! Started on September 4, 2012 at 9.30 am and completed around 6.15 pm of the same day! L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 45 / 47
Conclusions and future work L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 46 / 47
Conclusions and future work Contributions First attempt to analyze the opportunities and challenges of SDN in LR-WPANs Definition and implementation of a prototype Future work Robustness against sink failure (multi-sink architectures?) Performance evaluation through simulation or experimentation Optimal setting of some protocol parameters (for example, size of tables, period of beacon and report generation, etc.) Implementation of a simulator of the generic nodes and interaction with a real controller Extension to the the hardware-in-the-loop simulation approach Towards a Software Defined Wireless Networking approach, using different technologies. L. Linguaglossa, S. Costanzo et al. Unbridling SDN April 30, 2013 47 / 47