Autonomic Network Management for Software-Defined and Virtualized 5G Systems

Transcription

1 Autonomic Network Management for Software-Defined and Virtualized 5G Systems Wei Jiang, Mathias Strufe, and Hans D. Schotten Intelligent Networking Group, German Research Center for Artificial Intelligence (DFKI) Trippstadter Str. 122, Kaiserslautern, Germany s: {wei.jiang, mathias.strufe, Institute for Wireless Communication and Navigation, Technische Universität (TU) Kaiserslautern Building 11, Paul-Ehrlich-Street, Kaiserslautern, Germany s: Abstract The Fifth Generation (5G) system is envisioned to become more complicated, which imposes a great challenge on network management. But today s manual and semi-automatic managing approaches are already costly and time-consuming. Thanks to new technologies, such as software-defined networking and network function virtualization, a possibility of autonomic management is opened for the 5G system. In this context, a novel management framework in software-defined and virtualized network is proposed by the SELFNET project so as to lower operational expenditure, improve user s experience and reduce time-to-market of services. As a key part of this framework, an Autonomic Manager (AM) is designed to provide the network intelligence by means of machine learning techniques. In this paper, the functionality and mechanism of the AM, as well as an intelligence control loop, are presented. A 5G test-bed established to demonstrate the autonomic management, along with some results on collecting and selecting network metrics, are illustrated. I. INTRODUCTION One of the consensuses for the Fifth Generation (5G) system is that mobile traffic in the year of 2020 will increase 1000 times in comparison with that of 2010 due to the proliferation of mobile Internet access [1]. The emerging applications, such as Internet of Things, virtual and augmented reality, self-driving car, and remote control, bring new system requirements, e.g., massive-connection provision, ultra-low latency and ultra-reliability [2]. To meet these requirements, the 5G system has to become more complicated [3], which are characterized by the following technical features: 1) a heterogeneous architecture consisting of marco cell, small cell, relay, and Device-to-Device link; 2) new spectrum paradigms, e.g., dynamic spectrum access, license-assisted access, and higher frequency at millimeter wave bands; and 3) cuttingedge air-interface technologies, such as massive antenna array and advanced multi-carrier transmission. The system s complexity inevitably imposes a great challenge on today s manual and semi-automatic network management that is already costly and time-consuming. Until now, This work was supported by the European Union Horizon2020 Programme under the 5G-PPP project: Framework for Self-Organized Network Management in Virtualized and Software Defined Networks (SELFNET) with Grant no. H2020-ICT / tackling network problems (systems failures, cyber attacks, and performance degradations, etc.) still cannot avoid manually reconfiguring software, repairing hardware or installing new equipments. A mobile operator has to keep an operational group with a large number of network administrators, leading to a high Operational Expenditure (OPEX) that is currently three times that of Capital Expenditure (CAPEX) and keeps rising [4]. Additionally, troubleshooting cannot be performed without an interruption of the network operation and violation in Service Level Agreement, which deteriorate the user s Quality-of-Experience (QoE) [5]. In this context, the EU H2020 SELFNET project [6] has been set up to design and implement an autonomic management framework for 5G mobile networks. Taking advantage of new technologies, i.e., Software-Defined Networking (S- DN) [7], Network Function Virtualization (NFV) [8], Self- Organized Network (SON) and artificial intelligence, this framework provides the capabilities of self-healing against network failures, self-protection against distributed cyber-attacks, and self-optimization to improve network performance and end users QoE [9]. Although SON has a self-managing function, it is limited to static network resources. It cannot suit to 5G scenarios, such as network slicing [10] and multi-tenancy [11], where dynamic resource utilization and agile service provision are enabled by SDN and NFV technologies. Currently, SON can only reactively respond to detected network events, while the SELFNET framework is capable of proactively performing preventive actions for predicted problems. The SELFNET framework aims to assist network operators to simplify management and maintenance tasks, which in turn can significantly lower OPEX, improve user experience and shorten time-tomarket of new services [12]. In addition to the software-defined and virtualized network infrastructure [13], the SELFNET framework consists of: 1) SDN/NFV sensors and a monitor that can extract the network status; 2) SDN/NFV actuators and an orchestrator that perform corrective and preventive actions; and 3) an Autonomic Manager (AM) that is in charge of diagnosing network problems and making tactical decisions. This paper focuses on presenting the functionality and mechanism of 243 VDE VERLAG GMBH Berlin Offenbach

2 the AM. First, the reference architecture of the SELFNET framework is briefly introduced in order to provide a complete view of the autonomic management. Second, the functional blocks of the AM and a closed-loop control of the network intelligence are presented. Third, a 5G test-bed that is established to demonstrate the autonomic management, along with an initial illustration of the network intelligence on collecting and selecting network metrics, are provided. The rest of this paper is organized as follows. Section II gives a brief overview of the autonomic management architecture. Section III introduces the network intelligence by means of the AM and an intelligence control loop. Section IV illustrates the set-up of 5G test-bed and some results on collecting and selecting network metrics. Finally, Section V concludes this paper. II. THE REFERENCE ARCHITECTURE Taking account into SDN and NFV technologies for the 5G system, the network intelligence is applied in software-defined and virtualized network infrastructure. To provide a complete view of the autonomic management, the reference architecture of the SELFNET framework [14] is given, as shown in Fig.1. The differentiated layers are briefly explained as follows: Infrastructure Layer: All network functions managed autonomously by the framework rely on physical and virtualized resources in this layer. It encompasses physical and virtualization sublayer. The former provides an access to physical resources (networking, computing, storage, etc.), while the latter instantiates virtual infrastructures on top of the physical sublayer. Data Layer: It implies an architectural evolution towards the SDN paradigm by decoupling the control plane from the data plane. In the SELFNET framework, the Data Layer represents a simple data-forwarding, which can be either non-virtualized or virtualized network function. Control Layer: This layer includes two internal sublayers: SDN controllers and SON control plane sublayer. SDN/NFV sensors and actuators, which are capable of collecting data from the entire system and enforcing actions, respectively, are also contained. Autonomic Layer: To realize the network intelligence, this layer consists of three modules, i.e., monitor, autonomic manager, and orchestrator. The monitor extracts data related to network behavior and uses these data to infer the network status. The AM is in charge of diagnosing the root cause of any existing or potential network problems, and deciding which countermeasure should be done. Following the tactical decisions from the AM, the orchestrator coordinates the physical and virtualized resources, and manages the SDN/NFV actuators, to execute the actions. NFV Orchestration and Management Layer: This layer is responsible for orchestrating and managing Virtual Network Functions (VNFs) via the VNF manager, as well as virtualized resources through Virtualized Infrastructure Manager (VIM). It conforms to NFV Management Fig. 1. An overview of SELFNET reference architecture. and Orchestration (MANO) specified by the European Telecommunications Standards Institute (ETSI) [15]. III. THE NETWORK INTELLIGENCE A. Autonomic Manager The AM can be regarded as the brain of the SELFNET framework and plays a vital role in the provision of network intelligence. Taking advantage of cutting-edge techniques in the field of artificial intelligence, it provides the capabilities of self-healing, self-protection and self-optimization by means of reactively and proactively dealing with detected and predicted network problems. As illustrated in Fig.2, the AM consists of the following functional blocks: Diagnoser is in charge of diagnosing the root cause of network problems. The monitor can derive a symptom for each detected or predicted network problem from the collected sensor data. The diagnoser processes the reported symptom to make clear its reason, and notifies the decision-maker. Decision-Maker (DM) can decide a set of corrective and preventive tactics to deal with the network problems based on incoming diagnostic information. A tactic is a high-level description of countermeasure, which needs to be transferred into an implementable action. Action Enforcer (AE) is responsible for providing a consistent and coherent set of scheduled actions to be enforced in the network infrastructure. For this purpose, this module recognizes and validates these tactics by applying conflict detection and resolution in order to provide implementable actions to be enforced. B. Intelligence Control Loop One of the main innovative aspects of the SELFNET framework is the network intelligence, which enables an autonomic management for 5G networks. Apart from the underlying software-defined and virtualized network infrastructure, a closed-loop control flow referred to as intelligence control 244 VDE VERLAG GMBH Berlin Offenbach

3 Fig. 2. An intelligence control loop. loop, starting from the sensors and terminating at the actuators, is designed. When the monitor detects or predicts a network problem, an intelligence control loop is initiated. The AM diagnoses the problem s cause, decides a tactic and plans an action. Once the orchestrator received an action request from the AE, it coordinates the physical and virtualized resources to enforce this action. The terminology indicating the control flow in Fig.2 are defined as follows: Sensor Data: According to [16], five differentiated data sources have been identified in the SELFNET framework. All monitoring information retrieved from physical devices, data plane, SDN controller, SDN/NFV sensors, and VIM, are uniformly called sensor data. The monitor is capable of analyzing and aggregating the collected sensor data so as to detect or predict network problems. Once a problem is found, a symptom will be derived and reported to the diagnoser. Symptom: A set of network metrics, such as alarms, events, Key Performance Indicators (KPIs) that can be evaluated to indicate the characteristics of an existing or emerging network problem, is defined as a symptom. Cause: It is a description of what the reason of a network problem is or why a network problem happens or will happen. Once the diagnoser received a symptom, it diagnoses the cause of this symptom. Tactic: After the cause of network problem is clarified, a countermeasure that can be applied to tackle this problem needs to be decided by the decision-maker. A tactic is a high-level description of countermeasure, which is required to be transferred into an implementable action. Action: It is an implementable version of a countermeasure to describe how to enforce, taking into account available physical and virtualized resources. The action provided by the AE contains more implementation details, e.g., actuators type and identity, the target location, the required resource and configuration information. C. An Exemplified Control Loop To further make clear its mechanism, we use an example to show the intelligence control loop. The storyline is depicted as follows: a summer concert is taking place in the city center, where a large number of spectators gathers in a small area. Some of the spectators start to share real-time videos in their social medias. When the number of video users increases, especially if some of them transfer videos in ultra-high definition, the network suffers from traffic congestion and the perceived Quality-of-Service (QoS) deteriorates. The monitor first detects this network s anomaly by means of continuously collecting and analyzing the sensor data. A symptom called video QoS decreasing is reported to the diagnoser. After an diagnosis, it is found that the cause of video QoS decreasing is the increased number of video users. Then, the possible tactics, which are load-balancing, video coding optimizing, and admission control, are determined by the decision-maker. The AE transfers these tactics into implementable actions and notifies the orchestrator. Taking into account available resources, the action of load balancing is finally selected and executed by the orchestrator. An actuator acting as a load balancer is instantiated, configured and deployed in the local network surrounding this concert. Afterwards, the congested network is successfully recovered and the perceived QoE of end users is quickly improved. IV. AN INITIAL ILLUSTRATION OF 5G TEST-BED A. Test-Bed Setup To demonstrate the autonomic management, a mobile network test-bed having the capabilities of self-monitoring and controllability is established. As shown in Fig.3, the setup of this test-bed conforms to the architecture of Mobile Edge Computing (MEC) [17], which was proposed by ETSI and specially designed for upcoming 5G networks. To implement a realistic network ecosystem, an open-source software-based LTE implementation called OpenAirInterface (OAI) [18] is adopted. It provides a full protocol stack of 3GPP LTE standard for E-UTRAN radio access and EPC core network. Relying on a software-defined radio module (USRP B210) at the enodeb side, a radio connection is established between an user equipment (UE) and the enodeb. Commercial UEs have been successfully tested to connect the enodeb and access the Internet, e.g., using an LTE-enabled ipad to browse webpages and watch YouTube videos. However, only a Mini-PC with an LTE surfstick rather than a commercial UE is applied here since commercial UEs are hard to install measurement tools (generally running on computer) for extracting network metrics. The Mini-PC acting as an UE and the server as enodeb form the RAN Edge of MEC. On the other side is the MEC Data Center (DC) Core of this test-bed, where three servers and two switches are deployed. First, the EPC server serves as the EPC core network of LTE system by means of running OAI softwares for the functionalities of MME, HSS and S/P-GW. It is connected to the enodeb at one side and to the Internet access switch 245 VDE VERLAG GMBH Berlin Offenbach

4 Fig. 3. The test-bed setup with Internet access and a separated monitoring network. TABLE I LIST OF NETWORK METRICS Fig. 4. Test-bed hardware fits into a server rack. at the other side. Then, the Internet access, marked by the blue-solid lines in Fig.3, is granted to the UE via the enobeb and EPC core network. Second, to facilitate a controllable network testing, a server is allocated to deploy network tools like iperf3 (to generate desired traffic) [19] and to provide internal services such as video-streaming. Third, the Autonomic Management server runs intelligence algorithms to monitor, diagnose and control the network infrastructure. For the initial illustration shown in this paper, this server acts as a data-sink for the collection of network metrics with the help of ZABBIX monitoring solution [20] and implements a feature selection algorithm to rank the collected metrics according to their relevance. This server is equipped with Graphics Processing Units (GPUs) to support a fast execution of intelligence algorithms. The hardware including servers, switches, Mini-PC, radio modules and antennas fits into a server rack, as shown in Fig.4, where the RAN Edge and the DC Core are not physically separated. B. Acquiring Network Metrics Since intelligence algorithms based on machine learning are data-driven, the collection of data is necessary for both No. Metric Definition 1 EPC Traffic In Incoming trafffic of EPC server 2 EPC Traffic Out Outgoing trafffic of EPC server 3 UE Traffic In Incoming trafffic of UE 4 UE Traffic Out Outgoing trafffic of UE 5 Server Traffic In Incoming trafffic of iperf3 server 6 Server Traffic Out Outgoing trafffic of iperf3 server 7 PLR Average Packet Loss Rate 8 Delay Round trip delay 9 Server Packet Out Number of iperf3 s outgoing packets 10 EPC Packet In Number of EPC s incoming packets 11 UE Packet In Number of UE s incoming packets 12 enb CPU Util enodeb s CPU utilization in percentage (%) 13 enb CPU Temp enodeb s CPU temperature in ( o C) 14 enb Mem Util enodeb s memory utilization 15 EPC CPU Util EPC s CPU utilization in percentage (%) 16 EPC CPU Temp EPC s CPU temperature in ( o C) 17 EPC Mem Util EPC s memory utilization 18 UE CPU Util UE s CPU utilization in percentage (%) 19 UE CPU Temp UE s CPU temperature in ( o C) 20 UE Mem Util UE s memory utilization training and operational phases. To guarantee the transmitting of network metrics, a separated measurement network is setup, as highlighted by the red-dashed lines in Fig.3. ZABBIX clients are installed in the servers and Mini-PC where metrics needed to be extracted. These clients are connected to the ZABBIX database running on the Autonomic Management server via a switch, which is specific for the measurement traffic carrying the collected metrics. It is noted that the data traffic, such as YouTube video-streaming, is transferred in an independent network route through the Internet access switch. The reason is to avoid potential collisions. In the previous tests, the data and measurement traffic are not separated. When testing data traffic congestion, the measurement traffic is also blocked. 246 VDE VERLAG GMBH Berlin Offenbach

5 Fig. 5. Relevance weight of features. In this paper, we illustrate the operation of test-bed by means of an example of traffic congestion. A testing procedure is designed as follow: 1) Configure the maximal bandwidth of the Internet access switch to 768kByte/s. 2) Run the enodeb and EPC. 3) Connect the UE to the network, visit YouTube.com and start a video down-streaming. 4) Generate traffic of 2.5MBytes/s by the iperf3 server and inject the traffic into the Internet access switch. Once the iperf3 traffic arrived, the congestion occurs. 5) After a period of congestion, terminate the iperf3 traffic so as to return to the normal status. During the whole test, the network metrics listed in Table I are periodically (one sample per second) collected and stored by the ZABBIX database. A dataset consisting of 20 metrics with 720 samples per metric is obtained. C. Feature Selection In practice, there are a large number of network metrics can be extracted from the 5G infrastructure. And every metric needs to be periodically recorded, resulting in a huge volume of data. When the management system tackles a specific network problem, e.g., the traffic congestion, it is inefficient (if not infeasible) to process all metrics. In essence, only a relatively small number of all available metrics are relevant to a problem, while others are either irrelevant or redundant. Because the network intelligence based on machine learning algorithms is data-driven, irrelevant and redundant metrics degrade the performance both in training speed and predictive accuracy. Hence, it is necessary to determine the metrics relevance. The learning machine should be built on relevant metrics, while discarding others, to simplify processing and improve performance. Feature Selection (FS) is one of the most important intelligence techniques and an indispensable component in machine learning and data mining [21]. It can reduce the dimensionality of data by selecting only a subset of features to built the learning machine. In this test, we take advantage of a classical FS algorithm called Relief-F [22] to calculate the relevance of the collected metrics. To be specific, it is applied to make clear which metrics listed in Table I are most relevant to the congestion. The acquired dataset with the dimension of is input to the Relief-F algorithm. Fig.5 shows the selection outcomes, which are relevance weights ranging from 1 to 1. The larger the weight is, the more relevant to the congestion. As we can see, the 6 th and 9 th metrics, namely Server Traffic Out and Server Packet Out, are the most relevant metrics. That is reasonable since the root cause of this congestion is the large traffic generated by the iperf3 server. The data of some of the most relevant and most irrelevant metrics are visualized in Fig.6. As shown in this figure, Packet Loss Rate (PLR) suddenly rises when the congestion occurred and returns to zero once the congestion stopped. We can derive from the data that PLR is also highly relevant. According to Fig.5, PLR is indeed the third relevant metric. On the other hand, there are some irrelevant features such as EPC CPU Temp and Server Traffic In. As illustrated in Fig.6, the CPU s temperature of the EPC server randomly fluctuates around 39 o C that is independent with the occurrence of traffic congestion. Another shown metric is the incoming traffic of the iperf3 server. Since the congestion happens in down-streaming traffic from the server to the UE, the upstreaming traffic cannot provide useful information. V. CONCLUSIONS This paper investigated autonomic network management for software-defined and virtualized 5G systems. Starting from a brief overview of the SELFNET framework, the functionality and mechanism of the Autonmic Manager, which provides the capabilities of self-healing, self-protection and self-optimization, have been presented. To demonstrate the network intelligence, an MEC-compliant 5G test-bed was established and introduced. An example of traffic congestion was experimented on this test-bed. The results proved that the applied intelligence algorithm can successfully select the most relevant metrics. But we have to say that it is just an initial step of the autonomic management. For further works, more intelligence algorithms will be studied, designed, evaluated and integrated into the Autonomic Manager. The test-bed will be extended to a larger scale in order to process a wide range of network problems and fully implement the network intelligence. REFERENCES [1] 5G white paper, NGMN, Feb [2] A. Osseiran et al., Scenarios for 5G mobile and wireless communications: the vision of the METIS project, IEEE Commun. Mag., vol. 52, no. 5, pp , May [3] J. G. Andrews et al., What will 5G be? IEEE J. Sel. Areas Commun., vol. 32, no. 6, pp , Jun [4] Top ten pain points of operating networks, Aviat Networks, [5] B. Bangerter et al., Networks and devices for the 5G era, IEEE Commun. Mag., vol. 52, no. 2, pp , Feb [6] Framework for self-organized network management in virtualized and software defined networks. EU H2020 5G-PPP SELFNET project. [Online]. Available: VDE VERLAG GMBH Berlin Offenbach

6 Fig. 6. Data visualization of the most relevant and irrelevant metrics. [7] B. A. A. Nunes et al., A survey of software-defined networking: Past, present, and future of programmable networks, IEEE Commun. Surveys, vol. 16, no. 3, pp , [8] R. Mijumbi et al., Network function virtualization: State-of-the-art and research challenges, IEEE Commun. Surveys, vol. 18, no. 1, pp , [9] J. P. Santos et al., SELFNET framework self-healing capabilities for 5G mobile networks, Trans. on Emerging Telecommu. Tech., vol. 27, no. 9, pp , Sep [10] X. Zhou et al., Network slicing as a service: enabling enterprises own software-defined cellular networks, IEEE Commun. Mag., vol. 54, no. 7, pp , Jul [11] K. Samdanis et al., From network sharing to multi-tenancy: The 5G network slice broker, IEEE Commun. Mag., vol. 54, no. 7, pp , Jul [12] L. J. G. Villalba et al., D2.1 - Use cases definition and requirements of the system and its components, EU H2020 SELFNET project, Tech. Rep., Oct [Online]. Available: [13] P. Neves et al., The SELFNET approach for autonomic management in an NFV/SDN networking paradigm, Intl. Journal of Distributed Sensor Networks, vol. 16, no. 2, pp. 1 17, Feb [14] R. Cale et al., D2.2 - Definition of APIs and interfaces of the SELFNET framework, EU H2020 SELFNET project, Tech. Rep., Mar [Online]. Available: [15] Network Functions Virtualisation (NFV): Management and Orchestration, ETSI, Tech. Rep., Dec [Online]. Available: [16] L. J. G. Villalba et al., D4.1 - Report and prototypcal implementation of the monitoring and discovery module, EU H2020 SELFNET project, Tech. Rep., Sep [17] M. Patel, et al., Mobile-Edge Computing introductory technical white paper, Mobile-Edge Computing (MEC) industry initiative, [18] N. Nikaein et al., OpenAirInterface: A flexible platform for 5G research, ACM SIGCOMM Computer Communication Review, vol. 44, no. 5, pp , [19] iperf - The ultimate speed test tool for TCP, UDP and SCTP. [Online]. Available: [20] ZABBIX: The enterprise-class monitoring solution for everyone. Zabbix LLC. [Online]. Available: [21] V. Kumar and S. Minz, Feature selection: A literature review, Smart Computing Review, vol. 4, no. 3, pp , Jun [22] I. Kononenko et al., Estimating attributes: analysis and extensions of RELIEF, in Proc. of the 6th European Conf. on Machine Learning, Catania, Italy, Apr. 1994, pp VDE VERLAG GMBH Berlin Offenbach