BestNet: SDN enabled converged

network optimization

Lime Micro Hackathon

AtlantTIC Research Center 1

Contents

Background ........................................................................................................................................................... 1

Description of the solution .................................................................................................................................... 1

Architecture of the solution .................................................................................................................................. 3

A description of the elements the finalist created ................................................................................................ 5

Hardware and software used ................................................................................................................................ 6

Issues ..................................................................................................................................................................... 7

Resolved issues .................................................................................................................................................. 7

Outstanding issues ............................................................................................................................................ 7

Plans for taking the solution forwards .................................................................................................................. 8

Background

Smartphones and tablets have evolved to a point where they have several wireless access technologies

available. Nevertheless, terminals are not managed by the network, and they have been considered just

as leaf nodes with a single network interface.

For example, users and operators are using Wi-Fi to offload cellular connections, especially in areas

with high connectivity demand. In addition, small cells and other ultra-dense networks will be essential

to reach the expected data rates for 5G.

Nevertheless, current solutions just configure terminals to connect to a list of Wi-Fi APs. Therefore,

there is a demand for solutions that are able to maintain connectivity (at the application level) and select

the best network interface according to a set of performance metrics (lowest latency, highest bandwidth,

lower consumption, etc.).

Network operators have enough information to determine and predict the "best interface" and the "best

network" that should be used at every moment. Currently, it is not possible to command devices to use

one or another. However, if we transform them into SDN routers managed by the network, this will not

only be feasible, but it will also be possible to alter routes without interrupting applications.

Description of the solution

In this demo, we show how a LTE network (in the future, a 5G network) can be optimized by allowing

the network to handle the connections of a user terminal. We have been granted a USPTO patent

covering this approach (publication number US20170093722 A1).

AtlantTIC Research Center 2

To achieve this objective we include SDN agents in users’ terminals. They are connected to a SDN

controller that centralizes some decisions that to date, were the exclusive responsibility of end user

terminals, such as access network selection and traffic steering through multiple interfaces.

This way, the “Network” can decide the best interface and access network at each moment to satisfy

users’ needs and optimize the use of the network. Hence, it is possible to reach the required latency or

bandwidth (or, in general terms, the expected QoE), even when users are moving or when the state of

the network changes dynamically.

Figure 1: BestNet scenario

In our demo, which fits in Scenario 4.b Converged networks, we show how a SDN-enabled terminal (a

computer) is commanded to switch between two SDN Wireless Access Points without losing session

continuity, or even to use both interfaces simultaneously. LTE (implemented with OAI eNB and EPC,

and LimeSDR) is used to control the user terminal and to transmit user data while the Wi-Fi interface is

down or is reconnecting.

AtlantTIC Research Center 3

Architecture of the solution

Figure 2 shows a more detailed diagram of architecture for the proof of concept that we presented to the

“Lime Micro SDR Hackathon”. Two laptops are connected to four networks: two Wireless-based LAN,

one Ethernet-based LAN, and one LTE network.

Figure 2: BestNet PoC Testbed

The elements in the testbed are:

1. LTE network:

OAI’s EPC is running in one PC, and the eNodeB is running in another PC connected to a Lime SDR. The S+PGW is connected to the Gateway PC through a L2 switch.

2. Ethernet network:

Just a L2 switch connected to one Laptop and to the Gateway PC.

AtlantTIC Research Center 4

3. Wireless network:

Two SDN enabled Wireless Access Points, both connected to the Gateway PC through a L2 switch.

4. Controller/Profiler:

A PC, connected to the Gateway through the LTE network L2 switch, hosts the SDN Controller and the Profiler. The SDN Controller, implemented in Open DayLight, sends forward rules to the elements of the system. It follows the orders received from the Profiler, which makes decisions based on the information received from the UEs.

5. Gateway:

The Gateway PC contains four NICs (Network Interface Cards) and works as a router. The Gateway PC is used also as an Application Server in the tests involving iPerf.

6. WebRTC server:

To demonstrate the operation of the system, we will show how a WebRTC session continues operating even if we change the access network that provides connectivity to the clients while maintaining a video conference.

The accompanying video shows three tests that present two of the main features of our system (traffic

steering and session continuity):

1. Traffic Steering:

This test shows how the Controller can select the interface used by UEs to transmit the information. Alice runs an iPerf client and establishes a TCP connection with the Application Server. The Controller decides which interface should be used at every moment (or can even decide to use the two simultaneously).

2. Session Continuity with iPerf:

This tests shows how the connection is maintained for the application even when we change which access network is used (an iPerf test session continues working even when we change the access network that connects the application and the server).

1. A TCP iPerf test is launched between Alice and the Application Server. 2. Alice's traffic goes through SDN-WAP-01. 3. At one point, the SDN controller in the core network decides to change the Wireless Access

Point that Alice should use to transmit the iPerf traffic. 4. The controller redirects the traffic to the LTE interface during the switching process in order to

keep the session open while the Wi-Fi interface is down. 5. When the connection with the SDN-WAP-02 Wi-Fi network is established, the controller

commands Alice to use again the Wi-Fi interface.

AtlantTIC Research Center 5

3. Session Continuity with WebRTC:

This test shows how the connection is maintained at an application level (a webRTC video conference continues working even when we change the access networks that connects the WebRTC clients and the server).

1. Alice and Bob set up a video conference call using a web application (https://appr.tc/). 2. Alice's video streaming goes through SDN-WAP-02. 3. At one point, the SDN Controller in the core network decides to change the interface that Alice

should use (because it detects a poor performance, needs the bandwidth in that network for other user, etc.).

4. The controller redirects the traffic to the LTE interface during the switching process in order to keep the session working while the Wi-Fi interface is down.

5. When the connection whit the SDN-WAP-01 Wi-Fi network is established, the controller asks Alice to use again the Wi-Fi interface.

A description of the elements the finalist created

The Traffic Steering Architecture (TSA)

The idea behind TSA (figure 3) is to manage end user devices communications from a centralized controller. Nowadays, user terminals generate and consume huge amounts of traffic, and therefore they have a considerable impact on the network. If we make it possible for the "network" (or more precisely, for a centralized agent that knows the state of the network) to handle how user terminals use their different communication interfaces, it is possible to improve the Quality of Experience (QoE).

This approach opens the door to different optimization policies, involving the most convenient interface configurations in end terminals. For example, the controller may detect that one access network is suffering from congestion due to an “elephant” traffic flow, and may therefore decide to move “mice” traffic flows to another access network. Other possibilities are enforcing connectivity policies from a centralized controller (e.g. blocking or allowing specific traffic types), the transparent application of energy-saving strategies (e.g. switching on and off specific physical interfaces depending on the terminal battery level), or centralized mobility support (e.g. applying NAT or encapsulation techniques to support session continuity).

The proposed TSA model requires certain elements in terminals themselves, as well as specific modules at the side of the controller. In order to add SDN capabilities to end user terminals these must feature a virtual switch offering an OpenFlow API to the controller. The TCP/IP stack of the terminal runs on top of an L2 virtual interface which, in turn, is connected to an internal OpenFlow virtual switch such as Open vSwitch. Finally, the physical interfaces are placed directly underneath the virtual switch. This architecture means that the applications are unaware of the multiple physical interfaces, the virtual switch and the SDN architecture, and perceive a unique IP address, i.e. the one corresponding to the virtual interface. The operation of the virtual switch is governed by the TSA controller using the OpenFlow protocol. Apart from the virtual switch, additional modules are required to provide the TSA controller with meaningful information about the terminal’s connectivity (e.g. the available physical interfaces) and to configure and connect to the access networks selected by the controller.

AtlantTIC Research Center 6

Figure 3: Traffic Steering Architecture

The architecture of the controller follows the classical conceptual division between the Controller Platform and its Northbound and Southbound Interfaces. The Southbound Interface includes the communication protocols that will be used to communicate with the terminals and the switches and routers in the networks, including the reception of metrics and the delivery of network-interface configuration parameters and SDN rules. The Controller Platform is composed of several modules that provide all the functionality that is needed to maintain an updated view of network topology, process information from all its devices (terminals, routers and switches) and perform AAA tasks. Finally, the Northbound Interface connects the Controller Platform to the dedicated modules that analyze the performance of the network and the user connectivity quality and decide appropriate steering decisions, which are later applied by the terminals according to the SDN paradigm.

The SDN enabled Wireless Access Point

We are developing a Wi-Fi Access Point that can be managed by a SDN controller in order to route the traffic dynamically according to the state of the network or to the policies of the operator. We have successfully completed the development of a simple Access Point that handles a Wi-Fi and an Ethernet interface. It is implemented with a virtual switch in Linux running in a x86 PC. We are porting this implementation to inexpensive OpenWRT Wi-Fi APs (we are optimizing the current implementation in order to be able to manage a high amount of traffic despite of the low capacity of the system in terms of CPU, memory, etc.).

Hardware and software used

The hardware used for this PoC was:

2x Laptops Dell XPS 13 with Ubuntu 14.04; used for Alice and Bob (user devices implementing our Traffic Steering Architecture).

2x PCs Intel core i7 with 16GB of RAM; 1x 1Gbps NIC with Ubuntu 16.04; working as SDN-WAPs

AtlantTIC Research Center 7

3x 8 ports 1 Gbps L2 switches 1x Intel Xeon E5-2407 with 64GB of RAM; 4x 1Gbps NICs; with Ubuntu 16.04; working as a Gateway. 1x Intel Core i5 with 8 GB of RAM; 1x 1Gbps NIC; with Ubuntu 16.04; working as the

Controller/Profiler 1x Intel Core i7 with 16 GB of RAM; 2x 1 Gbps NICs; with Ubuntu 16.04; running the Open Air Interface

EPC core. 1x Intel Core i7 with 16 GB of RAM; 1x 1 Gbps NICs; with Ubuntu 16.04; running the Open Air Interface

eNodeB. 1x LimeSDR with Aluminium Kit USB3 Software Defined Radio attached to the OAI eNodeB.

The sofware used was:

Open Air Interface EPC core network (openair-cn; https://gitlab.eurecom.fr/oai/openair-cn). Open Air Interface eNodeB lte-softmodem

(openairinterface5g; https://gitlab.eurecom.fr/oai/openairinterface5g). OpenDayLight for the SDN controller implemented in Apache Karaf OSGi Platform

(https://www.opendaylight.org/). MySQL Server for the Profiler database (https://www.mysql.com/). Oracle Java 8 platform for the implementation of the client daemons

(http://www.oracle.com/technetwork/java/javase/overview/java8-2100321.html). WebRTC for the videostreaming (https://webrtc.org/). iPerf for the throughput test (https://iperf.fr/). Grafana with InfluxDB for the presentation of measurements

(https://grafana.com/; https://www.influxdata.com/). Wireshark for development (https://www.wireshark.org/).

Issues

Resolved issues

The most important challenge was to redirect the traffic flow through different subnets in different LAN segments while maintaining the connections alive. We have dealt with this problem by assigning a unique address to the BestNet-enabled terminals (such terminals have several physical interfaces, but applications are only aware of this address) and using the SDN controller to manage L2 frames in a virtual switch (in terminals) and at the SDN enabled gateways, switches or routers.

We implemented a SDN enabled Wi-Fi Access Point in a low cost OpenWRT based Wi-Fi AP. The selected device includes a CPU that is not powerful enough and a small amount of memory, so we had to use x86 PCs to implement the Wi-Fi APs used in the demonstration.

We got familiarized with OpenAirInterface and LimeSDR to implement a fully functional LTE operator and to be able to handle the traffic that is sent through this network.

Outstanding issues

The system is only a proof-of-concept and needs to be improved, both on stability as well as robustness.

AtlantTIC Research Center 8

Implement TSA in a conventional smartphone (Ubuntu Touch and/or Android Phone). In this demonstration we have used PCs with multiple network interfaces (Wi-Fi, Ethernet, and LTE) running Linux .

Improve our SDN enabled Wi-Fi AP implementation for very low cost OpenWRT Wi-Fi APs.

Plans for taking the solution forwards

Improve stability and robustness of the system. Implementation in an Android phone/tablet. Continue developing the SDN Wi-Fi Access Point in a commercial router. Continue developing the Profiler. In this demo, we command the terminals manually, but in the future,

an automatic system (the Profiler) will collect statistics and calculate the routes to optimize the network. Furthermore, It will predict the resources needed by users and will route the traffic accordingly.

Integrate also the Edge Computing and Network Slicing paradigms in this demonstration. Move Network Functions or Applications near the end user when necessary (in order to improve latency, use less network resources, etc.)