Automatic monitoring management for 5G mobile ... - ScienceDirect

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

Available online at www.sciencedirect.com

ScienceDirect Procedia Computer Science (2017) 000–000 Procedia Computer Science 11000 (2017) 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 J. Garc´ıa Clementebb , and Alberto Huertas Huertas Celdr´ Celdráanna,∗,, Manuel Manuel Gil Gil P´ Péerez reza ,, F´ Féelix lix a J. Garc´ıa Clemente , and Gregorio Gregorio Mart´ Mart´ıınez nez P´ Péerez reza a Dept. Ingenier´ıa de la Informaci´ on 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ó de Computadores, University of Murcia, 30071 Murcia, Spain b Dept. Ingenier´ıa y Tecnolog´ııa 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 Publishedby byElsevier 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 managethis sense, Self-Organizing Networks (SON) arose with the goal of moving forward from traditional manual management 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: [email protected] E-mail address: [email protected]

c 2017 The Authors. Published by Elsevier B.V. 1877-0509 c 2017 The Authors. Published by Elsevier B.V. 1877-0509 Peer-review under responsibility of the Conference Program Chairs. Peer-review©under of the Conference Program B.V. Chairs. 1877-0509 2017responsibility The Authors. Published by Elsevier Peer-review under responsibility of the Conference Program Chairs. 10.1016/j.procs.2017.06.102

2

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

329

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 flexibility 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: selfconfiguration, 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 lifecycle 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


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 managing 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 administrators 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: Virtualized 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 monitoring 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 Inspection (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.

4

Alberto Huertas Celdrán et al. / Procedia Computer Science 110 (2017) 328–335

331

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 (Virtual Network Operator)

VNO 2

Data Plane Management (DPM)

VNO n

Control Plane Management (CPM)

Virtualized Network Functions (VNF) VNFs (Monitoring,...)

...

VNF Manager (VNFM)

SDN Applications

VNFs (Firewall, DPI,...)

Manager VI Monitor

SDN Controller

Virtualized Infrastructure (VI) VM 1 (Virtual Machine )

VM 2

VM 3

VI Security

...

VI Manager (VIM) ...

VM n

Manager

Virtualized Layer VI Monitor

Physical Resources

VI Security

...

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


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 parameters 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 administrators 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)

6


333

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 architecture to accomplish the actions established by the groups of policies defined in Section 4. When the previous

334


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

Orchestrator

Manager

Manager

1

Create VNF Monitoring in VM1 2 4

Fail: No resources

Fail: No resources

8

13

6

Add Computation Resources Ok: Compute2

11

3

Create Virtual Machine in Compute1

Check catalog

7

Create VNF Monitoring in VM1

Fail: No resources 5

SDN Application

9

Announcement notification

10

Create Virtual Machine in Compute2 Ok: VM2

Create VNF Monitoring in VM2 14

Ok: VNF Monitoring2 17

12

Create VNF Monitoring in VM2 Ok: VNF Monitoring2

16

15

Balance VNF Monitoring1 & VNF Monitoring2 Ok: Balanced

18

Fig. 3. Diagram of sequence showing the interactions between the Orchestrator and the SDN/NFV resources

8


335

6. Conclusions and future work In this paper, we have proposed a solution in charge of automatically orchestrating at real-time the network monitoring 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 belonging 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 configuration 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 applications (Apr. 2016). 13. ETSI NFV ISG, Network Functions Virtualisation (NFV); Network Operator Perspectives on NFV priorities for 5G, Tech. rep. (Feb. 2017).