Architecture for automatic reconfiguration of network ...

Architecture for automatic reconfiguration of network devices in response to events in the network Krzysztof Grochla, Leszek Naruszewicz Proximetry Poland, 40-203 Katowice, Al. Rozdzienskiego 91 [kgrochla|lnaruszewicz]@proximetry.pl

Abstract. The article presents the architecture of the network management system capable of autonomous reconfiguration of the managed devices by preprogrammed rules. The proposed architecture allows implementation of simple logical functions providing self-healing and self-optimization functions in wireless networks. The architecture is based on the centralized network management system and business rule management engine, which processes events in the network and decides whenever a preprogrammed rule should be started. Keywords: Network management, autonomous operation, self-optimization, SON

1

Introduction

Current wired and wireless networks consist of a very large number of devices. These devices are configured by the network operator. To automate this task, network management systems (NMS) have been developed. They consist of software and hardware which allow performing typical network administrator tasks. An NMS employs various protocols to accomplish these tasks. For example, the SNMP[1] protocol can be used to gather information from devices and send configuration change commands. Other popular network management protocols include NETCONF[2] and CWMP[3] (often referred also as TR-069). Typically, network management systems do not apply a logic which executes operations other than the ones directly initiated by the operator. The operator uses an NMS to execute configuration changes easier and quicker compared to logging directly into the devices. Some of the NMSes offer group configuration changes to automate reconfiguration of a large number of devices, or allow scheduling of an operation at a predefined time, but the network management software does not trigger configuration changes by itself. This paradigm changes with the introduction of the Self-Optimized Network (SON) concept, which was proposed as the part of the LTE standard by 3GPP [4]. The SON feature allows automation of several tasks to lower operation costs (OPEX). For example, in a SON-enabled LTE network the neighbor relations and Physicall Cell IDs are selected automatically [5]. The main functionality of SON includes self-configuration, self-optimization and self-healing. The costs of the

© Springer-Verlag Berlin Heidelberg 2011

network installation may be lowered by auto-configuration functions, which allow adding new active devices to the network, such as base stations, almost without any manual configuration [6]. Self-optimization and auto-configuration require implementation of new functions in the network management systems, namely algorithms that react to changes in the network state and reconfigure the network when needed as well as calculate the optimal parameters of the network operation. The NMS needs to react to planned changes, such as addition of a new base station, to failures and to variation of radio signal propagation. To perform such an operation correctly, it needs to monitor the statistics representing the current transmission conditions, as well as to react to events representing registration or loss of connectivity with a device. The automation of network management operations is very specific and related directly to the particular network installation or application. Some of the SON functions can be predefined and are valid for every network installation (eg. the PCI assignment in LTE), but others (e.g. reconfiguration in response to failures) require adaptation to the operator requirements. A vendor of the network management system is incapable of defining all possible operations, therefore it is more effective when such actions are defined or programmed by domain experts or network administrators. Some of the novel network management systems allow the network operator to predefine operations which are executed upon particular events, e.g Adrem NetCrunch [7] allows setting corrective actions to be taken in response to an alert. This functionality is often very limited and uses only a predefined set of triggers. In this paper, we propose an open architecture which enables building automation functions using a rule engine, which is external to the NMS server or central servers. This architecture allows flexible prototyping and validation of the autonomous operational rules, which change operation of the network in response to some events or to changes in the network performance.

2

Proposed architecture of the system

2.1

Generic architecture of the autonomous rule engine

NMSes are implemented as a centralized or a distributed system. A centralized NMS is based on a single server or a set of servers collocated within one location, which communicate over an IP network with managed devices and executes management operations. It stores the device configuration, network state, statistics and other data related to the network operation in a database. A distributed NMS consists of agents distributed among multiple network devices or distributed serves, without a single coordination point. The centralized approach is adopted by most of the network management tools available commercially and was the design goal of the management protocols[1-4]. In this work, we concentrate on the centralized architecture. We propose to extend the architecture by a new entity – the Autonomous Operational Rule Engine. It interfaces with the NMS using a network connection. The Rule Engine is a software system that executes one or more business rules in a runtime

production environment. It subscribes to the events and data it wants to monitor and executes rules defined by the operator.

Autnomous Operational Rules

Network operator

Network Management Server

IP Network

Managed device Managed device

Managed device

Managed device

Fig. 1. General view of the architecture for automatic reconfiguration of network devices

2.2

Detailed description of the proposed autonomous rule operation architecture

In the proposed architecture, the NMS server interfaces with the Autonomous Operational Rule Engine (AOR) through two layers of communication: the syslog events and the refreshing and provisioning operation protocol. The refreshing protocol is the standard external interface provided by the NMS for interaction with other systems or for communication with the GUI. It can be based on HTTP and web services, or any other protocol. It provides the following functionality that is used by the AOR:  transmission of the selected statistics gathered from network devices  subscription to network events  subscription to selected statistics  reconfiguration of network devices  definition and monitoring of QoS parameters. To allow triggering of an operation in response to any event logged by the NMS, syslog has been used as a secondary means of communication.

Desktop

Server DB Server GUI

Web Browser

DB

NMS Refreshing Protocol + Provisioning Operation

HTTP

NMS Logic SysLog

Syslog Events

AOR Web Server

govner

Rules Repository

Statistics Rule Engine

Rules

Knowledge Base

Communication Layer

Fig. 2. Interfaces between the NMS and the rule engine

The proposed Autonomous Operational Rule Engine consists of two modules: the Web Server providing the user interface and the Rule Engine which executes configured rules. The rules are stored in a database. The rule engine goes through all the rules either periodically or in response to a received event. The user interface needs to be extended with the functionality to define and configure the rules. This can be accomplished by using a web interface to simplify the communication.

3

Sample implementation

The proposed architecture of the automatic reconfiguration of network devices in response to events in the network has been implemented using the RedHat Drools business rule engine[8] and Proximetry AirSync NMS[9]. The rule engine has been divided into three elements: a queue manager, a network state builder, and a configuration manager.

Queue Manager

Network State Builder List of applied AORs actions

Stimulus

Current Network State

n tio m ee Pr

Stimulus

+

Stimulus

Action Stimuli queue

Stimulus

Collision resolution

New Network State

AOR Action to be applied/revoked

Configuration Manager Subsystem1 Transactio n Manager

Subsystem2

.. . SubsystemN

Fig. 3. Structure of the implemented rule engine

The AOR Queue Manager is responsible for queuing multiple stimuli which can be received from the network or external systems. By default, stimuli are inserted at the end of the queue and processed in the FIFO manner. The system defines a set of stimuli which are critical and preempts all other stimuli which are queued in the system. The Network State Builder takes a single stimulus from the head of the queue and, based on a list of actions defined by a given stimulus, builds a new network state. Each action is analyzed by the collision resolution module against the current network state and applied (or not) based on the predefined policy. The Configuration Manager is responsible for applying the new state to the network. It interfaces with all subsystems which need to be reconfigured, creates and manages configuration change transactions. 3.1

Sample functions

In the implemented system, the statistics related to a signal level were processed. As a sample operational rule we implemented reconfiguration of an existing QoS profile in response to change in modulation which is used on the link between a CPE and a base station. It allowed allocation of the same amount of radio resource blocks for this particular CPE, regardless of its distance to the BS.

4

Security and performance considerations

User accounting and access level verification should be maintained in the AOR Engine on the same level as in case of actions executed by the user directly in the NMS. Therefore, the AOR Engine needs to verify the user access rights in the NMS before applying any of the rules. When multiple operational rules are executed a large number of statistics needs to be forwarded to the AOR Engine. This may thwart the performance of both the NMS and the rule engine. To maximize the performance, the Rule Engine should be collocated with the NMS server within the same physical location and connected using fast network connection. When a particular rule is heavily exploited (e.g. applied on all devices), the AOR can be treated as a rapid prototyping tool and after testing the functionality, the algorithm can be implemented within the NMS. Our performance tests executed with Proximetry AirSync and JBoss Drools allowed execution of a single rule on all devices within the network composed of thousands of managed devices, but the performance depends heavily on the number of processed statistics and events.

5

Conclusions

The proposed architecture enables easy implementation and prototyping of the network self-optimization and self-configuration functionalities. The sample implementation showed that it can be used effectively with the JBoss Drools rule engine. References 1. K. McCloghrie, K. McCloghrie, J. Schoenwaelder, and D. Perkins, "Structure of Management Information Version 2 (SMIv2)". http://tools.ietf.org/html/rfc2578. 2. Bierman, R. Enns, M. Bjorklund, and J. Schoenwaelder, "Network Configuration Protocol (NETCONF)". http://tools.ietf.org/html/rfc6241. 3. "CPE WAN Management Protocol". TR-069 Amendment 4. Broadband Forum. July 2011. Retrieved February 16, 2012. 4. Hämäläinen, Seppo, Henning Sanneck, and Cinzia Sartori, eds. LTE SelfOrganising Networks (SON): Network Management Automation for Operational Efficiency. John Wiley & Sons, 2012. 5. Lukasz Chrost, Krzysztof Grochla: Conservative Graph Coloring: A Robust Method for Automatic PCI Assignment in LTE. Computer Networks, 268-276 6. Tragos E., Siris V., Bruno R., Grochla K, Ancillotti E.: Autmatically configured, optimised and QoS aware wireless mesh networks, Proceedings of IEEE PIMRC 2010. 7. AdRem NetCrunch, http://www.adremsoft.com/netcrunch/ 8. RedHat JBoss Drools, http://www.jboss.org/drools/ 9. Proximetry AirSync, http://www.proximetry.com/airsync-overview.php