Embed Size (px)
Citation preview
IC – Instituto de Computação
UNICAMP – Universidade de Campinas
http://www.ic.unicamp.br/~edmundo
Campinas, 9 de março de 2018
Edmundo Madeira
Alguns Tópicos de Pesquisa em Computação em Nuvens e Névoas,
Redes Veiculares e 5G
Arquitetura: Nuvem – Névoa – Rede Veicular
Orquestradores: Nuvem - Névoa
Projetos
• Orquestração de Serviços em Névoas Computacionais para Aplicações Hadoop/Spark/HPAT em Nuvens Híbridas
• Incerteza na largura de banda disponível entre nuvens e névoas
• Migração Proativa de Máquinas Virtuais entre Névoas Computacionais
• Virtualização de redes LTE usando SDN e NFV
• Gerência de slices em redes 5G
Orquestração de Serviços em Névoas Computacionais para Aplicações
Hadoop/Spark/HPAT em Nuvens Híbridas
An Architecture for Orchestrating Hadoop Applications in Hybrid Cloud
HM – Hadoop Master NodeHW – Hadoop Worker Nodes
Incerteza na largura de banda disponível entre nuvens e névoas
Proposed Mechanism
SORTS September 2016 Coimbra F2F Meeting - 8
SORTS
Calculates a deflated available bandwidth to the scheduler by using a multiple linear regression technique
f(x,y) = ax + by +c- x: current predict uncertainty- y: currently available bandwidth- f(x,y): deflated available bandwidth
Migração Proativa de Máquinas Virtuais entre Névoas Computacionais
Virtual Machine Migration Scenario
An adaptive mechanism for LTE P-GW virtualization using SDN and NFV
P-GW user-plane virtualization
• OpenFlow switches• Hardware: high
processing capacity but small tables
• Software: large tables but slow processing capacity
User plane
Control plane
S1-U S5/S8 SGi
S11
S6a
Gx
X2
Uu
Uu
Internet
PCRFHSS
eNBu
eNBc
eNBu
eNBc
UE
UE
X2
MME
S-GWu Backhaul P-GWu S5/S8
EPC controller
P-GWcS-GWc
S1-MME
User traffic
Control signalling
OpenFlow protocol
Fig. 2. The adopted Software Defined Mobile Networking (SDMN) architecture.
user plane [19]. A network operator may face performance
limitations when implementing these functions in software,
especially because transferring packets between kernel and
userspace is a costly operation [16]. This constraint motivated
the decision to implement S/P-GWu using OpenFlow switches
rather than generic VNF in software. On the S/P-GWu,
OpenFlow logical ports are used to de/encapsulate the GTP
traffic so that the gateways can match and perform required
action on top of encapsulated IP user packets. On this SDMN
architecture, all S/P-GWu operations are implemented using
standard OpenFlow instructions, actively supported by the set-
field action and by the OpenFlow eXtensible Match (OXM)
metadata field carried between logical ports.
With this approach, the gateways can still be modeled as
VNFs running on top of virtual OpenFlow switches (like
the Open vSwitch, which offers an optimized implementation
for packet forwarding in kernel space [21]). However, as an
alternative, it is possible to deploy this same architecture using
hardware OpenFlow switches, which are designed to ensure
packet processing at line rate. On the other hand, hardware
switches have limited number of entries in its internal pipeline
tables. This restriction is usually associated with higher
costs for implementing Ternary Content-Addressable Memory
(TCAM) on hardware. So, selecting among a hardware of
software switch platform is a trade-off that depends on the
network requirements and available infrastructure.
Particularly, the central point of this paper is the adaptive
mechanism for P-GWu virtualization that can meet different
traffic load requirements while overcoming previously dis-
cussed limitations, regardless of using software or hardware
OpenFlow switches.
V. P-GW USER PLANE VIRTUALIZATION
On the user plane, the heaviest P-GW task is the filtering of
downlink user IP packets into the different QoS-based bearers
using TFTs. The TFTs use L3 and L4 header fields to filter
packets so that each one can be sent down to the individual
bearers. When using OpenFlow protocol to implement TFT
filtering, at least one flow entry must be installed at the
P-GWu for each active bearer. Considering that a UE can
have some dedicated bearers other than the default bearer,
and considering that each bearer can convey the traffic from
different applications, the total number of flow entries on the
P-GWu is prone to grow quickly. Despite the flexibility offered
by the adopted SDMN architecture, implementing the P-GWu
with a single OpenFlow switch is not realistic. Therefore, the
P-GWu virtualization employs the elastic computing concept,
so computing resources can be scaled up and down easily
whenever required.
A. The P-GWu internal design
Fig. 3 shows the P-GWu internal design. No matter whether
using hardware or software platform, a pool of OpenFlow TFT
switches is required to accommodate all flow entries. When
using software-based TFT switches (Fig. 3a), the table size
may not be the problem, but asingle virtual appliance probably
will not be able to handle all the traffic load. When using
hardware-based TFT switches (Fig. 3b), individual flow tables
will get full soon, even when there is available processing
capacity for use.
Besides, the P-GWu design also requires a pair of uplink
(UL) and downlink (DL) OpenFlow switches with the single
purpose of redirecting the traffic of each UE to the proper TFT
switch. Ensuring that all the traffic of a single UE is processed
at the same TFT switch allows the P-GWc to query for traffic
P-GWu
DL HW
switch
UL HW
switch
TFT SW pool
S5/S8 SGi
(a) Software-based TFT switches.
P-GWu
DL HW
switch
UL HW
switch
TFT HW pool
S5/S8 SGi
(b) Hardware-based TFT switches.
Fig. 3. The P-GWu internal design.
Simulationscenario
S-GWu
S-GWu
S-GWu
S-GWu
S-GWu
EPC controller
P-GWcS-GWc
Internet
P-GWu
OpenFlowbackhaul network
ns-3 simulator + OFSwitch13 OpenFlow 1.3 module for ns-3 (developed at Unicamp)
Ring network, 5 cell sites, 100 to 500 UEs, 4 apps with different QoS.
TF
T a
vg
. lo
ad
(%
)0
20
40
60
80
100
Block none Block GBR Block all
GBR bearers
Non-GBR bearers
(a) P-GWu traffic load.
Blo
ck r
atio (
%)
0
20
40
60
80
100
Block none Block GBR Block all
(b) P-GWu overloaded block ratio.
Pa
cke
t d
rop
s (
%)
0
20
40
60
80
100
Block none Block GBR Block all
(c) P-GWu overloaded packet drops.
Fig. 4. Simulation results for three different blocking strategies.
VI. P-GWU PERFORMANCE EVALUATION
A. Simulation scenario
The simulation scenario was implemented in the Network
Simulator 3 (ns-3) using the OFSwi t ch13 module1. Due
to CPU and memory limitations for performing large-scale
LTE simulations on ns-3, a reduced simulation scenario was
adopted, as illustrated in Fig. 5. The backhaul network is
composed of 6 OpenFlow switches in a ring topology, con-
nected by Gigabit Ethernet full-duplex links. The ring was
chosen as most of the legacy backhaul networks have a ring
access topology, and it is one of the most efficient approaches
regarding protection and costs. The P-GWu and 5 LTE sites
are connected to the ring switches. Each site has three eNBs
and its own S-GWu. The eNBs are laid out on a hexagonal
grid with an inter-site distance of 500 meters. Fig. 6 shows the
Radio Environment Map (REM), which represents the Signal-
to-Interference-plus-Noise Ratio (SINR) in the downlink with
respect to the eNB that has the strongest signal at each point.
The UEs, ranging from 100 to 400 on this scenario, are
randomly scattered over all the coverage area.
As LTE networks focus on Voice over IP (VoIP) and
multimedia applications, four applications are used during the
1This module enhances the ns-3 with OpenFlow 1.3 technology. It wasdeveloped by the authors of this paper and it is described in [22].
S-GWu
S-GWu
S-GWu
S-GWu
S-GWu
EPC controller
P-GWcS-GWc
Internet
P-GWu
OpenFlow
backhaul network
Fig. 5. The simulation scenario topology.
simulations to provide five different types of traffic flows with
different QoS requirements. They are: a HyperText Transfer
Protocol (HTTP) application for web page access mapped
to QoS Class Identifier (QCI) 9; a VoIP conversation with
call length expected to 100 seconds over UDP protocol and
mapped to QCI 1; a live MPEG-4 video streaming over
UDP protocol and mapped to QCIs 2 or 7; and a buffered
MPEG-4 video streaming over TCP protocol and mapped
to QCI 6 (videos with expected length to 90 seconds). UEs
can request for randomly dedicated bearer context activations,
with individual requests following a Poisson Process with rate
λ = 0.3̄ requests per minute.
Table I shows theP-GWu parameter values used for the sim-
ulations, adjusted to reflect the proportionality of the scenario.
The P-GWu was modeled considering both software and hard-
ware OpenFlow platforms. Hence, simulations use different
flow table size and traffic processing capacity values for each
TABLE IPARAMETERS FOR P-GWU OPENFLOW SWITCH MODELLING.
Parameter Hardware Software
Flow table size 1200 4096Processing capacity 1Gbps 100MbpsTFT switches 1, 2 or 4Split threshold 90%Join threshold 30%
0
100
200
300
400
500
600
700
800
900
0 200 400 600 800 1000 1200 1400
y-c
oo
rdin
ate
(m
)
x-coordinate (m)
-5
0
5
10
15
20
SIN
R (
dB
)
1
1,2 ,3 4,5 ,6
7,8 ,9 10,11,12 13,14,15
Fig. 6. The REM for the simulation scenario.
Gerência de slices em redes 5G
Slicing em 5G
• Video Transmission over VANETs
• QoE Optimization for Video streaming over 5G slices
• Video Streaming in Large-Scale Heterogeneous 5G Networks in Smart Cities
