Available online at www.sciencedirect.

com
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com

ScienceDirect
Procedia
Procedia Computer
Computer Science
Science 11000 (2017)
(2017) 000–000
328–335
Procedia Computer Science 00 (2017) 000–000 www.elsevier.com/locate/procedia
www.elsevier.com/locate/procedia

The
The 12th
12th International
International Conference
Conference on
on Future
Future Networks
Networks and
and Communications
Communications
(FNC-2017)
(FNC-2017)
Automatic
Automatic monitoring
monitoring management
management for
for 5G
5G mobile
mobile networks
networks
a,∗ a
Alberto
Alberto Huertas
Huertas Celdrán
Celdrána,∗,, Manuel
Manuel Gil
Gil Pérez
Péreza ,, Félix
Félix J. Garcı́a Clementebb , and
a J. Garcı́a Clemente , and
Gregorio
Gregorio Martı́nez
Martı́nez Pérez
Péreza
a Dept. Ingenierı́a de la Información y las Comunicaciones, University of Murcia, 30071 Murcia, Spain
a Dept. Ingenierı́a de la Información y las Comunicaciones, University of Murcia, 30071 Murcia, Spain
b Dept. Ingenierı́a y Tecnologı́a de Computadores, University of Murcia, 30071 Murcia, Spain
b Dept. Ingenierı́a y Tecnologı́a de Computadores, University of Murcia, 30071 Murcia, Spain

Abstract
Abstract
5G mobile networks are pushing new dynamic and flexible scenarios that require the automation of the management processes
5G mobile networks are pushing new dynamic and flexible scenarios that require the automation of the management processes
performed by network administrators. To this end, Self-Organizing Networks (SON) arose with the goal of moving from traditional
performed by network administrators. To this end, Self-Organizing Networks (SON) arose with the goal of moving from traditional
manual management processes towards an automatic and dynamic perspective. The orchestration of the monitoring services is
manual management processes towards an automatic and dynamic perspective. The orchestration of the monitoring services is
an essential task to conduct self-configuration, self-healing, and self-optimization processes required by SONs. In this context,
an essential task to conduct self-configuration, self-healing, and self-optimization processes required by SONs. In this context,
we propose a solution that efficiently orchestrates the monitoring services by managing the network resources automatically. In
we propose a solution that efficiently orchestrates the monitoring services by managing the network resources automatically. In
particular, we propose a 5G-oriented architecture that integrates the Software Defined Networking (SDN) and Network Functions
particular, we propose a 5G-oriented architecture that integrates the Software Defined Networking (SDN) and Network Functions
Virtualization (NFV) technologies to monitor and orchestrate the whole life-cycle of monitoring services considering information
Virtualization (NFV) technologies to monitor and orchestrate the whole life-cycle of monitoring services considering information
of the network control plane.
of the network control plane.
c 2017 The Authors. Published by Elsevier B.V.

©c 2017
2017 The
TheAuthors.
Authors.Published
PublishedbybyElsevier
ElsevierB.V.
B.V.
Peer-review under responsibility of the Conference Program Chairs.
Peer-review under responsibility of the Conference Program Chairs.
Keywords: Network monitoring; Software Defined Networking; Virtualization; Orchestration; 5G mobile networks
Keywords: Network monitoring; Software Defined Networking; Virtualization; Orchestration; 5G mobile networks

1. Introduction
1. Introduction
The evolution of technologies has provoked a radical change in mobile networks and, therefore, in their internal
The evolution of technologies has provoked a radical change in mobile networks and, therefore, in their internal
management processes. Nowadays, the incoming fifth generation (5G) of mobile networks is pushing new scenarios
management processes. Nowadays, the incoming fifth generation (5G) of mobile networks is pushing new scenarios
in which dynamism and flexibility are essential aspects. These new scenarios are characterized when considering
in which dynamism and flexibility are essential aspects. These new scenarios are characterized when considering
several Key Performance Indicators (KPIs) 11 , defined by the 5G Public Private Partnership (5G-PPP). Among these
several Key Performance Indicators (KPIs) , defined by the 5G Public Private Partnership (5G-PPP). Among these
indicators, the number of connected devices (from 10 to 100 times), the volume of mobile data per geographical area
indicators, the number of connected devices (from 10 to 100 times), the volume of mobile data per geographical area
(1000 times higher), the end-to-end latency (less than 1ms), and ubiquitous 5G access including low density areas are
(1000 times higher), the end-to-end latency (less than 1ms), and ubiquitous 5G access including low density areas are
some of the most relevant aspects that influence the evolution from traditional to future mobile networks.
some of the most relevant aspects that influence the evolution from traditional to future mobile networks.
This new situation requires the automation of the management processes performed by network administrators. In
This new situation requires the automation of the management processes performed by network administrators. In
this sense, Self-Organizing Networks (SON) arose with the goal of moving forward from traditional manual manage-
this sense, Self-Organizing Networks (SON) arose with the goal of moving forward from traditional manual manage-
ment processes towards an automatic and dynamic perspective. To reduce the network management complexity, the
ment processes towards an automatic and dynamic perspective. To reduce the network management complexity, the

∗ Corresponding author. Tel.: +34-868-88-4644.

∗ Corresponding author. Tel.: +34-868-88-4644.
E-mail address: alberto.huertas@um.es
E-mail address: alberto.huertas@um.es
1877-0509 c 2017 The Authors. Published by Elsevier B.V.
1877-0509 c 2017 The Authors. Published by Elsevier B.V.
Peer-review under responsibility of the Conference Program Chairs.
Peer-review©under
1877-0509 2017responsibility
The Authors. of the Conference
Published Program B.V.
by Elsevier Chairs.
Peer-review under responsibility of the Conference Program Chairs.
10.1016/j.procs.2017.06.102
 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335 329
2 A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000

Software Defined Networking (SDN) paradigm 2 can help SONs to automatically manage and orchestrate the network
resources when considering the current network status. The SDN paradigm has the following three characteristics:

1. The ability to decouple the data plane, where the forwarding elements are located, from the control plane, where
the routing decision is made.
2. The control element called SDN Controller that manages multiple network elements belonging to the data plane.
3. The global administration perspective that avoids making changes on each individual network element.

Furthermore, integrating the SDN paradigm with Network Functions Virtualization (NFV) techniques 3 allows
decoupling the software implementation of Network Functions (NF) from the underlying hardware, providing flexi-
bility in the management of the network resources. In this sense, NFV techniques allow deploying network functions
(e.g., load balancers, firewalls, or gateways –SGWs and PGWs in 5G scenarios) as software instances, called Virtual
Network Functions (VNF), running on generic hardware through software virtualization techniques.
One of the most challenging tasks of SONs is the management of monitoring services, which provide valuable
information about resources and network status that is essential to provide the main functionalities of SONs: self-
configuration, self-healing, and self-optimization 4 . In this sense, the orchestration of monitoring services is a critical
and complex process that should be carried out in an automatic way. Otherwise, the management of these services
would be impossible to perform due to the huge number of 5G devices consuming network services, the high mobility
of these devices, or the bandwidth and latency of future mobile communications, among others. Despite the facilities
provided by the NFV and SDN approaches, the mobility provided by future 5G mobile networks and the dynamic
provision of services have hindered the management of the network infrastructure efficiently. Furthermore, we think
that future mobile networks should orchestrate the network monitoring services by considering not only Data-Related
Information (DRI), e.g., the information contained in network flows, but also the Control-Related Information (CRI).
Aspects belonging to the SDN and NFV control planes, such as the number of gathered flows per second or the
percentage of CPU and storage consumed by network resources at a given time, for example, are essential to ensure
the correct provision of monitoring network services.
In order to overcome the previous challenge, we propose a novel solution that considers information of the network
control plane to orchestrate monitoring services by managing network resources automatically. Our proposal defines
a 5G-oriented architecture that integrates the SDN and NFV technologies to monitor and orchestrate the whole life-
cycle of monitoring services by considering the SDN and NFV control plane. Our architecture is the only one, to the
best of our knowledge, that manages the provision of monitoring services defining a set of policies that consider CRI
and 5G aspects, such as the number of active users, the network infrastructure’s location, or the users’ mobility.
The remainder of the paper is structured as follows. Section 2 discusses some related work on other SDN-oriented
solutions that monitor and orchestrate the network elements. Section 3 shows the components forming the proposed
architecture, while the management policies and how they manage the virtual and physical network elements are
presented in Section 4. Section 5 shows the process made by our solution to enforce the actions required to manage
the network resources. Finally, conclusions and future work are drawn in Section 6.

2. Related work

An actual review of the Software-Defined Networking (SDN) paradigm 5 is focused on the current research status
of multi-domain SDN and its future challenges. Among the diversity of proposals oriented to the SDN paradigm,
monitoring services are crucial for many network management tasks, such as load balancing, traffic engineering,
Service Level Agreement (SLA), and security, among others. In this sense, OpenNetMon 6 is a solution that uses
the OpenFlow protocol to monitor all flows between predefined link-destination pairs on throughput, packet loss, and
delay. By querying the switch about the number of bytes sent, as well as the duration of each flow, OpenNetMon is
able to calculate the effective throughput per flow. To this end, this solution compares the flow statistics to compute the
packet loss; particularly, the packet counters from the first and the last switch of each path between the link-destination
pairs. Instead, the delay is measured by injecting probe packets directly into the switch data planes and determining a
realistic delay for each flow. On the other hand, PayLess 7 is an efficient network statistics collector framework for the
SDN paradigm. PayLess is built on top of an OpenFlow controller and is able to monitor, aggregate, and select the
330 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335
A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000 3

information gathered from the switches belonging to the data plane, in accordance with the high-level requirements
expressed by applications. Furthermore, this solution provides a flexible RESTful API for flow statistics collection at
different aggregation levels. It uses an adaptive statistics collection algorithm that delivers highly accurate information
in real-time, without incurring significant network overhead.
Previous proposals are oriented to monitor DRI of the network. Yet, they do not consider orchestrating and man-
aging the network resources automatically when the network is congested, or when a given service cannot be offered.
To overcome this situation, a given management solution 8 proposes to monitor, visualize, and configure the elements
belonging to the three planes of the SDN paradigm. SDN-specific metrics are considered by the network administra-
tors to make decisions and (re)configure SDN-related parameters according to their needs. Another approach oriented
to control the SDN paradigm 9 presents an SDN-based load balancing solution, in which flow capacity is defined by
the number of requested physical resource blocks. Its results show a drastic reduction of the number of unsatisfied
users in the network and a substantial improvement of resources allocated per user.
The previous solutions are able to control the resources of SDN-oriented networks at real-time, but they did not
consider virtualization techniques. In this sense, the Software-Defined Network Virtualization (SDNV) 10 framework
integrates SDN and NFV techniques. This considers the SDN principle of separating data and control planes with the
NFV principle, decoupling the service functions from infrastructures. Moreover, key technical challenges for SDN and
NFV integration are discussed in this proposal. Following the SDN and NFV integration approach, another solution 11
proposes a management and orchestration architecture for multi-tenant transport networks. This allows deploying
virtual optical transport networks and virtual SDN Controllers as VNFs in data centers. One of the main challenges
addressed by this solution consists in integrating the orchestration of distributed cloud and network resources to
dynamically deploy virtual machines and VNF instances and provide the required network connectivity.
Despite the progress made by the previous solutions, they orchestrate the SDN and NFV resources by monitoring
just information related to the data plane (i.e., DRI). In order to ensure the provision of network management services,
we think that it is important to consider not only the DRI, but also CRI. To the best of our knowledge, there are no
solutions that integrate SDN and NFV technologies to manage and orchestrate the behavior of the network resources
considering CRI. Our solution covers this gap, by monitoring CRI to orchestrate the behavior of network elements
belonging to the SDN and NFV technologies.

3. 5G-oriented architecture for Control-Related Information

The flexibility and dynamism provided SDN and NFV technologies are expected to have a relevant impact on future
5G mobile networks 12 . Among the main benefits of applying SDN and NFV to 5G networks, we highlight the need
for network operators to speed up the innovation of network services, the ease of the network management processes,
and the reduction of equipment, power, and space costs. These benefits also help to reach the KPIs defined by the 5G
Public Private Partnership (5G-PPP) 1 , as indicated in Section 1. In this sense, we propose an architecture oriented
to 5G networks that integrate the SDN paradigm with the ETSI NFV proposal 13 . This architecture automatically
manages the network resources with the goal of orchestrating the network monitoring services, which are deployed
in our solution like VNF Monitoring. VNF Monitoring is characterized by gathering information from different and
heterogeneous sources; for example, network infrastructure (physical or virtual), network management services, and
communications between users and network services. Fig. 1 shows the five layers composing our architecture: Vir-
tualized Infrastructure (VI); Virtualized Network Functions (VNF); Software-Defined Networking (SDN) paradigm;
Control and Data Plane Management; and Operations and Business Support Systems (OSS/BSS).
From bottom to top, the Virtualized Infrastructure Manager (VIM) is in charge of creating, controlling, and monitor-
ing the whole life-cycle of Virtual Machines (VM) instantiated on generic Physical Resources, through the Virtualized
Layer. On top of the VIM, the VNF Managers (VNFM) are able to create, manage, monitor, and dismantle VNFs
running on the VMs exposed by the VI layer. VNFs are services oriented to help with the network management tasks.
Examples of VNFs can be monitoring services, Intrusion Detection Systems (IDS) deployed as Deep Packet Inspec-
tion (DPI) tools, or firewalls, among others. At the same level as the VNF, but in another layer, the SDN paradigm
decouples the control plane from the data plane. Therefore, the SDN Controller and the SDN Applications are able to
monitor and manage the control plane of the physical and virtual network resources.
 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335 331
4 A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000

OSS/BSS

VNO 1
VNO 2 ... VNO n
(Virtual Network Operator)

Data Plane Management (DPM) Control Plane Management (CPM)

Virtualized Network Functions (VNF) SDN VNF Manager (VNFM)

Applications
Manager
VNFs VNFs
VI VI
(Monitoring,...) (Firewall, DPI,...) ...
SDN Controller Monitor Security

Virtualized Infrastructure (VI) VI Manager (VIM)

VM 1 (Virtual Machine ) VM 2 VM 3 ... VM n Manager

Virtualized Layer
VI Monitor VI Security ...
Physical Resources

Fig. 1. Architecture to manage the network resources efficiently

In order to manage the information considered by the previous layers, our architecture proposes a management
layer composed of two planes: data and control plane. This proposal is oriented to the Control Plane Management
(CPM), which handles CRI provided by the SDN Applications and from the Virtualization Managers (VNFM and
VIM). The Data Plane Management (DPM) is outside the scope of this work and manages DRI received from the
data plane of the SDN Applications as well as from the existing VMs and VNFs. Regarding the control plane, there
are several components in charge of monitoring and aggregating CRI, analyzing and making decisions to ensure the
provision of VNFs, and reacting and orchestrating the decision-making results according to a given set of internal
rules and policies defined by the Virtual Network Operators (VNO) belonging to the OSS/BSS layer.
In order to show how the proposed architecture is able to ensure the provision of VNF Monitoring, Fig. 2 expands
the internal communications between the different components belonging to the Control Plane Management.

Control Plane Management

policies
Policy Manager

Monitor & Aggregator Analyzer & Decision Reaction Orchestrator

Fig. 2. Components shaping the Control Plane Management

Specifically, the Monitor & Aggregator component gathers CRI from:

• The VNFM. This manager provides metrics with the status of the VNF Monitoring (e.g., the number of network
flows gathered per second).
• The SDN Applications. They send CRI about the status of elements composing the three planes of the SDN
paradigm. The number of flow entries stored in each switch, the number of SDN Applications running in the
SDN Controller, or the logical/physical/geographical location of a given application or network resource could
be examples of CRI gathered by the Monitor & Aggregator component.
• The VIM. This component provides CRI about the status of the virtual and physical resources in which the VNF
Monitoring is running. It could be the percentage of CPU and memory used by physical and virtual machines.

Once the previous CRI has been gathered, this is aggregated and sent to the Analyzer & Decision component,
which analyzes the aggregated CRI and decides the actions needed to ensure the provision of the VNF Monitoring.
332 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335
A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000 5

To this decision-making procedure, the Analyzer & Decision considers internal management policies (explained in
Section 4), as well as high-level policies defined by VNOs to set specific thresholds used by management policies.
Both types of policies are provided to the Analyzer & Decision component through the Policy Manager. Next, we
define a set of possible actions to ensure the VNF Monitor provisioning made by the Analyzer & Decision:

• Regarding the VNF layer, our solution is able to virtualize new VNF Monitoring or configure internal parame-
ters of the VNF Monitoring in order to guarantee the service provision.
• In the SDN layer, we can indicate when SDN Applications should add, modify, or delete flow entries in the
switches to balance or filter the network traffic. Furthermore, we can also indicate specific actions of SDN
Application oriented to the control plane of given network elements (e.g., firewalls or IDSs, among others).
• Regarding the VI layer, our solution indicates when it is required to create new VMs with VNF Monitoring
capabilities or add virtual resources like memory, storage, or computation power to existing VMs.
• With regard to the physical layer, actions like switching on/off physical resources or reporting alerts to admin-
istrators can be performed to guarantee the VNF Monitoring.

The Reaction component is in charge of checking that decided actions can be applied without provoking conflicts
with the existing ones. Moreover, when there are several actions to be performed, the Reaction component is in charge
of establishing different levels of priority for them. Finally, the Orchestrator knows the components responsible for
applying the different actions and communicating with them (VNF, VIM, and SDN Applications) to enforce them.

4. Policies to ensure proper provision of monitoring network services

Our solution manages at run-time the network resources by using policies. Among the different existing policies,
we make use of management-oriented policies, which are defined in the Policy Manager component of the architecture
presented in Section 3. These policies decide the list of potential actions to be taken to guarantee the VNF Monitoring
provision, in accordance with CRI of SDN and NVF elements as well as 5G aspects like, for example, the number of
active users consuming network services, the network infrastructure’s location, or the users’ mobility.
Policies actions influence the behavior of the components and layers of the proposed architecture. Considering
this influence, we categorize our management-policies into four different groups, which are detailed in the following
subsections. These policies are comprised of the following elements: the type of policy, which identifies the policy
category; the network resource, whose information is currently being managed; the metric with which the network
resources are evaluated; the location where the policy will be enforced; the date or the period of time at which the
policy will be applied; and the result or actions to carry out on the network once the policy is applied.

4.1. Software-Defined Networking policies

The Software-Defined Networking (SDN) policies allow managing the elements belonging to the SDN paradigm.
Considering the CRI of SDN and VNF Monitoring, the users’ mobility, or the infrastructure’s location, this kind of
policies automatically manages the network resources belonging to the data, control, and application planes of the
SDN paradigm. One of the useful tasks of the SDN paradigm consists in controlling at real-time the network packets
forwarding. In this sense, Policy 1 shows an example to manage the flow tables of switches belonging to the data plane
of the SDN paradigm. This modifies the flow entries of switches located close to a congested one that sends network
statistics to a given VNF Monitoring. That congestion means that the number of Monitored Flows Per Second (MFPS)
processed by the VNF Monitoring is above a certain threshold MFPSRedAlert. This situation requires balancing the
network traffic between the close switches to guarantee the provision of network statistics to the VNF Monitoring.

Policy 1. SDN policy balancing the network traffic between close switches to provide VNF Monitoring

Type(#SDN) ∧ Resource(?switch) ∧ connected(?switch,?vnfMonitoring) ∧ integer[MFPS in #MFPSRedAlert]

hasStatus(?switch) ∧ Location(?switch,?area) ∧ locatedResources(?area,?nearSwitches) → balance(?switch,?nearSwitches)
 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335 333
6 A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000

4.2. Virtual Network Function policies

Through the Virtual Network Function (VNF) policies, our proposal is capable of managing and configuring the
internal behavior of VNFs. These policies allow instantiating/dismantling VNFs to migrate or balance the load work
of monitoring services with the goal of guaranteeing the VNF Monitoring provision. As an example, Policy 2 indicates
that when a given VNF Monitoring (resource) is congested (e.g., the percentage of CPU metric –CPUPct– is above a
threshold CPUPRedAlert), the result is to create a new VNF Monitoring close (location) to the congested one.

Policy 2. VNF policy creating a new VNF Monitoring close to the congested one to ensure the provision of monitoring services

Type(#VNF) ∧ Resource(?vnfMonitoring) ∧ integer[CPUPct in #CPUPRedAlert] hasStatus(?vnfMonitoring) ∧

Location(?vnfMontoring,?area) → createVNF(#Monitoring,?area)

4.3. Virtual Infrastructure policies

The Virtual Infrastructure (VI) policies are oriented to manage the virtual network infrastructure automatically, in
order to ensure the provision of VNF Monitoring. Among possible actions, we highlight the creation/dismantling of
virtual resources (e.g., computation, networking, storage), instantiation/termination of VMs, and even the relocation
of virtual resources in existing VMs, among others. Policy 3 shown as an example. When a given VM with a running
VNF Monitoring is congested (the percentage of used memory is above a MemoryRedAlert threshold), the reaction is
to instantiate a new VM close to the congested one to later create a new VNF Monitoring with a VNF policy.

Policy 3. VI policy deploying a new virtual machine when the memory of the congested one is not enough to provide monitoring services

Type(#VI) ∧ Resource(?virtualMachine) ∧ hasResource(?virtualMachine, #VNF Monitoring) ∧

integer[MemoryPct in #MemoryRedAlert] hasStatus(?virtualMachine) ∧ Location(?virtualMachine,?area)
→ instatiateVM(#NewVirtualMachine,?area)

4.4. Physical Infrastructure policies

The Physical Infrastructure (PI) policies allow controlling the physical resources of the network infrastructure, so as
to ensure the VNF Monitoring provision. Among possible actions, we highlight switching on/off the physical network
resources located at specific locations or sending alerts to the network administrators, in order to add/modify/remove
physical resources when they are required to provide a given VNF Monitoring. As an example, Policy 4 indicates that
when a VM with a running VNF Monitoring is congested (the percentage of used storage is above a StorageRedAlert
threshold), the reaction consists in switching on a new physical machine located close to the congested one to later
use the previous policies to ensure the VNF Monitoring.

Policy 4. PI policy switching on physical resources when the existing ones are not enough to provide monitoring services

Type(#PI) ∧ Resource(?physicalMachine) ∧ hasResource(?physicalMachine,?vnfMonitoring) ∧

integer[StoragePct in #StorageRedAlert] hasStatus(?physicalMachine) ∧ Location(?physicalMachine,?area)
→ switchON(#NewPhysicalMachine,?area)

5. Orchestration to manage monitoring network services

In this section, we introduce in detail the different steps performed by the Orchestrator component of our archi-
tecture to accomplish the actions established by the groups of policies defined in Section 4. When the previous
334 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335
A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000 7

management policies belonging to the Decision component indicate that is required to perform a certain action, this
is checked and prioritized by the Reaction component. Once this process is performed, the Orchestrator receives the
action and interacts with the different components belonging to the SDN, VNF, and VI layers to enforce it.
In order to show how the Orchestrator makes the different steps associated with a given action, we defined a
simplistic virtualized scenario. It is composed of an SDN-oriented network to monitor the network traffic by means
of a VNF Monitoring (VNF Monitoring1), which is running on a virtual machine (VM1) deployed on top of the
physical infrastructure (Compute1). Initially, the network provides VNF Monitoring1 to ensure the quality of service
(QoS). However, at a given time the number of MFPSs of VNF Monitoring1 starts increasing until exceeding a given
threshold. This situation provokes congestion in VNF Monitoring1, which is detected by the Decision component
thanks to the second policy of the previous section. As a result, the policy action indicates to continue providing the
service by creating a new VNF Monitoring (VNF Monitoring2).
Once the Orchestrator receives the action, Fig. 3 shows the different steps performed by the Orchestrator and the
SDN/NFV resources. First, the Orchestrator interacts with the VNFM to create the VNF Monitoring2 in the existing
virtual machine, VM1 (Step 1 in Fig. 3). Once the VNFM receives the request, it communicates with the VIM to
deploy the new VNF (Step 2). However, VM1 has not enough resources to deploy this new network service and the
VIM returns a fail message (Steps 3 and 4). Once the Orchestrator receives the message, it asks the VI Manager for
deploying a new virtual machine (VM2) in Compute1 (Step 5). The VIM checks that the available physical resource
(Compute1) is not enough to instantiate VM2, and it notifies the situation (Step 6). When the Orchestrator receives the
notification, it checks the catalog maintained by the VIM, so as to see if there are more available physical resources
to extend the existing one. If so, the Orchestrator notifies the VIM that is required to add new computation resources
(Compute2), and the VIM reports an alert to the network administrator to switch on Compute2. Once the physical
resources have been extended with Compute2 (Step 10), the Orchestrator communicates with the VIM to instantiate
VM2 in Compute2. When VM2 is instantiated and the Orchestrator catalog is updated (Step 12), the Orchestrator
communicates with the VNFM to deploy and configure the VNF Monitoring2 (Step 13). Finally, the Orchestrator
notifies the SDN Application in charge of balancing the network traffic, which it has to modify the flow tables of the
existing switches to balance the network traffic between the two VNF Monitoring (Step 17).

CPM VNFM VIM SDN

Orchestrator Manager Manager Application

Create VNF Monitoring in VM1

1 Create VNF Monitoring in VM1
2
Fail: No resources
Fail: No resources 3
4
Create Virtual Machine in Compute1
5
Fail: No resources
6

7 Check catalog
Add Computation Resources 9
8
Announcement
Ok: Compute2 notification
10
Create Virtual Machine in Compute2
11
Ok: VM2
12
Create VNF Monitoring in VM2
13 Create VNF Monitoring in VM2
14
Ok: VNF Monitoring2
Ok: VNF Monitoring2 15
16

Balance VNF Monitoring1 & VNF Monitoring2

17
Ok: Balanced
18

Fig. 3. Diagram of sequence showing the interactions between the Orchestrator and the SDN/NFV resources
 Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335 335
8 A. Huertas, Celdrán, M. Gil Pérez, F. J. Garcı́a Clemente, G. Martı́nez Pérez / Procedia Computer Science 00 (2017) 000–000

6. Conclusions and future work

In this paper, we have proposed a solution in charge of automatically orchestrating at real-time the network moni-
toring services provided by SDN-oriented networks. To this end, we have defined an SDN/NFV-oriented architecture
that monitors the control plane of the network resources and manages the virtual and physical network elements be-
longing to 5G networks dynamically. The proposed architecture makes use of management policies that automatically
control the planes of the SDN paradigm as well as the virtual and physical network resources. The proposed policies
consider aspects like Control-Related Information (CRI) of the network resources, the number of active users, or the
users’ mobility in order to manage the different network elements considered by the NFV and SDN approaches.
As future work, we plan to deploy our 5G-oriented architecture in a fully virtualized environment. Specifically, we
plan to use OpenStack as VIM to instantiate the virtual resources in which the VNFs will run; OpenDaylight as SDN
Controller to control the virtual switches deployed in the OpenStack infrastructure; and Open Baton to orchestrate
the elements belonging to the SDN and NFV planes. By considering this virtualized environment, our intention is
to automatically deploy VNFs at real-time in different Radio Access Networks (RAN) and the EPC (Evolved Packet
Core) belonging to 5G mobile networks, in order to ensure the provision of the monitoring services.

Acknowledgements

This work has been supported by the Spanish MINECO, as well as European Commission FEDER funds, under
grant TIN2015-66972-C5-3-R and TIN2014-59023-C2-1-R, a Séneca Foundation grant within the Human Resources
Researching Training Program 2014, and the European Commission Horizon 2020 Programme under grant agreement
number H2020-ICT-2014-2/671672 - SELFNET (Framework for Self-Organized Network Management in Virtualized
and Software Defined Networks).

References

1. 5G PPP, Key performance indicators, Tech. rep.

2. S. Singh, R. K. Jha, A survey on Software Defined Networking: Architecture for next generation network, Journal of Network and Systems
Management 25 (2) (2017) 321–374. doi:10.1007/s10922-016-9393-9.
3. R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. De Turck, R. Boutaba, Network Function Virtualization: State-of-the-art and research
challenges, IEEE Communications Surveys Tutorials 18 (1) (2015) 236–262. doi:10.1109/COMST.2015.2477041.
4. L. Jorguseski, A. Pais, F. Gunnarsson, A. Centonza, C. Willcock, Self-organizing networks in 3GPP: standardization and future trends, IEEE
Communications Magazine 52 (12) (2014) 28–34. doi:10.1109/MCOM.2014.6979983.
5. F. X. A. Wibowo, M. A. Gregory, K. Ahmed, K. M. Gomez, Multi-domain Software Defined Networking: Research status and challenges,
Journal of Network and Computer Applications 87 (2017) 32–45. doi:10.1016/j.jnca.2017.03.004.
6. N. L. M. van Adrichem, C. Doerr, F. A. Kuipers, OpenNetMon: Network monitoring in OpenFlow Software-Defined Networks, in: IEEE
Network Operations and Management Symposium, 2014, pp. 1–8. doi:10.1109/NOMS.2014.6838228.
7. S. R. Chowdhury, M. F. Bari, R. Ahmed, R. Boutaba, PayLess: A low cost network monitoring framework for Software Defined Networks,
in: IEEE Network Operations and Management Symposium, 2014, pp. 1–9. doi:10.1109/NOMS.2014.6838227.
8. P. H. Isolani, J. A. Wickboldt, C. B. Both, J. Rochol, L. Z. Granville, Interactive monitoring, visualization, and configura-
tion of OpenFlow-based SDN, in: IFIP/IEEE International Symposium on Integrated Network Management, 2015, pp. 207–215.
doi:10.1109/INM.2015.7140294.
9. S. Namal, I. Ahmad, A. Gurtov, M. Ylianttila, SDN Based Inter-Technology Load Balancing Leveraged by Flow Admission Control, in:
IEEE SDN for Future Networks and Services, 2013, pp. 1–5. doi:10.1109/SDN4FNS.2013.6702551.
10. Q. Duan, N. Ansari, M. Toy, Software-defined network virtualization: An architectural framework for integrating SDN and NFV for service
provisioning in future networks, IEEE Network 30 (5) (2016) 10–16. doi:10.1109/MNET.2016.7579021.
11. R. Muñoz, R. Vilalta, R. Casellas, R. Martinez, T. Szyrkowiec, A. Autenrieth, V. López, D. López, Integrated SDN/NFV Management
and Orchestration Architecture for Dynamic Deployment of Virtual SDN Control Instances for Virtual Tenant Networks, Journal of Optical
Communications and Networking 7 (11) (2015) B62–B70. doi:10.1364/JOCN.7.000B62.
12. The 5G-PPP SELFNET project, Deliverable D2.3: Prototype and report framework for enabling the encapsulation of NFV and SDN appli-
cations (Apr. 2016).
13. ETSI NFV ISG, Network Functions Virtualisation (NFV); Network Operator Perspectives on NFV priorities for 5G, Tech. rep. (Feb. 2017).