Jean-Michel Sanner

Pierrick Louin

Yassine Hadjadj-Aoul

Meryem Ouzzif

An extended and flexible SDN control plane

Abstract-In this paper we demonstrate the feasibility of an extended and flexible SDN control plane that allows to overcome the limitations of the Openflow protocol by achieving distributed and intelligent network services in SDN networks. This extended control plane is designed according to the following reference guidelines; 1) the concept of generic and programmable network nodes usually known as "white boxes". They integrate a generic engine to execute the service and a library of elementary components as basic building blocks of any services; 2) a fine grained decomposition logic of network services into elementary components, which allows the services to be designed and customized on the fly using these building blocks available on each network node in libraries; 3) a mechanism for re-configuring or redefinition on the fly of the network services on generic nodes without service interruption; 4) some smart elementary agents called SDN controllers elements to provide and distribute the intelligence necessary to interact with the data plane at different levels of locality.

This SDN control plane is illustrated in a proof of concept with the implementation of a distributed monitoring service use case. The monitoring service can act and evolve in a differentiated manner in the network depending on traffic requirements and monitoring usage.

Index Terms-Programmable, Data plane, Controller, SDN

I. INTRODUCTION

During the last decades, several network architectures, such as the IETF Policy Based Networking and ForCes, have emerged to make the network more flexible. The most emblematic evolution is certainly that which consists in separating the control plane from the data plane, which is proposed in Software-Defined Networking (SDN).

By centralizing the control function, SDN makes it easier to instantiate new services and applications. In fact, SDN eliminates the need for distributed protocols, replacing them with a simpler protocol, like OpenFlow [START_REF] Mckeown | Openflow: Enabling innovation in campus networks[END_REF], for communication between controllers and switching equipments. The effectiveness of the Openflow protocol, which does not require equipments' renewal, is certainly at the origin of its wide deployment by infrastructure operators, making it the de facto SDN protocol. However, OpenFlow based SDN architectures are strongly limited in their functionalities according to different dimensions. In its essence, the SDN approach is centralized with one controller controlling a large cluster of very simple switches in the network. It is therefore difficult to implement efficiently in a distributed way some usual and classical functions currently used in networks. This is the case for instance with the functions which manage large amounts of traffic for firewalling, security or packet inspection, or the functions which need some locality like fast rerouting to react on time, or finally those that require intelligent analysis on network nodes like monitoring.

We propose in this paper an extended, flexible SDN control plane which is able to overcome these limitations. It allows to manage dynamically, on the fly, and in a differentiated way, networks functions which are distributed in network nodes. We illustrate this concept through a monitoring use case and we demonstrate that we are thus able to introduce flexibility, dynamicity and adaptability in such functions to implement various scenarios of service deployment.

The remainder of this paper is organized as follows. Section II details the related works. Section III introduces the considered design guidelines. Section IV describes the monitoring use case. Section V gives more details about the proof of concept implementation details. Section VI discusses the obtained results. Finally, the paper concludes in Section VII.

II. RELATED WORKS

As we mentioned, the Openflow protocol has inherent limitations. There are some drawbacks to shifting all logic to the controller level. Indeed, taking all decisions on a remote point can present problems of latency and scalability [START_REF] Schmid | Exploiting locality in distributed sdn control[END_REF].

Different solutions were proposed to tackle the issues introduced beforehand. The distribution of controllers was one of the first approaches considered to solve these problems while increasing the reliability of these networks. In [START_REF] Dixit | Towards an elastic distributed sdn controller[END_REF], the authors proposed a new framework, named Elasticon, for the dynamic placement of controllers. Other approaches, quite similar, have been proposed in the literature, some of which have been very successful with network operators such as ONOS [START_REF] Berde | Onos: Towards an open, distributed sdn os[END_REF].

To optimize operation, some approaches present a hierarchical architecture, in which one or more high-level controllers handle events requiring a global vision and lowerlevel controllers handle events requiring a local vision [START_REF] Schmid | Exploiting locality in distributed sdn control[END_REF]. In [START_REF] Hassas Yeganeh | Kandoo: A framework for efficient and scalable offloading of control applications[END_REF], H. Yeganeh et al. proposed Kandoo, a hierarchical set of controllers compatible with OpenFlow. They define a notion of local controllers directly managing a set of switches and a root controller that benefit from a global view of the network. Although the paper shows impressive results, it is to notice that the application scope of this solution is restricted to environments where local decisions are predominant such as Data Centers' environments. A similar approach, named Orion, was presented, in [START_REF] Fu | Orion: A hybrid hierarchical control plane of software-defined networking for large-scale networks[END_REF]. One main difference with Kandoo's architecture lies in the role of each control plane. In Orion, the local controllers are managing an entire area and propose an abstract view of their areas to a global area manager. Another difference with Kandoo is the intrinsic distribution of the Domain Controllers. Whereas Kandoo pleads for a "logically" centralized global controller, Orion designed its domain controller layer with several global controllers interacting on the inter-sub-domain management through a distributed protocol. While efficient and powerful, these solution inherit the shortcomings of Openflow. This means that the provision of on-demand functions remains difficult to implement and localized new decision-making is still very limited.

Enriching switches, traditionally lacking intelligence in Openflow, with a stateful per flow processing, as proposed in [START_REF] Bianchi | Openstate: Programming platform-independent stateful openflow applications inside the switch[END_REF], allows for much more elaborated functionality. However, even if the concept generalizes the Openflow match/action rules and offloads the central controller, the type of supported functions remains restricted to rather simple functions.

To go further in the complexity of the supported functions, some recent contributions suggest data plane programming.

Based on the open source Cisco's Vector Packet Processing (VPP) [START_REF] Intel | Fd.io -vector packet processing white paper[END_REF], the authors proposed in [START_REF] Choi | Pvpp: A programmable vector packet processor[END_REF] an extension using P4 language [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF] to create plug-ins, which can be dynamically swapped. Similarly, the authors of [START_REF] Jouet | Bpfabric: Data plane programmability for software defined networks[END_REF] proposed the BPFabric platform to centrally program and monitor the data plane using extended Berkeley Packet Filter (eBPF). In order to ease interaction with such low level framework, the authors proposed the use of a high level language, like P4, and to compile it to eBPF 1 .

These two contributions are in line with what we proposed earlier [START_REF] Sanner | Dices: A dynamic adaptive service-driven sdn architecture[END_REF]. Indeed, we proposed to model services using a high level language based on Petri networks, which allows not only to optimize services, as a P4 compiler would do, but also to extract qualitative properties. On the other hand, the architecture we have proposed allows a global and hierarchical management of a network, by delegating local processing logic to local controllers. This distribution, in the operation, allows to reduce the complexity in the management and to better manage networks at scale.

In this paper, we propose a proof of concept using the Click platform [START_REF] Kohler | The click modular router[END_REF], in which we have previously developed different modules [START_REF] Yassin | A programmable controller for unified management of virtualized network infrastructures[END_REF]. Note that our solution could have been developed based on eBPF or even VPP, which are more adapted to virtualized environments.

III. DESIGN GUIDELINES

A. Guidelines and principles of the proposed architecture

We proposed a general framework of a service driven SDN architecture in [START_REF] Sanner | Dices: A dynamic adaptive service-driven sdn architecture[END_REF]. At a high level, the architecture consists of:

• An orchestrator whose goal is to assemble, deploy and carry out network services in the network based on templates describing elementary network services, which are stored in a repository.

• Distributed controllers that drive the network elements and are in charge of executing the network services. They form together what we call an extended and distributed SDN control plane.

• Simplified, generic, programmable and efficient network elements (white boxes) in charge of the forwarding plane, which are driven by the local controllers in order to implement the different network services. Two principles underlie and guide the definition of this framework. Firstly, the introduction of models enabling the dynamic definition of network services. These models rely on templates that describe elementary network services. They are used and assembled by the orchestrator to compose, validate and deploy the targeted service. Secondly, a generic SDN controller function is available and ready to be instantiated and activated in all the network components. These controllers functions can be organised hierarchically at different levels to manage the control plane logic and different levels of locality.

Figure 1 depicts a set of generic networks nodes commonly referred to as "white boxes" carrying distributed and differentiated network services modeled with components. These network services components are composed of a set of elementary network functions assembled using a graph modeling approach and Petri nets models as described in [START_REF] Sanner | Dices: A dynamic adaptive service-driven sdn architecture[END_REF]. Petri nets modeling provides the necessary tools to check the consistency of the adopted models. A communication channel carries management and control messages between the orchestrator and the network nodes.

1) SDN management plan: The deployment of these components is ensured on demand by the orchestration function through the control & management channel. The management channel, represented by a yellow arrow in figure 1, is used to set up new components on nodes corresponding to different data plane functions or to update the current components running on the data plane. The orchestrator function is in charge of network functions deployment decisions based on human requirements or based on some automatic processes. It is also in charge of the effective deployment and of the update of the network components. The network service component can be completely updated, partially updated, i.e. some network elements in the graph, or completely or partially removed and modified.

2) SDN control plane: The SDN control plane channel is encapsulated in the communication channel like the management channel. It is represented by the green arrows which connect the upper controller and the local controllers integrated in the different components nodes. The SDN control plane is also distributed between the upper controllers and the local controllers connected to the elements of components which compose the data plane. Upper controllers and local controllers carry the smart functions of the data plane. These functions are distributed between the local and upper controllers to manage hierarchically different levels of locality.

B. The distributed controller function

To implement our distributed SDN controller function we use the programmable controller for unified management of virtualized network infrastructures proposed in [START_REF] Yassin | A programmable controller for unified management of virtualized network infrastructures[END_REF]. The role Thus, this flexible controller function can be used for our SDN control plane in a distributed or in a hierarchical way. We however extend its functionalities in programmability and make it able to connect and exchange with other controllers to distribute analysis and decision functions.

IV. A DISTRIBUTED MONITORING USE CASE

A. Use case motivations

The architectural concepts of the proposed extended SDN control plane are illustrated through a distributed monitoring function as it presents the following characteristics:

• A monitoring function is an elementary subset of any network service function. It is necessary in the design of a network service. It must be available on any node.

• A monitoring function can involve some intelligence at the local node level. Such intelligence cannot be managed with standard Openflow switches.

• Monitoring functions can be more or less complex depending on operator requirements and context scenarios and can be designed as context aware and upgraded dynamically, on demand.

• A monitoring function can generate a lot of control traffic particularly in the case of SDN OpenFlow networks, where the monitoring is centralized and is done by pooling.

• A monitoring function can involve some locality constraints for instance if a high responsiveness is required.

• A monitoring function can involve a lot of ressources when a sophisticated analysis is required. It justifies the benefit of dynamically adjusting the use of computing resources.

B. Use case description

The general principle of the use case is as follows. The goal is to detect an elephant flow, which consumes too much bandwidth, at the expense of other flows; then to take corrective measures if necessary at the node that detects this flow, usually a network entry point.

In order to optimize CPU resources, we only integrate at first a basic monitoring function in the network nodes. This function is generic and has little impact on resources and is distributed on all nodes of the network in the same way (step 1 in figure 2). This basic monitoring function is only able of detecting, at wire speed, a large, increasing variation in traffic on one of the nodes via a local controller and a global counter shown in figure 3.

If an abnormal increase in traffic is detected by a controller, this latter sends an alert to the higher-level controller, which then decides to install, on-the-fly, a more elaborated monitoring function, taking into account other possible criteria such as the position of the node in the network graph. For example, if it is an ingress node, the more complex monitoring configuration would then be able to perform a fine-grained analysis and identify the abnormal flow at the origin of the anomaly (step 2 in figure 2). The identification is achieved through an enhanced monitoring service, which can identify IP sessions and calculate their average throughput. This computation can be done in particular through additional controllers, i.e. local flows controllers that will interact with the first global flow controller in figure 4.

When detecting an anomaly, a corrective action is implemented by the local controller (step 3 in figure 2). It may consist in activating and configuring a traffic shaper that is included in the enriched configuration and that will limit the rate of the elephant flow.

A threshold-based mechanism on the global traffic volume allows the return to the initial monitoring configuration without risks of oscillations.

We illustrate by this use case the following properties that cannot be realized in an Openflow context for the already mentioned reasons:

• upgrade, without interruptions, of a generic configuration, • resources' optimization on nodes,

• intelligent processing and local analysis of flows,

• distribution of the analysis on several elementary controllers that interact and organize in a distributed or hierarchical way the control plane,

• differentiated distribution of functions according to nodes and needs,

• complexification or simplification of processing at a node level as required.

Local controllers

Step 1 to step 2

Step 2 to step 3 Fig. 2: Monitoring use case steps

V. IMPLEMENTATION OF THE USE CASE

A. Click

The Click Modular Router [START_REF] Kohler | The click modular router[END_REF] solution consists in launching a "Click" engine (program), in partial or total replacement of the standard linux kernel network of a physical or virtual machine. The engine provides a library of "elements" that can be assembled through a configuration script to compose a directed graph datapath, representing a particular service.

Packets travel along oriented edges between vertices (elements) in which specific processing is applied (classification, rewriting . . . ). The class of an element specifies a fixed or open number of input/output ports and its behavior (function).

The generic syntax is:

(element a )[output x ] -packets → [input y ](element b ).
Packets are processed, following the functions coded in each element possibly parametrized through a configuration string. At the border, 'FromDevice' & 'ToDevice' elements achieve input/output from/to network interfaces. Besides, elements expose "handlers" (interfaces) for exchanging with each other or with a remote manager, at run time.

The Click engine itself exposes "global handlers" for controlling the overall operations. In particular, one of them allows a "hot-reconfiguration" meaning a fast reloading on the fly of a whole new graph.

At design time, the Click router is made from standard and customized sources (C++ classes), allowing to extend the library of elements. Click can be built for running either as a user application which is more convenient for testing/debugging experimental developments, or as a kernel module when better performances are expected.

A configuration script is given as an argument when launching the Click router. It comprises the definitions of the graph and initial parametrization of its elements. Basically, standard elements accomplish simple though efficient operations. Smart processing can be specified through classification rules for example, to dispatch different flows onto different edges.

B. A new controller element in Click to control the dataplane

For the needs of our demonstrator and to illustrate the proposed concepts, we extended the functionality of the Click controller agent introduced in [START_REF] Yassin | A programmable controller for unified management of virtualized network infrastructures[END_REF]. This element offers a programmable automation mechanism where some actions can be performed, as a result of a logical/arithmetical combination of global or local element handlers, following a control expression written in an ad hoc language. This expression is evaluated periodically, upon packet event or on demand. If need be, actions are started by writing to arbitrary handlers. An External Call element exposes a 'command' handler informing about a job to be done when active. It can be polled by the upper controller which could in turn achieve a remote feedback. This logic is used, in our experiment to reconfigure on the fly the Click engine.

Beyond the basic logic functions of handlers composition, the main points of our extensions are:

• The ability to maintain variable values in memory. These variables make it possible, for example, to compute the Infinite Impulse Response (IIR) filter which allows us to smooth the traffic, to perform a traffic rate measurement.

• The possibility to read and write handlers of other controllers so as to be able to compose logically or arithmetically the results coming from several controllers attached to different Click components. Our controller can be programmed to perform the required operations by simple configuration like any Click element. Configuring a controller consists in configuring it with a control expression that describes the operations to be performed such as reading or writing handlers of Click elements, composing the values of these handlers to produce new results to trigger actions either directly at the local level, or at a more global level through the external element (cf. figure 3 for more details).

C. Implementation

Figure 3 shows how the basic monitoring function is implemented in Click (i.e. first step of the process illustrated in figure 2). The incoming stream is retrieved by the Click From Device element and goes through a Click classifier element that allows to collect the data streams on which the monitoring applies, for example TCP or UDP streams. The flow of interest then pass through a counter element and then through the queue and output interface elements.

A local controller allows reading the global counter and smoothing the extracted values. If the average value exceeds a fixed threshold, the controller activates the "external element" which allows raising a flag. Once this flag detected, the central controller downloads via the communication channel a more sophisticated Click monitoring configuration allowing a detailed analysis on flows.

Figure 4 shows how the more sophisticated monitoring function is designed in Click, to allow a detailed flows analysis. The yellow elements are those that are downloaded and added to the previous configuration. We develop the

VI. IMPLEMENTATION RESULTS & FEEDBACK

Figure 5 illustrates the proof of concept composed of three virtual machines running on one physical machine. The VM2 node carries the simple or complex monitoring function that applies to a route flow between two input/output interfaces of the virtual machine. A traffic source and a receiver on the VM1 and VM3 virtual machines allow traffic scenarios to be performed. The global controller is set up on the physical machine and is in charge of downloading the complex monitoring configuration. It is a simple Python script daemon. The traffic generator successively generates over time a sequence of UDP sessions of variable time durations and bit rates. When an elephant flow is generated, there is a large growth of traffic which triggers steps 2 and 3 of figure 2. A test sequence is plotted in figure 6. It shows the progress of the test sequence that we performed with the incoming and outgoing flows. The sum of the incoming flows is drawn in blue, the outgoing flows in red. The incoming elephant flow is in green, the outcoming flow is in orange. It can be seen that the elephant flow is limited as soon as it appears in order to of the openflow approach. Such limitations are as follows: Firstly, the low programmability of Openflow switches which prevents sophisticated local processing. Secondly, The strong centralization that is inherent in the Openflow architecture limits the distribution possibilities. We base this concept on several design principles:

• A white box approach of generic programmable switches.

• A disaggregation of network services into elementary components assembled via templates that model the service using a graph framework.

• A service execution engine hosted on all nodes.

• The introduction of a controller function that takes the form of an intelligent and programmable agent that can be flexibly distributed in network service components. We then illustrate this concept on an adaptive monitoring use case with the objective of detecting and limiting elephant flows. We are therefore relying on the Click architecture for which we have developed the controller function inside the framework of a Click element. This implementation allows us to demonstrate the feasibility of the proposed concept. It also allows us to highlight, limitations inherent to the Click environment: Firstly, regarding current Click implementation, actual data links are statically defined. Therefore, only a reasonable number of flows can be considered. In contrast, the logic inside a given element has "no limit" in terms of complexity since this is pure software. For example, it can implement an open list of session/flow contexts, each with a state-machine. We developed such an element: Contrack implementing the basis of a statefull firewall. Therefore, two axes appear for implementing a complex logic with the Click technology:

• Gather all the logic in rich and specific multi-function elements, which can be inconsistent with the intent of the Click approach.

• Distribute the algorithm onto several more generic elements which require to find a way to keep the contextual knowledge between them, using meta-data for example. Secondly, the limitations of the hot upgrade mechanism of Click components that causes packet loss. It would probably require a differentiated and fine-tuned mechanism for updating components in order to reduce losses.

However, the proposed architecture allows flexible and reconfigurable network services to be implemented, distributed or centralized according to requirements. It can also be implemented to create the primitive OpenFlow scenario as a reference. In the following part of this work, we want to complete the notion of controller that we presented by specifying in detail the scope of the functionalities necessary to ensure a satisfactory programmability and modularity in order to be able to centralize or distribute the SDN control plane according to the requirements of network services.

Fig. 3 :

 3 Fig. 3: Minimal monitoring Click component

Fig. 5 :Fig. 6 :

 56 Fig. 4: Complex monitoring Click component

  is to expose heterogeneous resources in a unified way to the control and management entities. It is also able to provide computation resources to manage local or global configuration decisions. In the reference paper, the concept is illustrated in the context of a networking usecase based on the Click software router environment[START_REF] Kohler | The click modular router[END_REF]. We reuse this Click controller element as a SDN controller in our own design. This controller can be inserted in the data plane and triggered through packets arrivals as other Click elements or, it can operate autonomously and independently of the packets sequences. It is able to manipulate elements handlers making read and write functions on individual Click elements or on sets of elements like Click components. It also integrate a simple syntax langage to describe computing operations executed using read parameters.

	Repository	Orchestrator function
		Management channel
			Upper controller Upper controller
	SDN control plane		Control channel
	Local controllers		Local controllers
	Network service components	Network nodes (white boxes)	Network service components
	Fig. 1: Extended SDN control & management plane principles
	of this controller

IOvisor Project. https://www.iovisor.org/.


Hamza Ben-Ammar
email: hamza.ben-ammar@irisa.fr

Yassine Hadjadj-Aoul
email: yassine.hadjadj-aoul@irisa.fr

Gerardo Rubino
email: gerardo.rubino@irisa.fr

Soraya Ait-Chellouche
email: soraya.ait-chellouche@irisa.fr

A versatile Markov chain model for the performance analysis of CCN caching systems

Keywords: CCN, Caching, Markov Chain, Modeling

Beyond Content Delivery Networks (CDNs), Network Operators (NOs) are developing caching capabilities within their own network infrastructure, in order to face the rise in data consumption and to avoid the potential congestion at peering links. These factors explain the enthusiasm of industry and academics around the Content-Centric Networking (CCN) concept and its in-network caching feature. Many contributions focused these last years on improving the caching performance of CCN. In this paper, we propose a very versatile model capable of modeling the most efficient caching strategies. We first start by representing a single generic cache node. We then extend our model for the case of a network of caches. The obtained results are used to derive, in particular, the cache hit probability of a content in such caching systems. Using a discrete event simulator, we show the accuracy of the proposed model under different network configurations.

I. INTRODUCTION

The increase in data consumption over the past few years has allowed CDNs to be at the center of the content distribution value chain [START_REF] Cisco | Cisco visual networking index: forecast and methodology[END_REF]. Internet service providers (ISPs), for their part, are struggling to benefit from this increase. ISPs are, thus, investigating the possibilities of extending their infrastructure with caching capabilities to finally be part of the value chain.

The advent of Content-Centric Networks (CCNs) represents a real opportunity for ISPs [START_REF] Jacobson | Networking named content[END_REF]. In fact, these networks allow focusing on the content itself and not on its location, which in turn allows to overcome the limitations of the current Internet. Therefore, the end-users' requests (known as interests in CCN), that are routed to the Content Providers' servers, can be satisfied by the cached data at the intermediate nodes, thus reducing the round-trip time, network traffic and servers' load.

When content caching is possible, a significant improvement can be achieved, as shown in several studies [START_REF] Rossini | A dive into the caching performance of content centric networking[END_REF]. The analytical quantification of caching performance is, however, not sufficiently explored in the literature. In fact, several issues need to be addressed in order to understand the behavior of such a caching network. Indeed, in addition to the cache hit probability, other metrics deserve a deeper analysis, such as the average number of hops to reach a particular content, or the impact of cache size and traffic pattern on performance.

In our previous work [START_REF] Ben-Ammar | A Markov chain-based Approximation of CCN caching Systems[END_REF], we proposed an analytical model based on Markov chains to estimate the cache hit probability under the popular Least Recently Used (LRU) replacement scheme for a system with multiple caching nodes, where the default caching strategy of CCN, called Leave-Copy-Everywhere (LCE), is used. LCE consists in caching the requested contents in all the nodes along the downloading path. In this paper, we extend our work by proposing a versatile and general model, which is able to mimic the most efficient caching strategies developed for CCN like Leave Copy Down (LCD) and LRU-K [START_REF] Laoutaris | The LCD interconnection of LRU caches and its analysis[END_REF] [START_REF] O'neil | The lru-k page replacement algorithm for database disk buffering[END_REF]. Let's recall that in a multi-cache system, the decision of whether a data packet should be stored or not in the cache is managed using a caching scheme. Here, we intend to propose a methodology that allows modeling this process in general, that can be used to analyze different caching algorithms.

We consider in this work a network of caches in which the requests arrive independently and follow a popularity law (i.e. Zipf), which is generally the case in real systems [START_REF] Guillemin | Volatility of youtube content in orange networks and consequences[END_REF]. All the requests are forwarded through the shortest path to the nearest source. We start by proposing a discrete time Markov chain to model a single cache node. This model is, then, generalized to a system of caches. Compared to most of the existing contributions in the literature, the proposed solution can easily deal with different network topologies and allow having a good approximation of such type of caching systems.

The reminder of this paper is organized as follows. In Section II, we present the related work, which focuses on contributions providing an analytic model of caching systems. Section III provides the detailed description of the proposed model. Then, the evaluation of our proposal is introduced in Section IV. Finally, Section V summarizes the achievements of the paper and introduces our future work.

II. RELATED WORK

Many studies have been conducted to deal with the performance analysis of a single cache and a network of caches [START_REF] Zhang | A survey of caching mechanisms in information-centric networking[END_REF]. The study in [START_REF] King | Analysis of paging algorithms[END_REF], was probably the first attempt to evaluate and model caching systems. The author proposed a model for predicting the buffer hit probability under the LRU and FIFO replacement policies. Unfortunately, the computational complexity of this model grows exponentially with the cache size C and the number of data items R. Dan and Towsley proposed, in [START_REF] Dan | An approximate analysis of the LRU and FIFO buffer replacement schemes[END_REF], an algorithm, with a complexity of O(CR), for predicting an approximate cache hit probability under the LRU replacement policy. The proposed solution is, however, limited to the case of a single cache.

Che et al. developed, in [START_REF] Che | Hierarchical web caching systems: modeling, design and experimental results[END_REF], an analytic modeling technique, which was further investigated in [START_REF] Fricker | A versatile and accurate approximation for LRU cache performance[END_REF]. The solution allows identifying a characteristic time approximation for each item in the cache, which was used to estimate the cache hit rate. In [START_REF] Dan | An approximate analysis of the LRU and FIFO buffer replacement schemes[END_REF], the authors extended this algorithm to the case of a network of caches. Psaras et al. proposed,[START_REF] Psaras | Modelling and evaluation of ccn-caching trees[END_REF], a Markov chain-based caching model to estimate the proportion of time a given piece of content is cached, in the case of a single router. They also extended their model to cover the case of multiple caches. Nevertheless, the aforementioned proposals are applicable only when the LCE caching strategy is used.

Recently, there have been many proposals that treated caching schemes different from LCE in systems with multiple caches. In [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF], the authors extended the work of [START_REF] Che | Hierarchical web caching systems: modeling, design and experimental results[END_REF] and proposed a unified framework to analyze the performance of caches (both isolated and interconnected). Their model covers various insertion and eviction policies (including LRU). They evaluated the accuracy of their proposal through simulation. However, in the case of interconnected caches, the tests were conducted only in the case of a 6-nodes chain with fixed network settings. The authors in [START_REF] Gast | Ttl approximations of the cache replacement algorithms lru(m) and h-lru[END_REF] developed algorithms to approximate the hit probability of cache replacement algorithms that are variants of LRU and similar to LRU-K [START_REF] O'neil | The lru-k page replacement algorithm for database disk buffering[END_REF], by extending the work of [START_REF] Che | Hierarchical web caching systems: modeling, design and experimental results[END_REF]. Their study is, however, limited to the case of single caches.

III. A GENERAL MARKOV CHAIN MODEL FOR MULTI-CACHE SYSTEMS

We use here the LRU algorithm to manage the node's content store. Other memory management algorithms have been studied in the case of cache modeling like First In First Out (FIFO) and Random Replacement (RR). However, LRU is known to perform much better than FIFO [START_REF] Chrobak | LRU is better than FIFO[END_REF] and the expected long-run performances of both RR and FIFO replacement policies were shown to be roughly the same [START_REF] Gelenbe | A unified approach to the evaluation of a class of replacement algorithms[END_REF].

A. System description

In CCNs, the content's name is the only identifier of data. To request and retrieve data, two types of packets are commonly used [START_REF] Jacobson | Networking named content[END_REF]: Interest Packet and Data Packet. Clients can ask for specific data objects by sending Interest packets, which are forwarded towards the data sources using the Forwarding Information Base (FIB). A record of the forwarded Interests is kept in the Pending Interest Table (PIT) in order to keep track of the Interests waiting for a data packet. When a node receives multiple requests for the same content, the Interest packets will be aggregated in one entry in the PIT and only the first one is routed. Once the requested content is found, it is automatically routed back to the clients on the reverse path. All the nodes along this path can store a copy of data to answer future demands.

Let G = (V, E) be a graph representing a network of caches, where V = {v 1 , ..., v M } is the set of nodes and E ⊂ V × V is the set of links between the nodes. Let C = {c 1 , ..., c R } be the set of contents available for the users (the catalog). We assume that all the accessible contents in the system have the same size. The cache capacity is then expressed in terms of the number of objects that can be stored. All available contents are stored permanently at one or more servers attached to some nodes within the network. In the rest of the paper and for the sake of readability, we will use the term node/cache interchangeably as well as the terms rank/popularity and content/item/object.

Clients, which are attached to the network nodes, send requests into the network looking for content. The pattern of these requests is characterized by the Independent Reference Model (IRM) [START_REF] Dan | An approximate analysis of the LRU and FIFO buffer replacement schemes[END_REF]. Users generate, thus, an independent and identically distributed sequence of requests from the catalog C of R objects. Specifically, the probability p r to request an item c r from the set of available contents is constant and follows a popularity law, where the contents are ranked decreasingly according to their popularity from 1 to R. Since, in our work, we address video services, the contents feature a skewed popularity distribution. As already argued in many previous studies, the latter fits the Zipf law [START_REF] Fricker | Impact of traffic mix on caching performance in a content-centric network[END_REF]: the probability to request the content of rank r is:

p r = r -α / R i=1 i -α
, where α, the skew of the distribution, depends on the type of the accessible objects [START_REF] Fricker | A versatile and accurate approximation for LRU cache performance[END_REF]. For our approach, we only need to assume that 0 < p r < 1, for R ≥ 2.

B. LRU cache analysis

Let's consider a node in a CCN operating under the LRU replacement policy and having clients attached to it. Whenever a user requests a content of rank r in the catalog, it will generate a cache miss if the content is not present in the cache, or otherwise a hit. In the latter case, the object will be sent back to the user. In the case of a cache miss, the client's interest is forwarded to the next nodes in the direction of the nearest content server storing a permanent copy (i.e. origin server). Once located, the object is sent on the reverse path and depending on the caching strategy used in the network, the content will be cached or not in the nodes it passes through. In the general case, this decision can be seen as the probability that we denote β(r), with which a received content c r will be stored in a cache. The value of β(r) will then depend on the caching strategy adopted by the node. In the LCE policy, every object will always be cached by each node that passes by it, that is, β(r) = 1 for any content c r . In the LCD scheme [START_REF] Laoutaris | The LCD interconnection of LRU caches and its analysis[END_REF], for example, where a requested object is cached only on the node that resides immediately below the location of the hit, β(r) will be equal to the cache hit probability of the content on the parent node.

Suppose now that we have a cache managed with LRU and sized to contain N items, N R. Whenever a local cache hit or a caching decision occurs for an object, the object is placed at the top position in the cache. When a content c r is received, and for any given content c r (with r = r) occupying position i, three actions are then possible:

• c r will be moved down by one position if c r is outside the cache and it has been decided to cache it (with probability β(r)) or if it occupies block j with j > i; • c r will remain at the same position if c r occupies block j, with j < i, or if it is outside the cache and it has been decided to not cache it (with probability 1 -β(r)); • c r will be evicted from the cache if it occupies the N th position (last block) and if it has been decided to cache c r (with probability β(r)), which is outside the cache. Let us call a configuration of the cache any vector x = (x 1 , . . . , x N ), where x i is the content present at position i. We only consider the case where all positions are occupied because the cases where the cache is partially filled concerns only the initial transient phase. Let us denote by S the set of all possible configurations; we have

|S| = R!/(R -N )!.
The problem with exact analysis is the huge size of the state space S and the complexity of the chain. In the next section, we describe an efficient way of obtaining an approximation for such a metric that is shown to be very accurate compared to results obtained using simulations.

C. A general single LRU cache model

In our previous work [START_REF] Ben-Ammar | A Markov chain-based Approximation of CCN caching Systems[END_REF], we modeled the LCE caching strategy where every data packet is cached at every node that passes by it, which matches the case where the caching decision probability (represented by β(r)) is always equal to 1. In this paper, we extend our previous model MACS (Markov chain-based Approximation of CCN Caching Systems) to cover the general case considered here.

Let us consider a Markov chain X(r) = X h (r) h≥0 with N +1 states, as depicted in Figure 1. This chain will represent the evolution with time of the position occupied by content c r in the cache, where state N +1 means that content c r is absent, state 1 means that the object is at the top of the cache and state N that it is at the bottom. The probability that content c r stays at the same position s upon the reception of another item is denoted γ s (r).

Assume we know γ i (r), i = 1, 2, . . . , N, N + 1, satisfying 0 < γ i (r) < 1. This means that X(r) is irreducible and aperiodic. Let us denote by π(r) = (π 1 (r), π 2 (r), . . . , π N +1 (r)) its equilibrium distribution. Assume now that π(r) is exactly the marginal distribution corresponding to content c r and that the chains X(1), . . . , X(R) are independent of each other. The probability that a content of rank r remains in state s of the chain, s ∈ {1, 2, . . . , N + 1}, after a request arrives, is

     γ s (r) = γs(r) + R i=1,i =r (1 -β(i))piPmiss(i), 1 ≤ s ≤ N, γ N +1 (r) = 1 -prβ(r).
(

) 1
The value of P miss (r) used in (1) represents the cache miss probability of content c r (its calculation will be detailed later) and the value of γ s (r) is a special case of γ s (r) where β(r) is 1, and it is equal to

           γ 1 (r) = p r , γ s (r) = R i=1,i =r p i s-1 j=1 π j (i), 2 ≤ s ≤ N, γ N +1 (r) = 1 -p r . (2)
Again, observe that ( 1) is an approximation. Let's denote by T i,j the transition probability from state i to j in our model. Then, T i,j is equal to:

                   T i,i = γ i (r), 1 ≤ i ≤ N + 1, T i,1 = p r , 2 ≤ i ≤ N, T N +1,1 = p r β(r), T 1,2 = 1 -γ 1 (r), T i,i+1 = 1 -p r -γ i (r), 2 ≤ i ≤ N, T i,j = 0, j ∈ {1, i, i + 1}. (3)
The distribution π(r) satisfies the Chapman-Kolmogorov equations:

             π i (r) = N +1 j=1 π j (r)T j,i , 1 ≤ i ≤ N + 1, N +1 i=1 π i (r) = 1. (4)
If we develop the system of equations defined in ( 3) and ( 4), we obtain:

                       π 1 (r) = γ 1 (r)π 1 (r) + p r N i=2 π i (r) + p r β(r)π N +1 (r), π 2 (r) = (1 -γ 1 (r))π 1 (r) 1 -γ 2 (r) , π i (r) = (1 -p r -γ i-1 (r))π i-1 (r) 1 -γ i (r) , 3 ≤ i ≤ N + 1, π 1 (r) + π 2 (r) + • • • + π N +1 (r) = 1.
(5) By computing π N +1 (r), the cache miss probability, we can obtain the cache hit rate 1 -π N +1 (r) (with computational complexity of O(N R)). We can see from (5) that each π i (r) depends on π i-1 (r) (2 ≤ i ≤ N + 1), and once we get π 1 (r), we can calculate π N +1 (r) and deduce the cache hit probability. When β(r) = 1, we have π 1 (r) = p r . The equations then derived in ( 5) can be easily solved using (2):

             π1(r) = pr, π2(r) = pr(1 -pr) 1 -γ2(r) , πi(r) = pr(1 -pr) i-1 j=2 (1 -pr -γj(r)) i j=2 (1 -γj(r)) , 3 ≤ i ≤ N + 1. (6)
In the general case (0 ≤ β(r) ≤ 1), π 1 (r) cannot be computed directly, it depends on all the other values of π i (r) (for 2 ≤ i ≤ N + 1). One way to solve this problem is to modify the expression of π 1 (r) in order to reduce its dependency on the other variables. To do so, we first add and subtract in the expression of π 1 (r) the value p r ×π N +1 . Then, using the expression of γ 1 (r), and since N +1 i=1 π i (r) = 1, we get a new expression of π 1 (r):

π 1 (r) = p r (1 + (β(r) -1)π N +1 (r)) 1 -(γ 1 (r) -γ 1 (r)) . ( 7
)
Now, π 1 (r) depends only on π N +1 (r). The idea then is to use a fixed-point iteration in order to generate successive approximations to the solution, which consists on finding π N +1 (r), starting from an initial guess. To do so, we start by considering an approximate value of π N +1 (r) (that we denote by π N +1 (r)) by using the one obtained when β(r) = 1, to compute π 1 (r). Once we have π 1 (r), we can calculate π i (r) (2 ≤ i ≤ N + 1) using ( 5) to finally obtain a new value of π N +1 (r). The value of π N +1 (r) is also used to calculate γ s (r) (s ∈ {1, ..., N }) by replacing P miss (r) with π N +1 (r). These steps are repeated until we converge to the final solution by replacing in each step π N +1 (r) by the new computed value π N +1 (r) (Figure 2 shows that convergence is fast).

D. Multiple caches system

Following common practice [START_REF] Dan | An approximate analysis of the LRU and FIFO buffer replacement schemes[END_REF] [11], we assume in this work that after a cache miss and when a content is decided to be cached by a node, it will be downloaded instantaneously. Let's consider a system of multiple CCN nodes where the contents are forwarded according to the Shortest Path Routing (SPR) algorithm [START_REF] Wang | Ospfn: An ospf based routing protocol for named data networking[END_REF]. With SPR, when a client's interest cannot be satisfied by a node, it is forwarded along the shortest path to the closest permanent copy of the requested content. In this case, each node has to take into account, in addition to the local requests, the interests that come from other nodes due to a cache miss (we denote this stream of interests by "miss stream" or MS). The outgoing miss stream rate from a node u of a content c r is equal to

MS r (u) = req(r, u) × π N +1 (r, u), (8)
where req(r, u) is the total proportion of requests for c r received by u and π N +1 (r, u) is the miss probability of content c r at u. In CCNs the interests for the same object received by a node will be aggregated and only the first one is sent to the next nodes. This feature should be considered when computing the total miss stream received by a node having more than one child node. The incoming miss stream ratio for an object with a rank r at a node v, that we denote by η r (v), is equal to:

η r (v) = u:NH(u)=v MS r (u) w =u:NH(w)=v 1-MS r (w) . (9)
The set {u : NH(u) = v} represents the nodes having v as the next hop in the shortest path toward the source. The value of (1 -MS r (w)) represents the case where an interest sent from the node w is discarded because it was already received by another node. The probability that a node v will receive a request for c r will no longer be p r , but another value that we denote as p r , which will take into account in addition to the local requests, the interests due to a cache miss from previous nodes. For each node v, this value is equal to:

p r = p r + η r (v) R k=1 (p k + η k (v)) = p r + η r (v) 1 + R k=1 η k (v) . (10)
Consider again the previous Markov chain (see Figure 1). For every node v, we can compute the stationary state probabilities as we did in the case of a single node, by replacing p r with p r in equations ( 1), ( 2) and ( 5). As we mentioned previously, the cache hit probability of a content with popularity r is equal to 1 -π N +1 (r). To compute the cache hit performance of a multi-cache system, we start by treating the leaf nodes of the network since in our model, each node to know all the incoming stream of requests, including those received due to cache miss from previous nodes. Starting from the leaves, we go through the core nodes of the network until arriving at the source node, where the permanent copies of the catalog's objects are attached.

IV. PERFORMANCE EVALUATION A. Simulation environment

In order to evaluate the accuracy of our proposal, we compared the analytic model presented in previous section with the results of simulations using ccnSim [START_REF] Chiocchetti | ccnSim: An highly scalable ccn simulator[END_REF], which is a discrete-event and a chunk-level simulator for CCNs. The accuracy of MACS, compared to the simulation results, can be affected by many parameters. Our focus on the conducted experiments was on the following key settings: cache size and Zipf law's skew distribution value.

The simulations were conducted on two complete binary trees with 31 and 15 nodes 1 . In the simulation settings, we considered a catalog of contents containing 20, 000 1-chunk sized objects whose popularity distribution follows the Zipf's law. Permanent copies of the available contents were hosted on one repository attached to the root node of the network. We set a uniform cache store capacity on the CCN nodes, which was defined as a proportion of the catalog size. Different simulations were conducted with a cache store size varying from 0.1% to 1.0% of the catalog capacity. The clients, attached to the network's leaves, generated requests according to a Poisson process with a rate per client corresponding to one request per second (each client representing an aggregate 1 Realistic network topologies can be also used as we did in [START_REF] Ben-Ammar | A Markov chain-based Approximation of CCN caching Systems[END_REF]. of users). We tested also different values of the Zipf law's skew parameter α going from 0.8 to 1.2. As shown in many studies [START_REF] Fricker | Impact of traffic mix on caching performance in a content-centric network[END_REF], these two values correspond to the Zipf popularity exponent in the case of User Generated Content (UGC) and Video on Demand (VoD), respectively. As we mentioned previously, the Least Recently Used (LRU) is used as a cache replacement policy and the value of β(r) in our model is fixed to 0.52 . Next, we will expose and compare the cache hit results obtained with our analytical model and with the ccnSim simulation tool (due to lack of space, only the cache hit rate metric is shown and results related to specific caching schemes are not exposed). The numerical simulation results, shown in the graphs, depict the mean values taken over 30 runs, where 10 6 requests are sent in the network when the system reaches stability (i.e., all the caches become full) with error bars representing 99% confidence intervals.

B. Model results and analysis

Figure 3 shows the values of the average cache hit ratio versus the content popularity under different scenarios using a simulator and our analytical model MACS. For the sake of clarity, we considered in the graphs only the objects whose popularity goes from 1 to 500. We can see from the charts that our analytical model gives in average an accurate hit rate for the whole range of item population with different network settings. When the cache size is set to a low value (0.1% of the catalog), the model performs better even with distinct values of α and for different types of content popularity (see Figures 3(a) and 3(b)). In the case when the cache capacity is set to 1% of the catalog size (see Figures 3(c cache hit ratio per content in our model is estimated with a slightly lower accuracy compared to the other case (cache size of 0.1%). However, the cache hit approximation of the highlypopular objects remains precise in the different scenarios.

In Figure 4, we report the total hit probability as a function of the cache size and the Zipf law parameter α with two different network topologies. The goal here is to test a large range of values in the network configurations and see the model's performance in terms of accuracy. We observe that doubling the network size did not affect MACS performance since accuracy is similar in both tested networks. The results also indicate that the error rate of our model goes up when the total hit ratio is low. It can especially be seen when the value of α is equal to 0.8, where the cache exhibits a relatively poor performance. In the other cases, we obtain low error rates.

Figure 5 reports the cache hit rate at different levels of the network topology. Level one being the leaf caches and level five represents the root node. The results show that we get the best match between simulations and our model at the leaf nodes. The model's accuracy is slightly reduced at higher levels within the network. The main cause of this inaccuracy is related to the estimation of the miss stream. At the leaf nodes, the requests received contain only those generated by the clients, which can be easily estimated. However, the incoming miss streams of the nodes located at the core of the network are more difficult to estimate since they are computed using the cache hit rate of previous nodes.

V. CONCLUSION

We propose in this paper MACS, a Markov chain-based Approximation of CCN Caching Systems to estimate the cache hit probability under the popular LRU replacement policy. The versatility of MACS enables us to model different caching schemes and not just one specific strategy. The obtained results show that our model, compared to the simulations conducted under the ccnSim tool, can estimate with high accuracy the cache hit rate of a multi-cache system. In the future, we intend to use the model to analyze efficient caching strategies such as LCD and LRU-K, in order to better understand the main reasons of their performance. This will include examining various metrics in addition to the cache hit ratio like the content providers' load and the average distance or latency to retrieve data.

Figure 1 :

 1 Figure 1: General Markov chain model for a content c r in an LRU cache

Figure 2 :

 2 Figure 2: Cache hit ratio vs number of iterations in our algorithm of contents with different popularities under a single node (β(r) = 0.5, catalog = 20000, cache size = 0.25% of the catalog)

  (cache size = 1%, α = 1.2)

Figure 3 :

 3 Figure 3: Total hit vs content popularity under binary tree topology (31 nodes) Simulation (Tree31) MACS (Tree31) Simluation (Tree15) MACS (Tree15)

Figure 4 :

 4 Figure 4: Total hit rate of the network under binary tree topology (31 and 15 nodes)

  Figure3shows the values of the average cache hit ratio versus the content popularity under different scenarios using a simulator and our analytical model MACS. For the sake of clarity, we considered in the graphs only the objects whose popularity goes from 1 to 500. We can see from the charts that our analytical model gives in average an accurate hit rate for the whole range of item population with different network settings. When the cache size is set to a low value (0.1% of the catalog), the model performs better even with distinct values of α and for different types of content popularity (see Figures3(a) and 3(b)). In the case when the cache capacity is set to 1% of the catalog size (see Figures3(c) and 3(d)), the

Figure 5 :

 5 Figure 5: Total hit rate at different layers of the network under binary tree topology (31 nodes)

The results obtained using other values of β(r) are very similar in terms of accuracy.

We would like to thank the Lannion-trégor community and the Regional Council of Brittany for their financial support.


Imad Alawe

Yassine Hadjadj-Aoul

Adlen Ksentini
email: adlen.ksentini@eurecom.fr

Philippe Bertin

Cesar Viho
email: cesar.viho@irisa.fr

Davy Darche
email: §davy.darche@tdf.fr

Smart scaling of the 5G core network: an RNN-based approach

Keywords: 5G, Scaling, Load Balancing, Mobile Core Network, Prediction, Neural Network

The upcoming mobile core network, which will be based on Virtual Network Functions (VNF), will face an increase of data traffic on both data and control planes. This is due to the increase of the number of connected devices and the newly 5G supported-services like IoT, Connected Health Care etc. Therefore dynamic and accurate scalability techniques should be envisioned in order to answer the needs, in term of resource provisioning, without degrading the Quality Of Service (QoS) already offered by hardware based core networks. Although provisioning new resources is easier as it is a matter of software deployment, the strategy to use (when to scale and how much to scale) remains complex. In this paper we propose scaling techniques based on neural networks to forecast the upcoming load. Hence scheduling the resource provisioning should be in a manner that all the needed resources will be deployed and active when the load increases. In the same way, it will scalein the unneeded resources when the traffic load decreases. The proposal is tested via discrete event simulations using a traffic load dataset provided by a Network Operator. The results show clearly the robustness of our proposal compared to a thresholdbased scaling technique.

I. INTRODUCTION

With the upcoming generation of mobile network, namely 5G, several new services and markets are expected to emerge (i.e. IOT, Connected Health Care etc.). These new services will lead to an explosion of the number of connected devices, of different types and categories (i.e. watches, sensors, robots etc.). It could reach 28 billions of devices connected to 5G by 2021, in front of 17 billion in 2016 [START_REF] Nordrum | Popular internet of things forecast of 50 billion devices by 2020 is outdated[END_REF].

The increase of the number of User Equipments (UE) will be accompanied by an increase of the traffic over both the data and the control planes of the mobile network, and over both sides: the Radio Access Network (RAN) and the Core Network (CN). Especially, as demonstrated in [START_REF] Alawe | On evaluating different trends for virtualized and sdn-ready mobile network[END_REF], the Access and Mobility Function (AMF), the new generation component of the Mobility Management Entity (MME), is likely to be congested since it is the single point of access for the control plane in the core network. As shown, the overhead causes an increase in latency for the Network Access Stratum (NAS) procedures, up to some requests' rejects when certain load thresholds are exceeded.

Following the case listed above, the requirement of low latency for 5G networks is far from being achieved, and solutions need to be found. In this way, the 3GPP has rethought the Core network architecture, which aims at being more flexible and scalable. The new architecture, namely New-Generation Core (NGC) architecture [START_REF]3rd Generation Partnership Project (3GPP), "System architecture for the 5g system[END_REF], addresses scalability and flexibility by introducing more modular Network Functions (NF) to compose the control plane service, which could also relies on network virtualization via Network Function Virtualization (NFV).

The NGC is a great step further as it splits the monolithic component MME of the Evolved Packet Core (EPC) (4G core network) into the AMF, the Session Management Function (SMF) and the Unified Data Management (UDM). Indeed, this split offers more flexible opportunities but it doesn't tackle yet the scalability strategies and techniques. Therefore, the main aim of this paper is to tackle the scalability issue in the NGC environment, with a particular focus on the AMF. As the components of the NGC are now modular functions that benefit from NFV, deploying or shutting off the instances of the concerned function is more easier; but deciding when to do it, is still a complex process. Therefore, there is a need to define when to scale and the techniques that best fit for mobile networking.

In this paper, we propose different new proactive scaling techniques and strategies. These techniques are based on machine learning and neural networks, and adapted for mobile network. As for the strategies, it allows: (i) to control the load of each AMF in order to decrease the latency for a given procedure, (ii) to dynamically deploy new instances (Scale out) or shut off non used instances (Scale in) depending on the traffic load in the mobile network and in a proactive way. The strategies and techniques are tested and proved using discrete event simulations and based on real mobile load data. Also, the proposed proactive strategies and techniques are compared to a reactive scaling technique, showing the benefits of scaling instances in a proactive manner.

The remainder of this paper is organized as follows. Section II lists and analyses related work on scalability solutions for VNFs and more precisely for mobile core network components. Section III presents the assumed architecture based on NGC and NFV. Section IV describes the proposed solution process from data management to neural network testing. Model evaluation and results analysis are presented in Section V. Finally Section VI concludes this paper and introduces our future work.

II. RELATED WORK

As the components of the NGC are run as VNFs (using Virutual Machine -VM or containers), the scalability issue is now more a VM (container) deployment issue than a hardware deployment issue. It is crucial to decide accurately when to scale and how many instances to deploy or to shut off. Many solutions are proposed in the literature for VNF scaling.

In [START_REF] Dutta | Qoe-aware elasticity support in cloud-native 5g systems[END_REF], [START_REF] Carella | An extensible autoscaling engine (ae) for software-based network functions[END_REF] and [START_REF] Alvi | Load based automatic scaling in virtual ip based multimedia subsystem[END_REF], authors have proposed scalability based on thresholds. In this scaling categories usually two thresholds are defined: one for scaling in (SIT) and one for scaling out (SOT). When the load exceeds the SOT, a scale out process is launched. On the other side, when the load goes beneath the SIT, a scale in process is launched. This technique allows to scale the system reactively to the evolution of the system load. However, this technique may leads to oscillations, if the system load goes ahead and then beneath the thresholds. These oscillations will affect the overall system performance as they trigger much physical resources provisioning or releasing. Also, it is worth mentioning that many iterations may be needed in order to get the exact number of needed instances. In addition, reactive techniques act after a load increase or decrease. Thus the time elapsed between the scaling decision and the scaling process may lead to a performance deterioration.

Other techniques of VNF scaling are adaptive techniques. In [START_REF] Arteaga | An adaptive scaling mechanism for managing performance variations in network functions virtualization: A case study in an nfv-based epc[END_REF], the authors propose a mechanism that combines Q-Learning with Gaussian Processes-based system models, which allows to adapt to dynamic environments and improve the scaling policy before taking any action. Indeed, this proposal, as the authors assume, reacts better than static threshold. However, it remains a reactive solution, and hence inherits the same weaknesses. Also, it should be noted that using Reinforcement learning, may take a considerable time before staring to have the correct decisions. Indeed, this is not acceptable in systems like 5G, due to the time constraint of certain type of applications.

Some papers in the literature have opted for proactive solutions like in [START_REF] Bilal | Dynamic cloud resource scheduling in virtualized 5g mobile systems[END_REF]. Authors propose a solution based on time series model in order to forecast CPU usage from a historical dataset, and hence schedule resource provisioning pro-actively. This technique is interesting for its pro-activity, but it does not offer adaptation in case of traffic pattern evolution and is not compliant with mobile networks' requirements. Besides, the proposed solution considers only system level information, like CPU or memory usage, but for mobile networking in 5G, service level information should be taken into consideration aiming at reflecting better the global load of the core network.

III. ARCHITECTURE

In this paper, we consider using the New Generation Core Network (NGC). This architecture is the new 5G standard prepared by the 3GPP group. The architecture of the NGC In legacy 4G core network, the procedures of an attached UE on a certain MME should be processed only by this same MME. Thus, scaling-in an MME means transferring all the users' context to another MME before shutting off the first one. On the other hand, when scaling out, two solutions are possible: (i) the new MME handles new UEs and hence the deployed MMEs continue to serve the already connected UEs, (ii) some migration procedures should be launched, for load balancing purpose, to move some of the already attached UEs to the recently deployed MME. This fact made scalability a complex issue and shows that the EPC architecture is inflexible.

Therefore the 3GPP group have rethought the NGC architecture by envisioning deploying the Network Functions in a virtualized environment. Thus, scalability will be more a software deployment issue than a hardware installation issue. Also, in [START_REF]3rd Generation Partnership Project (3GPP), "System architecture for the 5g system[END_REF] 3GPP describes AMF instance addition and deletion procedures in a virtualized environment.

This approach made the scalability of the AMF function easier and the architecture more flexible from a deployment point of view. Nevertheless, the decision of scaling, like how much instances to scale in/out or when to scale, is still missing.

Based on the ETSI NFV reference architecture, the scalability of a VNF is a decision taken by the NFV Orchestrator (NFVO), using the information provided by both the Virtual Infrastructure Manager (VIM) and the VNF Manager (VNFM). Therefore, for the sake of simplicity, we have only added a Service Orchestrator (SO) to the NGC architecture in this work. As mentioned earlier, our approach aims to balance the load between the AMF instances and to scale in/out the AMF functions as required. So the intelligence needed to apply this strategy is located in the SO.

IV. AMF BALANCING AND SCALING PROPOSAL

In this section, we describe the used-methodology to derive fine grained predictions of the arriving traffic, which is later employed by the proposed load balancing model. Thus, we start by introducing the datasets, which were prepared for the learning phase. Then, we describe the considered neural network models. Finally, we discuss briefly the strategy used for load balancing.

A. Mobile Dataset and Data Classification

The dataset used in our work contains real mobile data collected by Telecom Italia Big Data Challenge [START_REF] Italia | Telecom italia big data challenge[END_REF] and hosted on Harvard Dataverse [START_REF]A multi-source dataset of urban life in the city of milan and the province of trentino dataverse[END_REF]. This dataset is rich of information. It contains two months of data collected on different Cells of the mobile core network of Mobile Italia in Milano, with a period of 10 minutes.

We assume in this paper that in each period of time 10% of the whole traffic (calls, sms and Internet traffic) is control traffic. The rest (90%) of the traffic is considered as user data traffic. In order to use the data in our contribution (training the neural networks and testing them), the data followed some sorting and classification processes.

First, the data is sorted following the timestamps and not the cell ids. In other words, for each period of time (10 minutes), we regrouped together the data of all the cells in Milano city. Then we extracted our 10% of control traffic load with their timestamps.

Once we have the needed data, we propose to shift from a prediction problem into a classification one. This means that at each time stamp, the load data will belong to a load class. The load classes are distributed as following: the variation between the minimum control load and the maximum control load over the two months is split into 10 intervals. Thus the period between each interval of load is a class. Therefore, depending on the class, we are able to determine how much AMF instances we need to absorb, as we know already the capacity of our AMF (20 process per second in our case).

Then, each class is coded in order to increase the learning factor and the accuracy of our neural networks. The coding of the classes is simple and based on 'one-hot' coding. In other words, the class are coded using a word of 10 bits (as there are 10 classes), and the first class code will be the first bit equal '1' and the others equal '0'. The second class will have the second bit equals '1' and the other equal '0'... etc.

Finally to sum up, at the end of the data processing and classification, at each time stamp over two months, instead of having a number of connection, a class of load is defined where the number of connection fits in the interval of the class.

B. Neural Network Models 1) Deep Neural Network:

As stated before, the scaling decision is based on prediction of the upcoming control traffic load using neural network models. In this contribution we have compared the prediction performance of two types of neural networks (DNN and RNN) using the mobile data classification listed above, in Section IV-A.

The DNN, or also called feed forward neural network, is composed of several neural layers. The DNN layers are classified as following: the input layer; the hidden layer(s); 2) Recurrent Neural Network: The RNN is another type of neural networks. In our contribution, only LSTM cell [START_REF] Hochreiter | Long short-term memory[END_REF] is used. The main difference between feed forward neural networks (i.e. DNN) and LSTM, is that the RNN keeps state memory of the last passed activation events in the network as temporal contextual information [START_REF] Sak | Long short-term memory recurrent neural network architectures for large scale acoustic modeling[END_REF]. Figure 2 illustrates the structure of an LSTM cell. An LSTM cell is composed mainly of an input and three gates: the input gate, the forget gate and the output gate.

The input x t is squeezed between -1 and 1 using the tanh function and can be noted as following:

g (t) i = tanh(b g i + j U g ij x (t) j + j W g ij h (t-1) j )
i and j respectively represent the cell and the neuron. b, U and W respectively denote the biases, input weights and recurrent weights into the LSTM cell. Then, the output of the input gate (a sigmoid gate), which is between 0 and 1 (I t ), is multiplied element-wise by g (t) i in order to determine which inputs are switched on and off. This operation is denoted as g • i. Afterwards an inner state (C t-1 ), providing an internal recurrence loop to learn the relationship between inputs separated by time, is ultimately added to the g • i.

Furthermore, the forget gate, a sigmoid function, is elementwise multiplied by C t-1 to determine which previous states should be remembered and which should be forgotten, allowing the LSTM cell to learn appropriate context. Finally, the output O t of the sigmoid gating function is multiplied by the squeezed inner state s t in order to get the LSTM cell output expressed as following:

h t = tanh(s t ) • O t
For more details on RNN and LSTM structures and functions, interested readers may refer to [START_REF] Goodfellow | Deep learning[END_REF].

C. Load Balancing

To equilibrate the load between the AMF instances, a control model developed and tested in a previous work [START_REF] Alawe | On the scalability of 5g core network: the amf case[END_REF] will be used. The used-controller is Linear Quadratic Regulator (LQR) [START_REF] Zhou | Robust and optimal control[END_REF]. The LQR aims to minimize the performance index in order to allow the system to converge to the goal with less controller action. So periodically, the LQR will calculate a feedback vector allowing to determine the relative capacity of each AMF, depending on its load. Once the relative capacities are calculated, they are pushed to the eNodeB in order to distribute the arrivals on the AMF instances depending on the load of each. For more details about the load balancing process please refer to [START_REF] Alawe | On the scalability of 5g core network: the amf case[END_REF].

V. MODELS EVALUATION AND RESULTS ANALYSIS

A. Simulator

In order to test the models, we developed a discrete event simulator in Python using Simpy [START_REF] Team-Simpy | Discrete event simulation for python[END_REF]. The simulator simulates the behavior of UE arrivals that are buffered in the eNodeB queue. Then, the simulated eNodeB will dispatch the arrivals on the active AMF instances based on their relative capacity calculated periodically as mentioned above. The dispatched UEs will be hosted in the corresponding AMF queue and processed following a speed of 20 requests per second. This means that the latency chosen for a given AMF instance is 0, 05 milliseconds. Also, a given UE procedure will be rejected, due to the overload of the AMF instance, if the number of requests bypasses 50 requests in the AMF queue. In addition to the relative capacity calculation for each AMF, the SO checks each 10 minutes the neural network model in order to get the load class of the next period. Depending on the predicted class, the SO determines the needed number of AMF instances to be deployed for the next period. If the number of instances will increase, the SO will deploy the instances 60 seconds before the next period. The 60 seconds are considered as deployment latency. It is the needed-time to deploy an AMF instance in the data center and to be fully operational. The deployment latency (60 seconds) is calculated as an average following the tests conducted in [START_REF] Frangoudis | Cdn-as-a-service provision over a telecom operators cloud[END_REF]. Otherwise, for scaling in the AMF instances, the SO will order the removal of the over provisioned AMF instances 60 seconds after the next period in order to be sure that the load have decreased and avoid AMF overload. Finally, as the collected arrival data has a periodicity of 10 minutes, we distributed each period on 600 seconds in order to get more granularity and simulate a real traffic pattern. Therefore, the total number of arrivals of each period of 10 minutes is distributed following an inter arrival time, for each UE, calculated based on Poisson process law.

B. Scenarios

In order to test and compare our proposals, three different simulations were conducted. For the three simulations, we have considered the same arrival data (one week) with an AMF instance capacity of 20 requests per second. Also a deployment latency is considered over all the simulations equal to 60 seconds. The relative capacity refreshment of each AMF is achieved by the SO each 10 milliseconds.

1) Static Threshold Simulation:

The first simulation consists on validating our simulator and showing the behavior of a dynamic scalability based on a static threshold, while using our control model to balance the load over the deployed AMF instances. In addition to the simulation parameters listed above, we consider a scale out threshold of 80% of load of the overall deployed AMF capacity. The scale in procedure is launched once less than 10% of the overall AMF instances capacity is used. The scalability decision is checked each 2 seconds.

2) Deep Neural Network Simulation: In this simulation we deployed a DNN composed of an input layer; 3 hidden layers and an output layer. The hidden layer 1 is composed of 500 neurons, the hidden layer 2 is composed of 1000 neurons and hidden layer 3 is composed of 1500 neurons. In order to train our DNN, we extract 60% of the dataset, shuffle them, then inject them into the DNN as batches of 500. From the 40% of data left, we selected one week of data and injected it in the simulator (the same data as the other simulations). So in this simulation, the SO checks each period of time (600 seconds) the predicted load class given by the DNN for the upcoming 3) Recurrent Neural Network Simulation: Finally, for this simulation we deployed the RNN composed of one LSTM cell. This cell is composed 256 neurons. As the DNN, 60% of the dataset were shuffled and injected as batches of 500 in the RNN. In order to keep the value of our data classification for the RNN and get the best prediction accuracy, each training data of a batch is composed of one RNN chunk of which has the size of the word of a coded class [START_REF]A multi-source dataset of urban life in the city of milan and the province of trentino dataverse[END_REF]. Like in the DNN case, we selected one week of data from the 40% left in the dataset and inject it in the simulator(the same data as the other simulations).

C. Results Analysis

In Figure 4, we compare the number of deployed AMF instances in terms of the evolution of the load for (a) the threshold solution, (b) the DNN solution and (c) the RNN solution, and also the consequences on the AMF instances load in (d) threshold-based solution, (e) the DNN solution and (e) the RNN solution.

The threshold-based solution deploys up to 13 instances when the arrival rate is at the maximum rate as the RNN and DNN solutions deploy up to 12. On the other hand, when the load is at the minimum, the threshold-based solution deploys down to 2 instances, the DNN solution deploys down to 4 instances and finally the RNN deploys down to 3 instances. Although the threshold solution deploys more AMF instances than the RNN and the DNN solution, when the load is at its maximum, the AMF instances load is always reaching its maximum of 50 requests per seconds and thus the AMF instances are always overloaded. As for the DNN and RNN based solutions the AMF instances load is around 10 requests in the queue per seconds. This is explained by the fact that the threshold solution is reactive. Hence, it deploys the AMF instances after a load increase without foreseeing the time needed to provision new resources, which leads to AMF congestions and scaling oscillations.

On the other hand from Figure 5, we can see the consequences of overloading the AMF instances by evaluating the number of rejected requests: (a) Threshold-based solution, (b) DNN solution and (c) RNN solution, and the duration needed to process an attach request: (d) threshold solution, (e) DNN solution, (f) RNN solution. Comparing to the RNN and the DNN solutions, the number of blocked requests of the threshold-based solution is high. Also the attach duration of the UEs for the solution based on thresholds is always around 2.5 seconds as for the DNN and the RNN solutions is approximatively around 0.6 seconds. Hence, scaling in a proactive manner allow to avoid an increase of the latency while processing the control plane procedures.

Although the DNN is approximately similar to the RNN, it is worth mentioning that the RNN solution is slightly better that the DNN solution as it predicts more accurately (10% better than the DNN solution). This is shown in Figure 4, where we remark that when the load is at minimum, the RNN based solution scales in down to 3 whereas the DNN solution scales in down to 4 AMF instances. Indeed, the RNN predicts

VI. CONCLUSION

In this paper we proposed a novel solution to scale dynamically and pro-actively the VNF elements of the 5G new generation mobile core network. Our technique is based on neural networks where two different models are compared: the DNN and the RNN. Simulations, based on a real dataset of a Network Operator, showed that our solution scales in/out accurately the number of AMF instances depending on the load. Indeed, the proposed solution also bypasses the latency needed to provision new resources as it deploys in advance the needed number of AMF instances for the upcoming load; thus, avoiding overloading the core network and reducing the attach duration or the request process duration. We envision, for future work, to deploy our technique on a real platform in order to test its advantages on the field, and also we are willing to improve it in order to adapt when unexpected load pattern occurs.

Fig. 1 :

 1 Fig. 1: Architecture proposal for 5G

Fig. 2 :

 2 Fig. 2: Long Short Term Memory Cell Architecture

Fig. 3 :

 3 Fig. 3: Proposal Logic

Fig. 4 :

 4 Fig. 4: Evolution of AMF instances number with control traffic Requests (a) threshold-based solution (b) DNN-based solution (c) RNN-based solution compared to the evolution of AMF instances load with AMF instances number (d) threshold-based solution (e) DNN-based solution (f) RNN-based solution

Fig. 5 :

 5 Fig. 5: AMF instances number vs Blocked traffic Requests (a) threshold-based solution (b) DNN-based solution (c) RNNbased solution compared to the evolution of the UEs attach duration (d) threshold-based solution (e) DNN-based solution (f) RNN-based solution