Network Self-conﬁguration for Edge Elements using Self-Organizing

Networks Architecture (SONAr)

Daniel Ricardo Cunha Oliveira

, Natal Vieira de Souza Neto

, Maur

ıcio Amaral Gonc¸alves

avio de Oliveira Silva

and Pedro Frosi Rosa

Faculty of Computing, Federal University of Uberl

andia, Uberl

andia, Brazil

Keywords:

Self-management, Self-conﬁguration, Self-Organizing Networks, SDN, NFV, Cloud Computing.

Abstract:

5G networks deployment is already a commercial reality, while the speciﬁcation groups move towards 5G

standalone standardization. With the need for network slicing and edge computing capabilities – and there-

fore, inherent SDN and NFV adoption in a cloud environment –, these networks’ complexity will require

some degree of automation. The concept of Self-Organizing Networks (SON) is a trend for next-generation

systems, as it is already used in the mobile radio access network (RAN) context. In this work, we will present

a self-conﬁguration (one of the four basic self-* properties of SON) system basic design proposal, within the

context of Self-Organizing Networks Architecture (SONAr) framework. We will discuss the generic system

architecture and present one practical application example, using the self-conﬁguration platform to automat-

ically conﬁgure the network to receive an eNodeB (4G base station) edge component. All the system design

is being conceived to work on a carrier-grade production environment, with application versatility, reliability,

and scalability.

1 INTRODUCTION

Self-conﬁguration is a key fundamental feature in au-

tonomic computing theory and SON. Essentially, a

self-conﬁguration system should automatically adapt

the network parameters to changes in the environ-

ment. The SON speciﬁcation states that the self-

conﬁguration means actions applied before the net-

work enters an operational state (3GPP, 2018b). In

computer networks, there are two distinct contexts

where self-conﬁguration may be used: (i) the network

bootstrapping; and (ii) the occurrence of a new com-

ponent.

The network bootstrapping means the transi-

tion from a non-operational state to an operational

state. Each Network Element (NE) such as switches,

routers, eNodeBs, and so on are conﬁgured and

started by an operator. Typical conﬁgurations include

the allocation of logical addresses (IPv4 and IPv6),

the deﬁnition of static routes, the conﬁguration of spe-

https://orcid.org/0000-0003-4767-5518

https://orcid.org/0000-0001-5047-4106

https://orcid.org/0000-0002-6985-638X

https://orcid.org/0000-0001-7051-7396

https://orcid.org/0000-0001-8820-9113

ciﬁc management VLANs management, policy rules,

etc. Usually, these operations are executed manually

by the network administrator.

The occurrence of a new component stands for the

addition or removal of NEs. If a new NE is inserted

in the network topology, the operator must conﬁgure

it, as well as the neighbors’ NEs. Sometimes, the in-

troduction of a new NE means that some routes or

trafﬁc parameters should be modiﬁed to optimize the

network behavior.

Some projects are found in the literature aim-

ing attention at the orchestration and conﬁguration

of Software Deﬁned Networking (SDN) and Net-

work Functions Virtualization (NFV) resources on the

cloud environment, such as network slicing (Foukas

et al., 2017). To our knowledge, edge components are

not addressed in these projects. Furthermore, (3GPP,

2018a) ranks most of the self-conﬁguration functions

as For Future Study (FFS). This problem justiﬁes

the new approach proposed in this work: the imple-

mentation of self-conﬁguration aspects in the con-

text of a future self-management platform, the Self-

Organizing Networks Architecture (SONAr).

In this work, we brieﬂy describe SONAr and its

main components, and specify the procedures and

ﬂows to adapt its architecture to deal with the auto-

408

Oliveira, D., Neto, N., Gonçalves, M., Silva, F. and Rosa, P.

Network Self-conﬁguration for Edge Elements using Self-Organizing Networks Architecture (SONAr).

DOI: 10.5220/0009465104080414

In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 408-414

ISBN: 978-989-758-424-4

nomic conﬁguration when edge components are in-

serted on the network. As a use case, we will present

the self-conﬁguration case when an eNodeB (4G Base

Station) is plugged into a speciﬁc network. By us-

ing our approach, network operators should connect

the new edge components in a physical connection,

while all conﬁguration settings will be done automat-

ically by SONAr platforms. Beyond the dynamic pa-

rameter settings, the self-conﬁguration introduces an

additional security mechanism: the self-conﬁguration

module will verify whether the new NE is allowed to

get in the network topology.

The remaining of this paper is structured as fol-

lows. Section 2 gives some related work. Section

3 presents the self-conﬁguration requirements in fu-

ture networks and the SONAr model. Section 4 brings

our proposed approach, and ﬁnally, Section 5 presents

concluding remarks and future work.

2 RELATED WORK

Since 2001, IBM was already concerned about the

increasing complexity of computer networks and the

inherent difﬁculties to manage them, as well as the

companies’ OPEX increase with the need of highly

specialized professionals to perform trivial tasks.

(Ganek and Corbi, 2003) deﬁnes the basis and con-

cepts for autonomic computing, including the four

self-* features (self-conﬁguration, self-healing, self-

optimization, and self-protection) and their character-

izations.

Project ANEMA (Autonomic Network Manage-

ment Architecture) (Derbel et al., 2009) also deﬁnes

a high-level architecture model for self-conﬁguration

and self-optimization in IP networks. It does not, al-

though, addresses self-protection or self-healing fea-

tures, as well as SDN/NFV capabilities, being re-

stricted to regular IP networks with non-virtualized

components.

(Atayero et al., 2014) presents a vision on self-

organizing networks applied to 3GPP’s Long Term

Evolution (LTE). (3GPP, 2018b) is the 3GPP’s tech-

nical speciﬁcation (TS) that introduces the concepts

and requirements for mobile network SON. The scope

of this TS involves only self-optimizations and self-

healing, and it is limited to the Radio Access Network

(RAN) 3GPP protocols.

(Neves et al., 2016) brings the SELFNET frame-

work, an approach for autonomic management in

NFV and SDN networks, mainly designed for 5G net-

works. Both SONAr and SELFNET have some mu-

tual functions and may work together in the future

since SONAr is not dependable on the network type

– it was designed to work with NFV, SDN, and even

legacy network elements.

Although many efforts to achieve a complete and

comprehensive framework and architecture for Self-

Organizing Networks, none is already ﬁnished and

available. There are indeed a lot of requirements left

unmet by the several projects in this regard.

3 BACKGROUND

In this section, a review of the ongoing telecom-

munications and computer networks is presented,

along with the reasons that led us to consider self-

conﬁguration as an indispensable approach to work

on these networks. First, we characterize the re-

quirements of current and future networks and, subse-

quently, we bring the SONAr project where our pro-

posed self-conﬁguration functions are placed.

3.1 The Need for Self-conﬁguration

Future telecommunications and computer networks

are supposed to satisfy new application requirements,

such as high-volume trafﬁc, Ultra-Reliable and Low-

Latency Communication (URLLC), fault detection,

etc (Chen et al., 2018). Current and new approaches

(like IoT platforms, cloud computing and 5G net-

works) are expected to have capabilities to support

those requirements (Barona L

opez et al., 2017). In

these cases, there are a vast number of network com-

ponents to support billions of devices, as well as a

large number of rules to satisfy the communication re-

quirements. The new set of rules includes edge com-

puting (enabled by cloud and fog computing) network

slicing management (SDN), infrastructure orchestra-

tion (NFV), distributed resource management, and so

on. It can be inferred that it is impossible to manage

this complex environment manually.

The autonomic computing concept proposed by

IBM (Ganek and Corbi, 2003) already predicted that

future systems must have mechanisms to manage

themselves autonomously. We believe that the au-

tonomic computing era will arrive for computer net-

works with the introduction of 5G Standalone (5G

SA) networks: with the fully virtualized and SDN en-

abled core network in cloud infrastructure, 5G will

be prepared to deal with several different applications

and requirements. The self-adaptation is crucial to

achieving this idealization.

Autonomic computing is composed of the four

mentioned fundamental features: self-healing, self-

optimization, self-protection, and self-conﬁguration.

The SONAr approach discussed in Section 3.2 deals

Network Self-conﬁguration for Edge Elements using Self-Organizing Networks Architecture (SONAr)

409

with these four features. However, for this paper, the

target is the self-conﬁguration component. Computer

networks will require self-conﬁguration functions for

several reasons:

• Man made conﬁguration of too many NEs will re-

quire a great professional effort;

• Reliability issues due to manual conﬁguration of

a complex network;

• The high OPEX costs with professional services

could be a disavantage to business;

• Security issues with unauthorized NEs plugged in

the network;

• Network environments are changing too fast and,

therefore, demands more intense number of inter-

ventions.

Within the conﬁguration of a network, the edge NEs

represent a special case. For many of them, such as

mobile base stations, a specialized conﬁguration have

to be done, i.e. special VLANs with different for-

warding policies and prioritization must be assigned

for different packets types, as it will be seen in Ses-

sion 4.3. It is not an obvious or natural conﬁgura-

tion, as would be expected for regular NEs, such as

switches or routers. Therefore, edge NEs require spe-

cialized treatment in the network self-conﬁguration.

3.2 SONAr

The SONAr project aims to provide self-* capabil-

ities to computer networks. The ﬁrst architecture re-

lease was designed as a platform that operates in SDN

and NFV environments. However, the architecture is

prepared to involve legacy networks and protocols as

well, in a carrier-grade level of service.

Figure 1 shows the layered architecture design.

The Client, Control, and Infrastructure layers hold

NEs, SDN control components, NFV management

components, and other Operations, Administrations,

and Management (OAM) systems. All these men-

tioned elements are managed by the SONAr platform,

which is composed of the Interface Layer, Manage-

ment Layer, and Administration layer.

The Collector Entity (CoE) collects topology and

metrics from the other layers. The Control Primi-

tives Interceptor (CPI) intercepts management prim-

itives in the Southbound Interface (SBI). The Net-

work Service Broker (NSB) integrates with SDN con-

trollers and NFV orchestrators to execute the platform

decisions. The Network Event Manager (NEM) al-

lows event-driven communication between the plat-

form components. Finally, the Self-Learning Entities

(SLE) and Self-Organizing Entities (SOE) consist of

self-* services.

Figure 1: SONAr Basic Design.

The Self-Healing Entity (SHE), the Self-Optimization

Entity (SOE) and the Self-Protection Entity (SPE) are

out of scope in this document. The SLE implements

AI functions such as Machine Learning (ML) to pre-

dict the whole structure behaviour. The outputs from

SLE may generate conﬁguration tasks in the environ-

ment. The Self-Conﬁguration Entity (SCE) is the key

component in this role, where the services for network

self-conﬁguring are performed. The SCE utilizes the

Network Database (NDB) to store topology informa-

tion, settings, conﬁgurations applied, and other rele-

vant information. Section 4 will describe the SCE in

details.

4 SELF-CONFIGURATION

PROPOSED ARCHITECTURE

In this section, we will present the system’s general

design, followed by a typical message ﬂow explana-

tion, then an example of application and, ﬁnally, the

next steps of the work.

4.1 General Design

The general design for the Self-Conﬁguration Entity

is shown on Figure 2.

From bottom-up, the Infrastructure Layer repre-

sents all the NEs that make up the network, includ-

ing switches, routers, servers, and other NEs on edge,

since the Client Layer is not represented here. These

NEs may or may not be Virtual Network Functions

(VNFs) running on an NFV platform, such as Open

vSwitches deployed on a cloud environment. SDNC

is the SDN Controller. In the diagram, we are as-

suming that all the NEs in the infrastructure layer are

SDN compatible, i.e., they receive OpenFlow com-

mands (or any other Southbound Interface protocol

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

410

Figure 2: Self-Conﬁguration (SCE) System Basic Design.

commands). In the case of a legacy non-SDN com-

patible NE, the commands will come from the NSB

directly to the NE without passing through SDNC, as

will be seen in the next sessions. In this particular

case, the NE’s proper syntax will be used, instead of

the OpenFlow protocol.

CoE and CPI perform network monitoring. The

ﬁrst uses both the Autonomic Control Loop (ACL)

and the Local Agent (LA) services to collect network

information. ACL monitors the Infrastructure Layer

and it’s NEs periodically, while the LAs are internal

agents inserted into the NEs that summarize data and

send it to CoE. CPI is responsible for copying and

parsing OpenFlow messages and searching for primi-

tive metrics such as ofpmp-port-stats, for example.

NEM component receives the data collected by

CoE and CPI and converts them into events, which

are published in topics and made accessible to all

other elements that subscribe to these topics. The

Network Service Broker (NSB) is responsible for re-

ceiving messages from SCE, in addition to the other

Self-Organizing Entities, and send either Northbound

Interface (NBI) commands to the SDNC, or compat-

ible commands directly to the NE in case of legacy

one.

The Self-Learning Entities (SLE) will not be dis-

cussed here in details due to lack of space, but, in

brief, it is responsible for providing AI-based mech-

anisms to overcome the absence of human interven-

tion. It also subscribes to topics on NEM and receives

information about the network, storing and retrieving

them in/from the NoSQL Engine. Then it will eval-

uate improvements that will be implemented by all

self-* entities.

Finally, SCE is composed of several microservices

(ms) that will act together to provide the right conﬁg-

uration to the network. They are:

• SCE catalog-ms: this service subscribes to

NEM’s topics and becomes aware when a new

edge NE is plugged in the network. Its function

is to determine whether a new edge NE is in the

authorized NE database and, if so, discover the

type, vendor and version of this element;

• topology-ms: the function of this service is to

build the topology between all the network com-

ponents, including all the NEs and the SDN con-

troller;

• path engine-ms: this service must calculate all

paths between two nodes on the network, includ-

ing the best path between a node and its controller;

• command parser-ms: identiﬁes all the NEs in the

path (discovered by path engine service) between

the NE on edge and its ﬁnal endpoint, matching

them to the speciﬁc conﬁguration syntax. More

details of this procedure will be presented in the

next subsection.

At last, NDB is where all the network information

tables are stored, and the NoSQL Engine Database

stores all metrics collected by SLE, involving a high

volume of data storage.

In the next subsection, we will present a brief

description of a typical message ﬂow between these

components when a generic edge NE is plugged into

the network.

4.2 Typical Message Flow Diagram

To describe the process of a typical network self-

conﬁguration, let’s assume that an edge NE is plugged

into the network for the ﬁrst time. Figure 3 shows

how the message ﬂows between the SONAr and SCE

components.

Figure 3: Self-Conﬁguration Flow Diagram.

Network Self-conﬁguration for Edge Elements using Self-Organizing Networks Architecture (SONAr)

411

First of all, CoE (through ACL) sends an update to

NEM (MSG 1), informing that a new NE was de-

tected. NEM publishes the event on a speciﬁc topic.

The service SCE Catalog, which subscribes to

this NEM topic, receives the information that a new

NE was plugged, and then it receives its MAC ad-

dress (MSG 1). SLE component also gets this up-

date, but its subsequent actions are out of the scope

of this paper. Then SCE Catalog service consults the

edge catalog.db table (on NDB) to verify if: (1) this

speciﬁc MAC address exists and is authorized, pro-

viding an additional security measure against unau-

thorized network intrusion, and, if so; (2) retrieving

the type and version of the NE. Then it starts the com-

mand parser service.

The command parser identiﬁes every element be-

tween the NE on edge and its ﬁnal destination NE (de-

termined by path engine service), relating every SDN

NE with their conﬁguration syntax. For this, it uses

both syntax.db, which contains the commands gram-

mars for each NE network version for each edge NE

type, and resources.db, a resource pool where the ser-

vice may get available IP addresses, for example. It

mounts the OpenFlow commands, for example, and

send them to the NSB (MSG 2). The command ﬁeld

in syntax.db may be deﬁned using any compatible for-

mat, but in this work, Jinja2 is being used as a tem-

plate engine for describing the command’s syntaxes.

Finally, NSB will send the conﬁguration com-

mands to the SDNC through the NBI (MSG 3).

SDNC responds, acknowledging the execution of the

commands. In case of legacy elements, NSB will send

non-SDN proper conﬁguration commands directly to

these NEs.

In short, that is the primary communication ﬂow

between all components during the self-conﬁguration

process.

4.3 Possible Applications

In this subsection, we intend to demonstrate a high-

level application example for the self-conﬁguration

procedures. We do not intend to enter speciﬁc Open-

Flow details, mobile network-speciﬁc protocols or

message analysis.

One typical application, presented here as an ex-

ample, is the network self-conﬁguration when an eN-

odeB is plugged into a switch connected to this net-

work. We assume here that all the NEs are SDN com-

patible and an SDNC (not shown) is controlling all

the elements and it uses OpenFlow protocol on SBI.

Some of them may be, as mentioned before, Open

vSwitches VNFs if part of the infrastructure is cloud-

iﬁed. Also, for simpliﬁcation, the SONAr compo-

nents are not represented in the diagram. Since a 4G

eNodeB is considered for this example, the core ele-

ments may or may not be VNFs running on an NFV

structure. The example network, in a simpliﬁed topol-

ogy, is shown in Figure 4.

Just after the eNodeB is plugged on S1, the SDNC

receives an OFPT HELLO message, and the follow-

ing messages exchange will provide the SDNC with

the eNodeB MAC address (as mentioned, the Open-

Flow message ﬂows will not be detailed here). Fol-

lowing that, the CoE will request network updates

through ACL Request message and the SDNC will re-

spond with an ACL Response, containing information

about the new edge NE. CoE will then send a message

to NEM informing about the network modiﬁcations,

and NEM will update its topics with them.

SCE’s SCE catalog service subscribes to this

topic in NEM and, therefore, will receive the infor-

mation about the new eNodeB. It will then consult

the edge catalog.db table on NDB and verify if the

eNodeB is an authorized element on the network. As-

suming it is, it will retrieve from edge catalog the

type and version of the component, using the MAC

address as the key. In this case, it should return some-

thing like ”eNB vendorXXX version2.3.8.001c”, for

example. The path engine service calculates the best

route from S1 to the ﬁnal IP destinations. In this case,

there are four IP destinations for the packets from

and to the eNodeB: control messages should be for-

warded to Mobility Mobile Entity (MME), manage-

ment messages will go to the NE Manager, user plane

messages shall be sent to the Enhanced Packet Core

(EPC) and, ﬁnally, the sync packets should go to the

Clock Server. In traditional networks, this conﬁgura-

tion is done by manually setting and conﬁguring four

VLANs in each element in the path from S1 to S6.

The path engine service determines that the best

route from the eNodeB and the packet’s destination

should be S1-S2-R1-R2-S6. Therefore, these ﬁve

elements should be conﬁgured. Notice that the re-

dundancy path S1-S5-S4-S3-S2-R1-R2-S6 will not be

set, since the self-healing service should treat all the

network failures, sometimes in a predictive way. In

case of a broken link, SHE should call SCE to recon-

ﬁgure the new path, but this procedure is also out of

the scope of this paper.

The command parser service is then started and

receives the element type information, together with

the NEs that shall be conﬁgured. In order to do this,

it fetches the syntax.db table from the NDB (which

relates the edge element type and the NEs types to

the command syntaxes) and mounts the command se-

quences for S1, S2, R1, R2, and S6 elements, also

using the resources.db table, when additional parame-

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

412

Figure 4: Example of Self-Conﬁguration Application.

ters are needed. Next, command parser service sends

the command sequences to the NSB. NSB then sends

the commands to the SDNC, who will, ultimately, cre-

ate all the ﬂows and other conﬁgurations (such as pol-

icy rules) for each element. The use of OpenFlow

protocol makes it relatively simple to assign speciﬁc

ﬂows entries for a particular packet, given an IP des-

tination.

At last, SDNC returns a response to NSB, ac-

knowledging that the commands were successful ac-

cepted and implemented on all NEs.

One last remark, the self-conﬁguration platform

does not conﬁgure the edge NE itself, i.e., in the

example, it does not input any speciﬁc parameter

to the eNodeB, such as Public Land Mobile Net-

work (PLMN), Radio Resource Control (RRC) or Ra-

dio Link Control (RLC) paramaters, etc. The self-

conﬁguration platform only acts on the access (L2)

and transport (L3) network, preparing it for the al-

ready conﬁgured eNodeB, which has to be done in a

separate process (manually or not).

4.4 Next Steps

Both self-conﬁguration module and SONAr as a

whole still require some work, which is ongoing. For

SONAr, many of the components are already devel-

oped and working, such as NEM, NSB, CoE, etc. The

network bootstrap procedure is functional. Some of

the Self-Organizing Entities are currently being de-

veloped, in special SCE and SHE. The SLE com-

ponents also need to be improved, as some of them

still make analytic decisions based on simple statis-

tics trends, instead of more complex and efﬁcient AI

techniques.

SCE is currently under construction. The services

path engine and topology are already implemented

and working, but SCE catalog and command parser

are still to be coded and tested.

All the architecture is being developed and tested

in a virtual environment based on GNS3 software.

This allows us to make adjustments to the system and

simulate both traditional and NFV applications. A

partnership with a local operator will enable tests to

on the real environment, using its lab with physical

and virtual network elements.

5 CONCLUSION

In this work, we have proposed a self-conﬁguration

platform model, within the context of the SONAr

system. We have shown SONAr underlying archi-

tecture and, in particular, the Self-Conﬁguration En-

tity, which will perform the (preferable, but not ex-

clusively) SDN/NFV network conﬁguration automat-

ically. We have presented the main components on the

interface layer (NEM, NSB, CPI, and CoE) and man-

Network Self-conﬁguration for Edge Elements using Self-Organizing Networks Architecture (SONAr)

413

agement layer (SLE and SOE) and the overall system

structure.

We then presented the self-conﬁguration module

architecture, with all the services and databases that

compose it, along with its functions and interfaces,

followed by the typical message ﬂow through the sys-

tem and how the components interact with each other.

Finally, we have demonstrated an application ex-

ample using the network self-conﬁguration procedure

when an eNodeB is plugged into an operator’s net-

work in a sample topology. In a high-level manner, we

have described the information ﬂow and how the ser-

vices work together to build the conﬁguration needed

to accept the new NE rapidly. Some issues have been

discussed, primarily related to the network’s security

and reliability.

There is still some work to be done before the self-

conﬁguration module can be thoroughly tested, so this

paper has no intention to present ﬁnal or partial results

yet. The tests and measures will be done as soon as

the system is complete and will be presented in future

works.

ACKNOWLEDGEMENTS

This work is inside UFU-CAPES.PrInt Program. This

study was ﬁnanced in part by the Coordenac¸

ao de

Aperfeic¸oamento de Pessoal de N

ıvel Superior –

Brasil (CAPES) – Finance Code 001.

REFERENCES

3GPP (2018a). Telecommunication management; Self-

conﬁguration of network elements; Concepts and re-

quirements. Technical Speciﬁcation (TS) 32.501, 3rd

Generation Partnership Project (3GPP).

3GPP (2018b). Telecommunication management; Self-

Organizing Networks (SON); Concepts and require-

ments. Technical Speciﬁcation (TS) 32.500, 3rd Gen-

eration Partnership Project (3GPP).

Atayero, A. A., Adu, O. I., and Alatishe, A. A. (2014). Self

Organizing Networks for 3GPP LTE. In Murgante,

B., Misra, S., Rocha, A. M. A. C., Torre, C., Rocha,

J. G., Falc

ao, M. I., Taniar, D., Apduhan, B. O., and

Gervasi, O., editors, Computational Science and Its

Applications – ICCSA 2014, volume 8583, pages 242–

254. Springer International Publishing, Cham.

Barona L

opez, L., Valdivieso Caraguay,

A., Sotelo Monge,

M., and Garc

ıa Villalba, L. (2017). Key technolo-

gies in the context of future networks: operational and

management requirements. Future Internet, 9(1):1.

Chen, H., Abbas, R., Cheng, P., Shirvanimoghaddam, M.,

Hardjawana, W., Bao, W., Li, Y., and Vucetic, B.

(2018). Ultra-reliable low latency cellular networks:

Use cases, challenges and approaches. IEEE Commu-

nications Magazine, 56(12):119–125.

Derbel, H., Agoulmine, N., and Sala

un, M. (2009).

ANEMA: Autonomic network management ar-

chitecture to support self-conﬁguration and self-

optimization in IP networks. Computer Networks,

53(3):418–430.

Foukas, X., Patounas, G., Elmokashﬁ, A., and Marina,

M. K. (2017). Network slicing in 5g: Survey and chal-

lenges. IEEE Communications Magazine, 55(5):94–

100.

Ganek, A. G. and Corbi, T. A. (2003). The dawning of

the autonomic computing era. IBM systems Journal,

42(1):5–18.

Neves, P., Cal

e, R., Costa, M. R., Parada, C., Parreira,

B., Alcaraz-Calero, J., Wang, Q., Nightingale, J.,

Chirivella-Perez, E., Jiang, W., et al. (2016). The self-

net approach for autonomic management in an nfv/sdn

networking paradigm. International Journal of Dis-

tributed Sensor Networks, 12(2):2897479.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

414