Content uploaded by Daniel Corujo
Author content
All content in this area was uploaded by Daniel Corujo on Sep 14, 2017
Content may be subject to copyright.
Towards Enhanced Connectivity Through WLAN
Slicing
Maxweel S. Carmo∗† , Sandino Jardim∗† , Thalyson de Souza∗, Augusto V. Neto∗ ‡, Rui Aguiar‡, Daniel Corujo‡
∗Universidade Federal do Rio Grande do Norte (UFRN), Natal-RN, Brazil
†Universidade Federal de Mato grosso (UFMT), Barra do Garc¸as-MT, Brazil
‡Instituto de Telecomunicac¸˜
oes, Aveiro, Portugal
{max, sandino}@ufmt.br, thalysonluiz@ppgsc.ufrn.br, augusto@dimap.ufrn.br, ruilaa@ua.pt, dcorujo@av.it.pt
Abstract—Nowadays domestic and enterprise WLANs are
pervasive and offer capabilities adequate for a broad spectrum
of applications. Unlocking these networks for enhanced wireless
access to select users and devices, through dynamically sharing
the unused portion of hotspots bandwidth, is key to provide
seamless connectivity. Far from providing just basic wireless
connectivity, we argue that these WLANs can be efficiently
exploited to cope with emerging applications in the context
of smart cities, massive machine type communication, and
cellular data offloading. We introduce an approach aimed at
the efficient sharing of available WLANs resources, allowing
applications of domestic or enterprise users to coexist with third-
party applications. To achieve this goal, we go beyond existing
solutions by proposing the virtualization of access networks to
offer differentiated networking services in an isolated manner.
However, commodity wireless access devices are low-cost and
performance-constrained, in contrast to carrier-grade systems
that are very costly by deploying high networking performance.
For this paper, we focus on the suitability of our approach on
the customer premises, by assessing key performance networking
aspects of SDN-enabled commodity wireless access devices, to
obtain a better perspective of their current limitations.
I. INTRODUCTION
Emerging scenarios that rely on wireless communication
demand network requirements that cannot be accomplished
by traditional WLAN approaches. For instance, the recent
explosion of mobile data, where it is expected that the ag-
gregate data rate will increase by a factor of 1000x in ten
years, has prompted the 5G [1] research community to work on
new mechanisms and alternative architectures, as the current
incremental evolution of cellular network infrastructures will
not able to cope with it. One of the prominent approaches to
tackle this issue is the reuse of frequencies through smaller
cells and heterogeneous networks, and even the employment
of the IEEE 802.11 spectrum. Indeed, according to the latest
Cisco’s Visual Networking Index (VNI) report [2], in 2015
mobile offload data surpassed cellular traffic for the first time,
as 51% of total mobile data traffic was offloaded to 802.11
WLANs or femtocells. On a related scenario, the NGMN 5G
vision [3] expresses that the next mobile generation technology
will heavily rely on virtualization technologies to, based on
a common substrate infrastructure, tailor specific networks
offering specialized services for the fulfillment of the use
case demands, in contrast to today’s one-size-fits-all networks
where applications share access to the same network features.
Another emerging scenario is the sharing of user-provided
wireless resources with the general public. The high availabil-
ity of Wi-Fi networks in public places has fostered initiatives
like FON and Comcast Xfinity, which expand WLAN cover-
age for costumer members. This concept leverages customer-
owned WLAN networks that agreed to share a part of their
bandwidth for availability, allowing other members to connect.
Finally, with the popularization of IoT a massive number of
devices and sensors per square kilometer on urban centers
will require connectivity (smart cities, for instance). To cope
with that demand different network technologies are being
envisaged.
We argue that the WLAN infrastructure currently existing
on densely populated urban centers can be leveraged to effi-
ciently support the realization of these scenarios (and improve
the ones already existing, such as Internet access sharing
for end-users). Their requirements vary widely, but generally
include Quality of Service (QoS) guarantees at customer
premises network, optimized usage of customer and access
network resources, resource provisioning deployed beyond
the carrier-grade (at the access and customer networks, in
a dynamic way), scalability to accommodate an increasing
number of users and nodes, mobility support, and seamless
connectivity. All these requirements imply the extension of
network control operations on the customer systems by Inter-
net service providers. Nonetheless, despite that ISPs deploy
carrier-grade equipment at the core and access networks,
customer systems are traditionally composed by commodity-
based hardware network devices, meaning standard-issue mul-
tifunctional nodes (modem, switch, router, and wireless access
point functions in the same device) that embeds no outstanding
features and are widely available for purchase at low-cost.
Moreover, such devices either lack the appropriate tools or
present an inflexible proprietary software solution that makes
it hard to develop the required level of automation and control.
This paper introduces an approach that orchestrates a pool
of WLAN resources belonging to different owners with the
aim of allocating them to tenants as virtual networks that can
be independently controlled. Such a solution benefits service
providers willing to offer connectivity (and other network
services) to their costumers but which lack the means to
978-1-5090-3599-1/17/$31.00 c
2017 IEEE
maintain the necessary infrastructure. As our solution will
rely heavily on the SDN approach [4] and be implemented
using low cost switches commonly employed by end users
and Internet service providers, we also preliminarily evaluate
the network performance of these devices in supporting the
OpenFlow technology [5].
The remainder of this paper is organized as follows: The
next section presents our approach to slicing customer WLAN
networks; Section III presents related work, while section IV
discusses preliminary results regarding the WLAN switches
assessment, followed by the conclusions.
II. SLICING CUSTOMER WIRELESS NETWO RK S
We argue that network virtualization can efficiently support
the WLAN resources unlocking, allowing them, through ade-
quate business models, to be shared among the general public,
instead of being restricted to household users as it occurs
today. Going beyond the provisioning of basic wireless con-
nectivity, the ability to create network slices (virtual networks)
that coexist on the same access infrastructure, allows providing
isolation and service differentiation for applications. Along
with this, for added flexibility, each virtual network operator
could independently manage the elements and resources inside
a slice.
A. Slice Representation
The slice representation described below implies the fol-
lowing business model: The infrastructure provider, which
owns the network infrastructure and is responsible for the
management of the lifecycle of virtualized networks (pro-
visioning, management, and termination), the tenant (virtual
network operator) that shares the physical infrastructure with
other tenants and offers Internet connectivity for its customers,
end-users and devices. At our approach the Internet service
provider (ISP) plays the infrastructure provider’s role as it
offers the infrastructure (including last mile and even last
hundred meters infrastructure) that allows WLANs to connect
to Internet.
By employing network virtualization the infrastructure
provider creates slices according to the tenant’s needs and
exposes convenient network abstractions that allow the control
of virtualized network elements, as would occur in a private
physical network. Two factors are considered, regarding the
way a slice is presented to the tenant: firstly, the decision
about the type of virtual network elements that should be
present in the slice, and secondly, how a tenant is able to
interact with them. Regarding the latter, in our approach
the network elements belonging to the slice expose well-
known SDN interfaces like OpenFlow and OVSDB [6], so
the tenants do not need to invest in new APIs. Regarding
the former, the following network elements can compose the
slice: the virtual access points (VAPs), a virtual switch, and
virtual network functions (VNFs) [7], as depicted in Fig.1. The
presence of the VAPs in the slice provides the tenant with the
means to configure the (virtual) access points according to
Fig. 1: Slice abstraction: a virtual SDN.
established requirements, allowing, for instance, the configu-
ration of WLAN specific aspects such as authentication, or
connectivity enablement at a given geographical location. The
tenant can offer specific network services towards customers
(nodes requiring connectivity) in its slice through VNFs that
are deployed on specialized servers located at the ISP (since
the ISP can offer cloud services) and from third-parties in
the Internet. Indeed, such functions can even be placed at the
costumer networks, as proposed in [8] and [9] where domestic
equipment (such as Set Top Boxes) composes a FOG system
[10] to provide on-demand services and VNFs to support IoT
applications. To enable VNF forward chaining [11], i.e., the
ordered list of network functions through which a flow must
cross, the tenant can employ a centralized virtual switch. Once
it connects VAPs and VNFs, the tenant can program it, through
SDN API, to direct selected arriving flows to the appropriate
VNFs (more details in the next subsection). From the tenant
viewpoint, the virtual switch is also a convenient construct
to perform broadcast communication. It could be useful, for
instance, in IoT communication scenarios where multiple
devices need to receive the same message (e.g. configuration
commands).
The mapping between the virtual and physical network
elements can be a 1-to-n relationship, where a single virtual
switch or AP is mapped to several physical elements, or a n-
to-1, where 1 physical element can host several virtual APs.
The mapping is hidden from the tenant, who only sees and
interacts with the allocated virtual elements.
Alternatively, the APs could be abstracted away to restrict
all the slice control and configuration to the virtual switch. It
would be still possible for the tenant to have some indirect
control over the APs, once the appropriate semantics are
present. For instance, if the tenant wanted to stop offering
connectivity for nodes at a given physical place it could disable
the appropriate switch port. By doing so the entity responsible
for the virtualization would contact the physical AP(s) mapped
to that port and request to turn down the slice presence at that
location. As aforementioned, the reason for exposing the AP
elements at the slice is to allow the tenant to have control over
WLAN specific parameters.
The main reasons for allowing the VAP to correspond to
multiple physical APs are: first, the choosing of the most
appropriate physical APs to form the slice is complex in
different scenarios. Due to factors such as node mobility and
fluctuation of WLAN conditions along time, connectivity con-
ditions cannot be guaranteed. Second, the main focus lies in
the connectivity experienced by the nodes, deeming irrelevant
which AP offers the service. For instance, in data offloading
scenarios, once the service availability area is established (e.g.,
downtown, a public crowd event, etc.) what matters most for
the tenant is the amount and quality of data offloaded through
WLAN, and not knowledge of the exact APs that provided
the service. Therefore, the abstraction allows the tenant to
more effectively reach its nodes, since the virtualization layer,
which has the complete vision of all underlying networks
and their conditions, is responsible for choosing the most
appropriate APs (when choice is possible). The mapping also
provides resilience to failure through redundancy. In case of
AP malfunction, nodes can be reattached to APs nearby, hiding
the failure from the tenant. In addition, a slice abstraction
that exposes all physical APs to the tenant can be complex to
manage due to the large number of network elements. Besides,
the flexibility of mapping allows innovative solutions to be
conceived. For instance, a node that moves away from the
reach of its virtual wireless network could be reconnected to
it after the system perceives its presence at the new place
and extends the virtual network to incorporate nearby physical
AP(s) apt to provide the required connectivity.
B. Slice Management
Fig.2 depicts our preliminary approach for slice manage-
ment. Through slice specification parameters (e.g., WLAN
coverage, AP location, QoS parameters, etc.) the tenant re-
quires the slice creation. A network virtualization layer is
responsible for creating, managing and presenting the slice
abstraction to the tenant. Specifically, the virtual network
manager (VNM) selects the APs that fit the slice requirements
from a database that holds physical network information (such
as the AP location and WLAN capabilities), and configures
them to be part of the slice. It is also responsible for the
management of aspects not directly concerned to abstractions
such as recovery from AP failures (for instance, by selecting
a working AP nearby, configuring the slice parameters on it,
and redirecting the nodes to there).
The AP proxy acts as an intermediary between the tenant’s
controller and the physical APs. It intercepts controller-to-
switch messages, maps the virtual AP identified in the message
to the corresponding physical AP(s), and replicates the mes-
sage to them (Fig.3). In addition, the component also performs
control plane isolation, i.e., it avoids that a particular controller
overuses network resources such as physical CPU, buffers, and
bandwidth, enforcing a fair sharing of these resources among
tenants. It does this by establishing a threshold to the rate of
control messages that the tenants can send to the APs.
Fig. 2: A general approach for slice management.
Fig. 3: A Virtual AP mapped to two physical APs. OpenFlow
messages from the controller are replicated to reflect the
mapping.
A dedicated network virtualization layer per slice improves
scalability in cases where the slice covers huge areas with
hundreds of APs. It also improves robustness, as failure at
any component of the layer does not affect other slices.
The AP slice manager (ASM) instance runs on each AP
and is responsible for analyzing controller-to-switch messages
and applying them to the appropriate slice. For instance, if the
tenant requires that all UDP packets be dropped at the AP, the
ASM will apply that policy only to packets belonging to the
specific tenant’s slice. In this way, UDP packets belonging to
other slices will not be affected at that AP. It is also in charge
of identifying to which slice packets arriving from mobile
nodes belong. As there is a controller for each instantiated
slice, ASM must decide, for instance, the destination of a
packetIn OpenFlow message. Also, the ASM is responsible for
configuring WLAN parameters such as SSIDs and authentica-
tion methods per slice. Another responsibility of the ASM is
the continuous monitoring of the AP resources utilization such
as bandwidth, and flow tables. This measurement is essential
for deciding, for instance, whether the AP is able to support
an additional slice or the amount of resources that can be
provisioned to a particular one.
Alternatively, the ASM functions could be performed by an
instance located at a dedicated server, outside the AP. We opt
for deploying the ASM at the AP because the choice presents
Fig. 4: The use of a virtual switch to support VNF service
chaining.
key advantages: the AP monitoring function does not consume
network resources to perform its tasks (the monitoring module
isn’t located at a remote site); the choice scales easily, as the
load associated to ASM procedures is distributed among the
APs; failures at the ASM module only impact the AP where
it is installed; Conversely, failure at the dedicated server could
render hundreds of APs useless.
As aforementioned the virtual switch supports the network
service chaining logic for VNFs. To send packets through a
service chaining the tenant directs them to the virtual switch by
installing the appropriate flows (rules) at the VAPs. Through
this, packets arriving from VAPs are directed to the ports
where VNF virtual machines are connected. In this way
packets traverse the desired path before leaving the switch
towards their final destination (see Fig.4). Tunnels can be
deployed between the VAP and the virtual switch in order to
support traffic steering between these elements. In this case,
the tenant would perceive at least two ports at each VAP; one
associated to the tunnel itself and another to normal traffic (for
packets that don’t need VNF services). Taking into account
the topology represented in Fig.4, if the tenant intends, for
instance, that HTTP traffic be directed to VNF1 before leaving
the slice, it should issue a flow modification control message
to the virtual switch specifying that TCP packets destined
to port 80 coming from a given tunnel should be directed
to the switch’s port 1. At the VAP the tenant would install
a flow to redirect these packets to the tunnel’s port, while
the remainder packets (unrelated to service chaining) follow
the path established by conventional routing, without passing
through the virtual switch. By only directing to the switch
traffic that needs to participate on the service chaining, the
design avoids unnecessary delay penalties for other flows.
III. REL ATED WORK
Several existing works highlight important issues addressed
on this paper, albeit differently. Commercial solutions like
FON propose to open the closed Wi-Fi resources to the general
public, by allowing users to connect to the FON network
whenever it is available. In [12] authors propose a mechanism
to allow fair sharing of access network among different users.
The goal in both solutions is to offer connectivity to end users
by sharing the access networks, but without taking into account
advanced needs of applications such as QoS requirements or
seamless connectivity. Although the work in [13] proposes to
slice the home network, its focus is restricted to managing
network resources to provide better services to the household
such as reserve bandwidth for specific domestic equipment.
The solution disregards the problem of efficiently sharing
WLAN resources for the general public. Consequently, the
slice concept has a much more restricted scope than in our
approach. In [14] authors present an architecture that, through
network-assisted mobility management mechanisms, aims at
choosing the most appropriate WLAN for mobile nodes in
terms of QoS guarantees and optimal network resources usage.
Although the solution heavily depended on SDN to perform
flow monitoring and selectively admit new flows, no study
was conducted to evaluate the suitability of low-cost WLAN
devices in supporting SDN. Similar works that explore SDN
on WLAN devices to better control these networks also lack
a similar evaluation.
None of the above proposals offers virtualized networks
as a service or any other flexible abstraction that allows
different tenants to share network resources and have full
control over the allocated resources at the access and last mile
network premises. On the other hand, network virtualization
supported by SDN [15], [16], [17], [18] is a popular topic
on cloud networking, with the FlowVisor network hypervisor
[19] being the seminal work in the field. Authors in [20]
present a comprehensive survey showing the main character-
istics and differences among existing proposals. Specifically,
architectures that employ distributed network hypervisors to
scale better in face of complex infrastructure or that employ
network elements with improved capabilities to help on the
virtualization process are the closest to our architecture. The
solution presented in [21] deploys the network hypervisor
inside the switch element to reduce the control messages delay
caused by the addition of the intermediary network hypervisor
between the controller’s server and switch. On the other hand,
the solution limits the possibilities to present fully virtualized
topologies, since the tenant directly interacts with the physical
switches of interest, being aware of its existence. Our proposal
differs from these previous works in a sense that it is focused
on ISP and WLANs, instead of cloud networks, and is aimed
at the issues implied on this environment such as low capacity
and lack of robustness of APs devices, nodes mobility, coexis-
tence of scenarios with varied complexity (e.g., the same low-
cost network device should support simple elastic background
traffic and QoS sensitive flows that need to be steered through
a chaining of network functions before leaving the network),
and fluctuations of the network conditions.
IV. TES TB ED EX PE RI ME NTATI ON
As our approach relies on commodity-based devices to
support slice services, we conducted a set of experiments on a
real testbed featuring OpenFlow enabled equipment with the
TABLE I: Low Cost Testbed Switches
Network node platform CPU RAM
Mikrotik Router BOARD 951G-2HnD Ateros 600MHz 128 MB
TP-Link TL-WR1043ND HW V1 Ateros 400MHz 32 MB
TP-Link TL-WR1043ND HW V3 Ateros 720MHz 64 MB
aim of assessing how the OpenFlow software layer operations
impact on the performance of the corresponding devices. We
employed three different switch models featuring commodity-
based configurations (detailed in Table I), typically available
in the market and used by both ISPs and home users for Wi-Fi
wireless access. On all three devices we replaced the original
firmware with the OpenWRT operating system and installed
Open vSwitch [6] to enable OpenFlow v.1.3 functionalities at
the kernel level.
The testbed consisted of a switch connecting, via 100 Mbps
Ethernet interfaces, two machines, one used to generate traffic
and host the switch’s controller, and the other to sink the
generated traffic. We employed an in-band control channel
as it represents a realistic scenario in our context (out-band
channel to control the customers’ wireless switches seems
unpractical). The D-ITG tool [22] was employed at the client
side to generate UDP flows at a constant rate of approximately
410 Kbps each for 60 seconds for the purpose of calculating
the one-way delay (OWD), packet loss and throughput. The
experiment started with 74 UDP flows and this number was
increased to obtain the desired load (30, 60, 90 and 120 %).
We employed the Ryu framework to build a controller that
installed a new OpenFlow rule for each UDP flow as they
arrived to the switch. As D-ITG uses a different source port for
each flow it generates, the installed rules match the respective
UDP source port field values. In this way we certificate that
the controller is contacted every time a new UDP flow arrives.
The action of all rules is the same: to forward the packets to the
D-ITG server. We envisage scenarios where a WLAN switch
supports several virtual networks and tenants can individually
control the flows they own. As so, we employed multiple
flows (ranging from 74 to 293, according to the offered
load) at the tests and performed a per-flow control to have
an evaluation setting that represents an extreme case of the
conditions an implementation of our approach will face. We
compared the average OWD of all flows as a function of
the offered load in two different settings: OpenFlow-enabled
and OpenFlow-disabled switches (Fig.5). OF-enabled switches
performed worst mainly due to the time the first packets of
each flow have to wait at incoming buffers before the controller
installs the forwarding rules. Also, as expected, the switch
with higher power processing (TP-Link V3) performed better,
especially when OpenFlow was enabled.
Fig.6 shows the throughput and respective packet loss
for the same experiment. At 60 Mbps of offered load the
throughput at the OF-enabled TP-Link V3 corresponds to 95%
of the throughput from the same switch with OF-disabled.
For the Mikrotik the throughput is 91% of the OF-disabled
corresponding switch. For an offered load of 90Mbps both
Fig. 5: OWD comparison: devices with OF functionality
enabled and disabled.
switches suffered a considerable throughput decrease, with TP-
Link V3 reaching 45.9Mbps, which represents 55% of the OF-
disabled switch throughput. The TP-Link V3, the switch that
has more power processing, performed better in all cases.
We also performed a comparison between TP-Link V1
and its successor, TP-Link V3, to perceive how the hard-
ware evolution could increase the OpenFlow performance.
As depicted in Fig.7, the improvements are considerable.
While TP-Link V1 sustained a maximum throughput of only
28.2 Mbps its successor reached 55.3 Mbps. For 60% of
offered load the packet loss at the V1 was already above
53% while at version V3 was below 4.6%. The evaluation
conducted by [23] and focused at the performance analyses
of the TP-Link V1 corroborates our findings, although in our
experiment the switch got a throughput about 40% higher.
We think improvements on the latest versions of OVS and
Ryu frameworks could explain the difference. Moreover, by
our experiment it is clear that improvements at hardware
level, without a necessary increase of monetary cost, can
substantially enhance the SDN support in this kind of low-cost
equipment. We believe further enhancements both in software
and hardware will allow for devices that support OpenFlow
with minor performance penalties in the near future.
Results show that there is a trade-off between control capac-
ity and network performance. On the one hand the logically
centralized control brought by SDN is highly desirable and
considered fundamental to unlock the potential of the WLANs
to the Internet of Everything (IoE). On the other hand the
deployment of an open source SDN solution at low-cost equip-
ment is not free from performance penalties. Nevertheless,
it is suitable enough to support different scenarios ranging
from web surfing to crowdsourcing applications to device-to-
device communication to multimedia applications, although
the existing resources like link capacity can’t be explored to
full extent. Moreover, measurements can be taken to improve
the OF-enabled devices performance. Although we employ an
in-band control channel, QoS mechanisms can be configured
to give priority to controller messages at a hop before the
Fig. 6: Packet loss and throughput as a function of offered load.
Fig. 7: Performance comparison between TP-Link V1 and V3.
switch (at the ISP premises, for instance) and the same can
be done at the WLAN switch for messages directed to the
controller.
V. CONCLUSION AND FUTURE WORK
The concept of slices as virtual SDNs tailored for specific
applications or scenarios has gained traction in the last years
and is considered one of the key concepts for the realization of
the upcoming 5G networks. We argue that extending this con-
cept to the access and customer networks can bring great op-
portunities in terms of efficiently sharing the WLAN resources
among diverse applications and end users. In current literature
the concept of slice is open and conveys different meanings.
For this work, a network slice is defined as a virtual SDN
(vSDN), i.e., a network composed of virtual elements, their
connections and managed by an SDN controller. This paper
introduced an approach to allow internet service providers to
create slices over commodity wireless network devices based
on SDN technology and presented preliminary tests indicating
that, although the OpenFlow architecture imposes performance
constraints, these devices can at a great extend offer the SDN
support needed by our slicing approach. Our next step is to
implement a prototype of our framework and realize tests to
analyze key performance parameters such as the overall cost
of the virtualization layer, performance of recovery from AP
failure, VNF service chaining penalties, and the efficiency in
distributing the network resources among the slices.
ACKNOWLEDGMENT
This work was partially supported by the SMART (CNPq
Universal grant number 457051/2014-0) and Smart Metropo-
lis research projects. The authors would like to thank the
Coordination for the Improvement of Personnel in Higher
Education (CAPES), the National Council for Scientific and
Technological Development (CNPq) and the Fundac¸ ˜
ao de
Amparo `
a Pesquisa do Estado de Mato Grosso (FAPEMAT).
Experiments were carried out at NPITI/UPLab of Instituto
Metropole Digital (IMD).
REFERENCES
[1] J. G. Andrews, S. Buzzi, W. Choi, S. V. Hanly, A. Lozano, A. C. Soong,
and J. C. Zhang, “What will 5g be?” IEEE Journal on Selected Areas
in Communications, vol. 32, no. 6, pp. 1065–1082, 2014.
[2] C. V. N. Index, “Global mobile data traffic forecast update, 2015-2020,
feb. 2016.”
[3] N. Alliance, “5g white paper,” Next generation mobile networks, white
paper, 2015.
[4] B. A. A. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, and
T. Turletti, “A survey of software-defined networking: Past, present, and
future of programmable networks,” IEEE Communications Surveys &
Tutorials, vol. 16, no. 3, pp. 1617–1634, 2014.
[5] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,
J. Rexford, S. Shenker, and J. Turner, “Openflow: enabling innovation in
campus networks,” ACM SIGCOMM Computer Communication Review,
vol. 38, no. 2, pp. 69–74, 2008.
[6] B. Pfaff, J. Pettit, T. Koponen, E. J. Jackson, A. Zhou, J. Rajahalme,
J. Gross, A. Wang, J. Stringer, P. Shelar et al., “The design and
implementation of open vswitch.” in NSDI, 2015, pp. 117–130.
[7] R. Mijumbi, J. Serrat, J.-L. Gorricho, N. Bouten, F. De Turck, and
R. Boutaba, “Network function virtualization: State-of-the-art and re-
search challenges,” IEEE Communications Surveys & Tutorials, vol. 18,
no. 1, pp. 236–262, 2016.
[8] F. Ramalho and A. Neto, “Virtualization at the network edge: A
performance comparison,” in World of Wireless, Mobile and Multimedia
Networks (WoWMoM), 2016 IEEE 17th International Symposium on A.
IEEE, 2016, pp. 1–6.
[9] F. Ramalho, “SmartEdge: Fog Computing Cloud Extensions to Support
Latency-Sensitive IoT Applications,” Master’s thesis, DiMAP - Univer-
sidade Federal do Rio Grande do Norte, Brasil, 2016.
[10] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its
role in the internet of things,” in Proceedings of the first edition of the
MCC workshop on Mobile cloud computing. ACM, 2012, pp. 13–16.
[11] J. Halpern and C. Pignataro, “Service function chaining (sfc) architec-
ture,” Tech. Rep., 2015.
[12] V. Sivaraman, T. Moors, H. Habibi Gharakheili, D. Ong, J. Matthews,
and C. Russell, “Virtualizing the access network via open apis,” in
Proceedings of the ninth ACM conference on Emerging networking
experiments and technologies. ACM, 2013, pp. 31–42.
[13] Y. Yiakoumis, K.-K. Yap, S. Katti, G. Parulkar, and N. McKeown,
“Slicing home networks,” in Proceedings of the 2nd ACM SIGCOMM
workshop on Home networks. ACM, 2011, pp. 1–6.
[14] F. S. D. Silva, A. V. Neto, D. Maciel, J. Castillo-Lema, F. Silva,
P. Frosi, and E. Cerqueira, “An innovative software-defined winemo
architecture for advanced qos-guaranteed mobile service transport,”
Computer Networks, vol. 107, pp. 270–291, 2016.
[15] N. M. K. Chowdhury and R. Boutaba, “A survey of network virtualiza-
tion,” Computer Networks, vol. 54, no. 5, pp. 862–876, 2010.
[16] D. Drutskoy, E. Keller, and J. Rexford, “Scalable network virtualization
in software-defined networks,” IEEE Internet Computing, vol. 17, no. 2,
pp. 20–27, 2013.
[17] A. Blenk, A. Basta, and W. Kellerer, “Hyperflex: An sdn virtualization
architecture with flexible hypervisor function allocation,” in Integrated
Network Management (IM), 2015 IFIP/IEEE International Symposium
on. IEEE, 2015, pp. 397–405.
[18] A. Al-Shabibi, M. De Leenheer, M. Gerola, A. Koshibe, G. Parulkar,
E. Salvadori, and B. Snow, “Openvirtex: Make your virtual sdns pro-
grammable,” in Proceedings of the third workshop on Hot topics in
software defined networking. ACM, 2014, pp. 25–30.
[19] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McK-
eown, and G. Parulkar, “Flowvisor: A network virtualization layer,”
OpenFlow Switch Consortium, Tech. Rep, pp. 1–13, 2009.
[20] A. Blenk, A. Basta, M. Reisslein, and W. Kellerer, “Survey on network
virtualization hypervisors for software defined networking,” IEEE Com-
munications Surveys & Tutorials, vol. 18, no. 1, pp. 655–685, 2016.
[21] R. Doriguzzi-Corin, E. Salvadori, M. Gerola, M. Su˜
n´
e, and H. Woesner,
“A datapath-centric virtualization mechanism for openflow networks,” in
Software Defined Networks (EWSDN), 2014 Third European Workshop
on. IEEE, 2014, pp. 19–24.
[22] S. Avallone, S. Guadagno, D. Emma, A. Pescape, and G. Ventre, “D-
itg distributed internet traffic generator,” in Quantitative Evaluation of
Systems, 2004. QEST 2004. Proceedings. First International Conference
on the. IEEE, 2004, pp. 316–317.
[23] L. Lima, D. Azevedo, and S. Fernandes, “Performance evaluation of
openflow in commodity wireless routers,” in Network Operations and
Management Symposium (LANOMS), 2015 Latin American. IEEE,
2015, pp. 17–22.
