1. 2017/03/30 105598065 Speaker：Cheng-Yu Wang (王承宇) Advisor：Ke, Kai-Wei
Enabling Resource Pooling in Wireless Networks
through Software-Defined Orchestration
2017/03/30
Speaker：Cheng-Yu Wang (王承宇)
Advisor：Ke, Kai-Wei

2. Outline
Introduction
Explain Keywords – Resource Pooling、Ad-hoc network、OpenFlow
SDN-Enabled Resource Pooling
Principles
Edges and drawback
Example use case & Test Bed details
Performance Analysis
Conclusion

3. Introduction
This paper proposes a network paradigm where network resources are virtually pooled through an OpenFlow controller that serves as the network orchestrator.
Improvement of uplink data rates in addition to the downlink and the compatibility with common equipment, as no ad-hoc network protocols are needed.

4. Resource Pooling?
Resource pooling is an IT term used in cloud computing environments to describe a situation in which providers serve multiple clients, customers or "tenants" with provisional and scalable services.

5. Ad-hoc Network?
A ad hoc network is a decentralized type of wireless network. 
The network is ad hoc because it does not rely on a pre-existing infrastructure, such as routers in wired networks or access points in managed (infrastructure) wireless networks.

6. OpenFlow?
OpenFlow is an open standard that enables researchers to run experimental protocols.
In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions.

7. Introduction (Cont.)
Recent years have seen the rise of Internet traffic originating from mobile sources, due to different contemporaneous Factors：
Terrestrial infrastructures offer faster mobile data rates
The diffusion of mobile consumer devices such as smartphones and tablets
The growing fruition of digital goods

8. Introduction (Cont.)
In mobile networks a significant proportion of traffic is generated by a limited number of users.
An analysis performed by Ericsson on a set of markets with high LTE subscriber and mostly high-end Android devices has shown that the heavier 10% of users generate 55% of data traffic, while the heavier 20% of users generate around 70% of the overall data traffic

9. Introduction (Cont.)
The critical challenge is how to create such a pooled virtual network and how to make effective use of it
In this work, we advocate that Software-Defined Networking (SDN) technologies are mature enough to efficiently orchestrate a resource pooled network
Therefore, this paper is focused on the efficient orchestration of such pooled uplink transfers

10. SDN-Enabled Resource Pooling (Principle)
The goal is to aggregate a set of network resources, corresponding to a set of links with their characteristics, so as to exploit them as a single one with improved capacities.

11. SDN-Enabled Resource Pooling (cont.) (Principle)
This can be accomplished mainly through two different conceptual approaches:
Stateful: all the involved actors have knowledge of what is going on
Virtual: hosts may or may not be aware of the resource pooling mechanisms undergoing the network

12. SDN-Enabled Resource Pooling (cont.) (Principle)
the approach we chose for our proposal, as it allows to avoid the use of ad-hoc network protocols and it ensures compatibility with current mobile networks
Moreover, we claim that it is an approach beneficial in supporting an arbitrary user behavior

13. SDN-Enabled Resource Pooling (cont.) (Principle)(傳送方法)
resource management to be separated from client hosts
Hosts are supposed to have at least two active network interfaces: WLAN、WWAN
a host may be able to perform a network operation using its WLAN channel, when the relative packets are received by the WLAN switch/router, they can be serially forwarded to other LAN hosts that in turn may concurrently send them to the proper destination through their WWAN links

14. SDN-Enabled Resource Pooling (cont.) (edges and drawback)
to the best of our knowledge neither OpenFlow nor alternative southbound protocols allow to install on a switch a rule that is able to change run-time the port on which to forward a packet.
As a consequence, the controller itself risks of being the performance bottleneck, representing the throughput upper bound regardless of the network composition.

15. Example use case
depicted in Figure 2, is composed by a certain number of First Responders who connect to a MEOC (Mobile Emergency Operations-Control Centre) that brings to them IEEE n coverage

16. Example use case (Cont.)
First Responders may belong to different entities, such as medical personnel, security services or firemen

17. Example use case (Cont.)
Now suppose that a generic field operator wants to upload a file to a remote destination
this host sends first the file(s) to the MEOC using the high-quality LAN channel. The MEOC then orchestrates the data distribution

18. Test Bed details Ubuntu Linux15.10，Mininet network emulator 2.2.1
Open vSwitch：emulated OpenFlow-Compatible switch
Floodlight ：controller (Ryu、Open Daylight、NOX、POX etc.)
iPerf：generate TCP traffic
numbers of clinet：from 3 to 17

19. Test Bed details (Cont.)
The basic topology of the test system is depicted in Figure 3, and he MEOC is composed by a host
There are five client hosts , each with its own LAN connection to the MEOC and with a specific mobile connection to a remote node, called “sink”.

20. Test Bed details (Cont.)
In each client host, a Linux Bridge has been configured to forward traffic properly between its two interfaces, and the same holds for the remote node

21. Test Bed details (Cont.)
Configuration 1 Steps
An iPerf TCP server is started on the sink host
iPerf client job connects to it from a field host
a generic TCP upload from h1 to hSink
traverse all client nodes(follow step 1~3)
Performance is analyzed on the sink host

22. Test Bed details (Cont.)
Configuration 1 Steps

23. Test Bed details (Cont.)
Configuration 2 Steps
An iPerf TCP server is started on the sink host
iPerf client job connects to it from a field host
Controller dispatch packet from s1 to h2~h4
a generic TCP upload from h2~h4 to hSink
Performance is analyzed on the sink host

24. Test Bed details (Cont.)
Configuration 2 Steps

25. Test Bed details (Cont.)
Two different orchestration disciplines to forward packets to different ports have been implemented as FloodLight modules:
Round Robin (RR): for each packet received, the controller forwards it to a different output port, incrementally (i.e. 3, 4, 5, 6, 3 ..).
Weighted Round Robin (WRR): for each packet received, the controller forwards it using a Weighted Round Robin fashion

26. Test Bed details (Cont.)
High packet loss ratios hinder TCP performance, and the only way to compensate the inability of TCP is to grow its congestion window
To active a sufficient number of TCP flows for each transfer, we set TCP flows to 40.

27. Performance Analysis
System efficiency ratio = actual recorded data rates / theoretical aggregate capacity
每個模擬測試次數：10 times
取樣頻率：0.1 second sampling rate

28. Performance Analysis (Cont.)

29. Performance Analysis (Cont.)
Symmetric configuration
Asymmetric configuration (RR)
Asymmetric configuration (WRR)
Average data rate
38Mbit/s
20Mbit/s
28Mbit/s
theoretical aggregate capacity
40Mbit/s
30Mbit/s
System efficiency ratio
38/40 = 95%
20/30 = 66.7%
28/30 = 93.3%

30. Performance Analysis (Cont.)
When h1 equal to 5 Mbit/s, gives a 4X performance Speedup with RR and a 5.6X performance Speedup with WRR.

31. Performance Analysis (Cont.)
Figure 5 shows the general scalability of the system
it can be seen that the efficiency slightly decreases as the forwarding nodes number increases.

32. Performance Analysis (Cont.)
2 nodes：19.5Mbit/s，19.5/20 = 97.5%
4 nodes：95%
8 nodes：72Mbit/s，72/80 = 90%
16 nodes：143Mbit/s，143/160 = 89%

33. Performance Analysis (Cont.)

34. Performance Analysis (Cont.)
In Figure 6, values are recorded with a 1 second sampling rate for clarity purposes.
With the exception of an initial performance spike, Throughput in symmetric and asymmetric(WRR) are close.

35. Performance Analysis (Cont.)
Symmetric configuration
Asymmetric configuration (RR)
Asymmetric configuration (WRR)
Average data rate
25Mbit/s
19Mbit/s
24Mbit/s
theoretical aggregate capacity
40Mbit/s
30Mbit/s
System efficiency ratio
25/40 = 62.5%
19/30 = 63.3%
28/30 = 80%

36. Conclusion
Through emulation results, we showed how such a system is able to efficiently administrate the pooled resources, resulting in significant performance gains for client hosts
We conclude by considering that the proposal has been also designed so as to not require ad-hoc protocols and that a careful choice of the controller technology is able to guarantee high performance