GB2534938A - Communication network performance monitoring - Google Patents

Abstract

A communication network performance monitoring system is provided comprising an intelligent network server 102 configured to receive network performance indicators from a plurality of network Operational Support Systems, network OSS, the network OSS comprising at least a radio OSS 106, a microwave OSS 108 and a backhaul OSS 110. The received network performance indicators are used to identify a performance problem. A performance-enhancement solution is selected to address the identified performance problem by adjusting at least one network parameter selected from any one of the plurality of network OSS. By overseeing plural OSS, the self-organizing network (SON) server 102 can resolve problems in one subsystem by remedial action in another subsystem.

Description

COMMUNICATION NETWORK PERFORMANCE MONITORING

FIELD OF THE INVENTION

The present invention relates to an apparatus, method and computer program for monitoring the performance of a communication network.

BACKGROUND OF THE INVENTION

Cellular telecommunications networks characteristically provide "cells" of radio communication coverage between communication devices (which are typically mobile) and a core network (with a "downlink" from core network to communication device and an "uplink" in the opposite direction).

Various radio access technologies (RATs) are implemented: currently digital cellular networks are the most common and these are loosely classed as second generation (2G), third generation (3G), fourth generation (4G), etc. technologies according to whether the RAT achieves effective data communications that meet increasingly challenging requirements. Included in the 4G standards are the third generation partnership project (3GPP) long term evolution (LTE) and LTE-Advanced (LTE-A), which correspond to release and later of the 3GPP standards. Legacy 1G systems used analogue radio transmission of mainly voice data, whereas 2G systems utilise digital radio transmission. Earlier 2G wireless communication systems used only circuit switching, but later 2.5G systems used both circuit and packet switching, as do 3G systems. 4G and LTE/LTE-A technologies are solely packet-switched, with circuit-switched fall-back to earlier technologies.

The way that the information is communicated on the radio waves differs between the different generations. 3G technologies use Code Division Multiple Access (CDMA) modulation and a hybrid core network that treats data and voice differently. CDMA employs spread-spectrum technology (transmission bandwidth greater than frequency content of original information) and a coding scheme where each transmitter is assigned a code, allowing several transmitters to send information simultaneously over a single communication channel. 4G technologies use Orthogonal Frequency Division Multiple Access (OFDMA) modulation on the downlink (SD-FDMA on the uplink) and an Internet Protocol (IP) core network to communicate both data and voice. OFDM is a frequency-division multiplexing scheme in which a large number of orthogonal sub-carrier signals carry data on parallel data streams or channels. Each sub-carrier is modulated at a low symbol rate giving a total data rate similar to a conventional single-carrier modulation scheme in the same bandwidth. OFDMA and SD-FDMA use very similar computational structures. The LTE wireless interface is incompatible with 2G and 3G networks, so it is operated on a separate wireless spectrum.

To ensure effective coverage of a large geographic area, a plurality of cells are provided by respective network nodes, referred to in 2G as base transceiver stations (BTS) or base stations, referred to in 3G as NodeBs and referred to in 4G as evolved nodeBs or eNodeBs. Base (transceiver) stations are associated with one or more antenna arrays which in turn establish respective cells. They are controlled at least in part by other entities in the core network known as controllers. In 2G technologies the controllers are base station controllers (BSC); in 3G the controllers are radio network controllers (RNC); and in 4G LTE and LTE-A technologies there is a flatter architecture without a BSC or an RNC and the eNodeB includes radio resource management functionality. In LTE and LTE-A, the eNodeB is connected to an Evolved Packet Core (EPC) via a mobile management entity (MME) for control plane signalling and a Serving Gateway (S-GW) for user plane data. In wireless communication systems the BTS, NodeB or eNodeB has a first (radio) interface to the mobile station (or user equipment UE) and a second interface to the core network.

The interface between the BTS/NodeB/eNodeB and the core network is known as the backhaul interface or backhaul link. In 4G networks there is a single Ethernet cable connecting an eNodeB to an IP backhaul network. In LTE/LTE-A the backhaul link comprises both an "Sl" interface which links the eNodeB to the evolved Packet Core and an "X2" interface that allows signalling between different eNodeBs. Both signalling and application data are communicated on the backhaul link. Currently, the physical backhaul interface is likely to be a Time Division Multiplexing (TDM) interface or an Ethernet interface. The X2 interface is not present in GSM (2G) or WCDMA (3G). In LTE, the X2 interface is only used for direct handovers between neighbouring eNodeB. For such direct handovers, the destination eNodeB co-ordinates with the S-GW/MME to shift traffic (that is being sent over the X2 interface during the handover) from the source eNodeB to the S1 interface for the destination eNodeB. There can be a large number of neighbours for each eNodeB (e.g. up to 32) and the set of neighbours for a given eNodeb is unique and dynamic such that a given eNodeB may have a set of radio neighbours that changes over time.

As wireless communication systems advance in technology, functionality and user uptake, the maintenance of wireless networks is becoming more complex, time-consuming and expensive with users expecting continuing improvements in Quality of Service (QoS) and network coverage. It is desirable to keep operational expenditure associated with network maintenance as low as possible without compromising on QoS. The coexistence of multiple standards 2G, 3G and LTE and also multiple types of cells (e.g. macro, micro, femto and pico) means that a vast number of parameters have to be taken into account in optimizing network performance. It has been proposed by a 3GPP System Architecture Working Group 5 (SA5) to use principles of self-organizing (or intelligent) networks to allow fast deployment and configuration of BTS/NodeBs/eNodeBs and to adjust system parameters of BTS/NodeBs/eNodeBs to provide optimal (or at least improved) system capacity and service coverage.

There is a requirement to more efficiently and reliably diagnose and resolve wireless network failures and performance problems arising from, for example, equipment failure, vandalism and prevailing network conditions that could have an adverse effect on the QoS provided on communication links, such as traffic volume conditions and interference conditions. Efficient network tuning and troubleshooting can improve network coverage and QoS experienced by users.

BRIEF SUMMARY OF THE DISCLOSURE

According to a first aspect, the present invention provides an apparatus for monitoring a communication network, the apparatus comprising an intelligent network server having processing circuitry configured to: receive network performance indicators from a plurality of network Operational Support Systems, network OSS, the network OSS comprising at least two of a radio OSS, a microwave OSS and a backhaul OSS; identify a performance problem based upon the received network performance indicators; select a performance-enhancement solution to address the identified performance problem, wherein the performance-enhancement solution comprises an adjustment, initiated by the intelligent network server, of at least one network parameter selected from any one of the plurality of network OSS.

This recognises that the principles of an intelligent network can be applied, not simply to BTS/NodeB/eNodeB deployment and management, but can be applied more generally across different aspects of a wireless communication system such as two or more of the radio management system, the backhaul link management system and the microwave dish management system. For example, a problem arising in the radio management system could potentially be resolved by implementing a compensatory (or remedial) action in the backhaul link management system if the intelligent network is configured to have an oversight of network parameters across two or more different network management systems.

Furthermore, in some embodiments, the repository of performance-enhancement solutions can be progressively improved, responsive to recent network conditions by dynamically adapting the rankings of candidate solutions based on their observed relative effectiveness when implemented.

In some embodiments the network performance problem is identified in one of the microwave OSS, the radio OSS and the backhaul OSS and wherein the selected performance-enhancement solution comprises at least one network parameter adjustment in a different one of the microwave OSS, the radio OSS and the backhaul OSS.

In some embodiments the intelligent network server is configured to determine a category for the identified performance problem into one of a predetermined number of categories.

In some embodiments the apparatus comprises a repository of performance-enhancement solutions for storing a plurality of trial solutions depending upon the determined category of performance problem, wherein the intelligent network server is configured to select the performance-enhancement solution from the repository of performance-enhancement solutions.

In some embodiments the selection of the performance-enhancement solution from the plurality of trial solutions is based upon a ranking for each of the plurality of trial solutions.

In some such embodiments the ranking is updated by the intelligent network server, based upon a self-learning process comprising evaluation of results of implementation of the plurality of trial solutions.

In some embodiments the intelligent network server is configured to save a current state of a set of network parameter values to allow restoration of the parameter set to the current state after implementing the performance-enhancement solution.

In some embodiments the apparatus comprises a responsibility matrix database for storing contact information corresponding to at least one engineer responsible for addressing the detected performance problem.

In some embodiments the intelligent network server is configured to initiate sending at least one of a telephone call, an SMS (Short Message Service) message, an email and an instant messaging message to the at least one engineer, specifying a required network maintenance action.

In some embodiments the performance problem corresponds to at least one of a Base Station Controller, a Radio network Controller and a Microwave System Controller.

In some embodiments the performance problem corresponds to deterioration in service quality on one of a radio link, a microwave link, an Internet Protocol link and a fixed line capacity.

In some embodiments the network performance parameters received from the radio OSS comprise network performance parameters corresponding to at least two of: a 2G technology, a 3G technology and an LTE technology.

In some embodiments the performance problem corresponds to a dual stack radio link, wherein the dual stack radio link substantially simultaneously uses Asynchronous Transfer Mode, ATM, and Internet Protocol.

In some embodiments the identified problem relates to deterioration in the Internet Protocol component of the dual stack radio link and wherein the performance enhancement solution comprises converting the dual stack link to an ATM only link.

In some embodiments the ATM link is converted back to a dual-stack link when the intelligent network server determines that the Internet protocol component of the original dual-stack link has recovered from the deterioration.

In some embodiments the communication network comprises network OSS corresponding to a plurality of different vendors and/or operators.

In some embodiments the intelligent network server is configurable to initiate implementation the performance-enhancing solution and to store a result of the implementation for use in calculation of the ranking of the plurality of trial solutions.

According to a second aspect the present invention provides a method of monitoring a communication network, comprising the steps of: receiving at an intelligent network server, network performance indicators from a plurality of network Operational Support Systems, network OSS, the network OSS comprising at least two of a radio OSS, a microwave OSS and a backhaul OSS; identifying, using the intelligent network server, a performance problem based upon the received network performance indicators; selecting by the intelligent network server, of a performance-enhancement solution to address the identified performance problem, wherein the performance-enhancement solution comprises an adjustment, initiated by the intelligent network server, of at least one network parameter selected from any one of the plurality of network OSS. There is further provided computer software operable, when executed on a computing device, to cause one or more processors to perform a computer implemented method according to the above aspects of the present disclosure.

A further aspect provides machine-readable storage storing such a program.

Various respective aspects and features of the present disclosure are defined in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which: Figure 1 schematically illustrates a network topology of a wireless communication 15 network employing an intelligent network management system according to one embodiment; Figure 2 schematically illustrates a high level overview of the method implemented by performance-enhancement software on the intelligent network server 102 of Figure 1; Figure 3 is a flow chart schematically illustrating a self-learning performance improvement response of the intelligent network server of Figure 1 to an alarm detected in one of the wireless network entities; Figure 4 is a flow chart schematically illustrating automatic reporting of network performance problems detected by the intelligent network server 102 via alarms; Figure 5 is a flow chart that schematically illustrates a self-learning process implemented by the intelligent network-server; Figure 6 is a flow chart that schematically illustrates how the intelligent network server collates and processes information from the radio, microwave and IP management systems; Figure 7 schematically illustrates a dual stack problem in which an IP link of the backhaul OSS develops a problem; Figures 8A to 8D schematically illustrate results of field tests where an intelligent network according to the present technique was implemented to compensate for a "down site" (BTS/NodeB/eNodeB failure); Figures 9A to 9C schematically illustrate trial results of an implementation of the intelligent network according to the present technique in a 2G portion of a wireless network, where a single task is implemented to add best neighbour cells; and Figures 10A to 10D schematically illustrate results of a trial implementation of the intelligent network according to the present technique to a 3G neighbouring sequence comprising three RNCs corresponding to a single operator;

DETAILED DESCRIPTION

Figure 1 schematically illustrates a network topology of a wireless communication network employing an intelligent network management system according to one embodiment. The communication network comprises: an intelligent network server 102, which has access via an internet connection 104 to a Radio Operations Support System (OSS), a microwave dish OSS 108 and a backhaul link OSS 110 through a mobile operator security firewall 112. The radio OSS 106 comprises: a base station controller 122, which controls a BTS 123 of a 2G wireless mobile communications standard such as GSM (Global System for Mobile communications); an RNC 124, which controls a NodeB 125 corresponding to a 3G wireless communication standard such as WCDMA (Wideband CDMA) or TD-SCDMA (Time Division Synchronous CDMA); and a Mobility Management Entity (MME) 126, which controls an eNodeB corresponding to an LTE/LTE-A standard.

A transmitter such as 123, 125, 127 may, in some cases comprise a single pylon having antennae such that it can function as two or more of a BTS, a NodeB and an eNodeB simultaneously. In the radio OSS 106, network failures may occur via BTS/NodeB/eNodeB failure or via failure on any one of: a link between the BTS 123 and the BSC 122; a link between the NodeB 125 and the RNC 124; and a link between the eNodeB and the MME 126. In the radio OSS 106 transmission failures may also occur due to, for example, line of sight blocking, overloading of the cell or an increase in the bit error rate. The intelligent network server 102 is configured to detect and to remediate these different types of failure.

An intelligent network system according to the present technique is a self-organizing network is based on the principle that a wireless mobile network can be configured to perform self-configuration, self-optimization and self-healing based upon a self-organized network hardware and software that at least partially replaces the use of human beings and physical tools to perform the network maintenance and control. An intelligent server coordinates the self-organization in a global manner across multiple wireless technologies (2G, 3G, 4G), across multiple vendors/operators and across multiple network subsystems such as a radio subsystem, a microwave subsystem and a backhaul subsystem.

The microwave dish OSS 108 comprises a hub microwave transmitter 132 and a plurality of terminal microwave transmitters 134, 136 that may be used to convey user traffic and data (e.g. voice calls and data sessions) as well as control data used to adjust settings of network nodes.. Microwaves (frequency range of 1 GHz to 30 GHz; wavelengths 30cm to 1cm) are typically used for point-to-point communications because they cannot pass around hills and other large obstacles as well as lower frequency radio waves can. However, the small wavelengths of microwaves allows for conveniently-sized antenna that can be used to direct narrow beams to a receiving antenna and the relatively higher frequencies relative to radio waves allows for a higher information-carrying capacity.

The backhaul OSS 110 allows voice and data to be communicated between BTS/NodeB/eNodeB and between an individual BTS/NodeB/eNodeB and the core network (e.g. the Evolved Packet Core (EPC) in LTE/LTE-A).

As shown in Figure 1, there are three different types of backhaul connection in this example arrangement: a TDM backhaul sub-system 140; a hybrid backhaul sub-system 150 in which voice is communicated via TDM and data via an Ethernet link; and an IP backhaul sub-system 160 in which both voice and data are communicated via Ethernet. A mobile backhaul network can take on many forms depending on factors such as transport technology, mobile standard and operator preference. The TDM backhaul 140 shows a Radio Access Network Base station (RAN BS) 142 and a Radio Access Network Controller (RAN NC) 144. The RAN BS 142 may be a single network controller/gateway or alternatively may be a site composed of several network controllers (OSS, WCDMA, RNC or synchronization server). Similarly, the RAN BS 144 may be a single base station or a collection of several base stations of the same or different wireless technologies (e.g. a single RAN BS may comprise both a GSM and a WCDMA base station). The same is true of the equivalent RAN NC and RAN BS shown in the hybrid backhaul 150 and the IP backhaul 160.

The intelligent network server 102 has access to network performance parameters and/or any alarms stored in each of the Radio OSS 106, the microwave dish OSS 108 and the backhaul OSS and can retrieve and respond to this network monitoring and control information based on information in a solutions repository 150 and a responsibility matrix database 160. The intelligent network server 102, the solutions repository 150 and the responsibility matrix database 160 together comprise key components of the intelligent network system. The intelligent network server 102 is configurable to respond to any alarm and to process performance parameters in relation to any network element in any network management sub-system 106, 108, 110 regardless of the operator or vendor associated with the network element concerned. Thus, for example, faults and performance measurements and enhancements can be performed on any BSC, RNC, MME, BTS, NodeB, ENodeB, Mobile Switching Centre (MSC), microwave antenna, TDM backhaul link, hybrid backhaul link or IP backhaul link.

The intelligent network server 102 may be connected to the system of any network operator via a "network cloud" (not shown), such that it can be configured to receive network performance parameters from any mobile network in any country (geographical location) via the Internet. Furthermore 2G, 3G and 4G communication links can be substantially simultaneously monitored and adjusted/repaired by the intelligent network system.

A responsibility matrix database 160 stores information on wireless network engineers such as name, job title, engineering team affiliation, technical and/or geographical responsibility area, mobile number and email address. The responsibility matrix enables dynamic correlation of any detected alarm, required action and performance statistics retrieved by the intelligent network server 102 with a relevant engineer and enables real-time reporting of network performance to the relevant engineer or group of engineers.

Thus, for example, in response to detection of an alarm in the radio OSS 106 in a particular geographical location, an SMS and/or email alert is sent to the appropriate engineer to initiate investigation and resolution of the problem.

If a problem is detected in the microwave dish OSS 108, the intelligent network server 102 can initiate action by an engineer or by an appropriate software control system to re-route a microwave transmission by reorienting a microwave dish.

A plurality of remote management terminals 172, 174, 176 is each configured for connectivity with the intelligent network server 102 via the Internet 104 to access network performance information and to intervene in network performance optimisation where appropriate. Access to the intelligent network server 102 is controlled by authentication and security provisions to protect against malicious and/or unauthorised access. The remote management terminals 172, 174, 176 may be any type of processing device, such as, for example, a personal computer, a laptop, a tablet, a personal digital assistant or a smartphone.

Figure 2 schematically illustrates a high level overview of the method implemented by performance-enhancing software on the intelligent network server 102 of Figure 1. The intelligent network computer program 210 comprises: an alarm gathering module 212; an alarm categorization module 214; an alarm resolution module 216; a state capture module 218; a scenario generation module 220; and a parameter tuning module 222. The computer program 210 is executed on or on behalf of the intelligent network server 102 e.g. by a cloud-based implementation) and is configured to receive from an Operational Support System (OSS) 250 of any network vendor, network performance data comprising alarms. It is conventional for an OSS such as the radio OSS 106 of Figure 1 to track performance and locally monitor a series of alarms corresponding, for example, to an indication that a BTS equipment failure has occurred or that a bit error rate has exceeded a threshold value. The alarm system database may correspond to one or more of a plurality of wireless network technologies from 2G to 3G to 4G through to LTE-A and indeed to any future generations of wireless technology.

The intelligent network server 102 retrieves the alarm data over the Internet 104 by penetrating or circumventing the mobile operator security layer 105, for example, by opening secure ports to other networks and using Secure Shell (SSH) commands to keep the secure connection open. In Figure 2, the alarm gathering module 212 of treceives alarms from remote vendor/operator databases and sends them to the alarm categorization module 214 for analysis. The categorization could be, for example, to group the alarms into an OSS category (radio, microwave or backhaul) and/or a wireless technology category (2G, 3G or LTE) and/or a specific type of failure indication (e.g failure of link between eNodeB and MME) and/or a geographical location of the physical hardware with which the error is associated.

At the alarm-resolution module 216, at least one candidate performance-enhancing algorithm is run to search, for each alarm category, for a suitable performance-enhancement solution. For example, if an eNodeB has failed, one possible solution would be to redistribute network traffic previously handled by the failed eNodeB to one or more a neighbouring eNodeB(s) pending manual resolution of the failure by an engineer.

However, an alarm associated with one category of OSS does not mean that the intelligent network system is restricted to diagnosis and resolution of the problem within the same OSS. On the contrary, for example, an alarm indicating a problem in the radio OSS106 could be effectively addressed by the intelligent network server 102 initiating an action on the backhaul OSS 110. Thus the intelligent network server 102 is configurable to work as an interpreter and judge to identify performance problems or opportunities for service-level improvements is specific parts of the network and to make modifications or adaptations to any part of the network (whether in the same OSS or not) to resolve those performance problems. The program at the alarm-resolution module 216 stage checks for a suitable solution with reference to the repository of solutions 150 and/or the responsibility matrix database 160.

The state capture module 218 is configured, after at least one suitable solution has been identified by the alarm resolution module 216, to take a snapshot of relevant current network parameters is taken prior to implementing a trial performance-enhancement solution to enable an emergency rollback to this previous state at a later time in case the trial solution has unforeseen effects that are undesirable. The scenario generation module 220 generates a resolution scenario for the network performance problem. The resolution may be entirely an automated one, such as specific network parameter adjustments or may alternatively involve running a software "patch" to address the problem. The selected scenario may instead or additionally involve sending an SMS, email or other type of message to an appropriate engineer as identified via the responsibility matrix database 160. The parameter tuning module 222 is configured to generate a program script (or obtain it in full or in part from a software library) and send it to a relevant one or more OSS (radio, microwave or backhaul) for remote execution at the OSS command line 254. Each of the modules of the program 210 of figure 2 may alternatively be viewed as processing circuitry configured to perform the specified function.

Figure 3 is a flow chart schematically illustrating a self-learning performance improvement response of the intelligent network server 102 to an alarm detected in one of the wireless network entities. The process starts at process element 310 and proceeds to process element 312 where the intelligent network server 102 (see Figure 1) listens for radio alarms and transmission alarms generated by each wireless network operator in relation to the part of the wireless network under their control. The operator alarm databases are accessed via the Internet and with the authority of the vendor/operator in question for the intelligent network server 102 to penetrate or circumvent the mobile operator security layer 112 (see Figure 1).

The radio alarms may relate, for example, to equipment failures such as an eNodeB failure and a transmission alarm relates to detection of one or more retransmission requests or a failed QoS metric of a received signal (e.g. a high bit-error rate). However, the alarms are not limited to indicating failures but may also indicate performance deterioration of many other kinds. At process element 314, each detected alarm is categorized into a class of network performance problem depending upon the type of alarm. Thus, for example, the alarm may be categorized as a radio alarm, a transmission alarm, a microwave link alarm or a backhaul link alarm.

At process element 316, the server 102 determines if the alarm is a radio alarm and if not, proceeds to process element 318 where it is categorized as a different type of alarm such as a transmission alarm or a microwave alarm. A corresponding alarm response sequence (not shown) is instigated after process element 318, depending upon the category of alarm detected.

Returning to process element 316, if the detected alarm is determined to be a radio alarm then the process proceeds to process element 320 where it is determined based upon the detected alarm type whether or not the alarm corresponds to a down site corresponding to failure of a piece of radio equipment such as a BTS/NodeB/eNodeB. If the radio alarm does not relate to a down site, the process proceeds to process element 322, where it is determined whether the radio alarm relates to a radio propagation problem or a dual stack problem.

A radio propagation problem could be, for example, received signal strength below a threshold due to adverse interference conditions in a cell or could indicate that a transmitter is propagating an an abnormal pattern that is causing the transmitter to be halted but propagating. A dual stack problem is a problem related to an internet protocol network node associated with the radio OSS 106 (see Figure 1). Dual stack is a type of internet protocol network that runs Asynchronous Transfer Mode (ATM) and IP protocols at the same time.

Returning to process element 320, if it is determined at process element 320 that the radio alarm does relate to a down site then the process proceeds to process element 324 where the geographic allocation of the down site, denoted "site X", is ascertained and plotted on a network map based upon geo-location data accessible to the intelligent network server 102. An initial response is to wait for a predetermined (but configurable) period and check if the same alarm indicates that the site in question is still down. If the site is not still down, but has recovered spontaneously during the predetermined period, then the process returns to process element 312 to analyze the next alarm. However if the site X is found to be persistently down, because it has not recovered by the end of the predetermined period then the process proceeds to process element 326, where one or more best neighbours of the down site are estimated.

A best neighbour can be determined, for example, based on received signal strength or based on past performance statistics. Once a group of best neighbours is determined at stage 326, it is determined at stage 328 if one or more of the identified best neighbours is also down. If one or more of the best neighbours is determined to be down at process element 328 the process proceeds to process element 330 where the identified best neighbour down sites are added to a down list and the search is widened beyond the best neighbour subset of BTS/NodeB/eNodeB to identify any further down sites that are not best neighbours of site X and the process then returns to process element 326.

At process element 328 it is determined whether or not one of the best neighbours of site X, which were established at process element 326 is also down.

If it is established at process element 328 that either none of the best neighbours is down or all of the down neighbour sites in the widened search area have been identified then the process proceeds to process element 332. At process element 332, the intelligent network server 102 accesses information on all of the best neighbours that do not correspond to down sites and reads and collates at least a subset of parameters and settings associated with the working best-neighbour cells. Since the network control spans a range of different wireless network technologies, the parameters and settings relevant to 2G, 3G and LTE for the best neighbour cell may all be read and collated. Further configuration information from the best neighbour cells such as a transmission scheme (e.g. CDMA, WCDMA, OFDMA, GSM) and technology (2G, 3G, 4G, LTE, LTE-A) and microwave link routes and geo-location information may also be recorded and collated by the intelligent network server 102 for the purpose of addressing the problem associated with site X being down.

According to the present technique a single point of failure can be addresses from a plurality of different angles due to the intelligent network system having a global overview of parameter values and alarms raised for all network-sub-systems, all wireless technologies and a plurality of vendors/operators.

At process element 334, having gathered and analysed the best neighbour cell parameter settings, the intelligent network server 102 proceeds to implement a trial solution to the network performance problem of site X being down by adjusting at least one of the settings of at least one best neighbour site to compensate for the lack of network coverage resulting from site X being down. Anything from a single parameter at a single neighbour cell up to a full set of parameters at every neighbour cell may be adjusted at stage 334.

Thus to compensate for the down-site X, not only the radio parameters may be altered, but also transmission parameters, microwave parameters or any other parameters at some or all neighbour cells may be altered to compensate for the failure.

After the parameter adjustments have been made at process element 334, the process proceeds to process element 336, where the intelligent network server 102 waits for a period to allow the network traffic to settle and for the effects of the parameter adjustments to take effect on the cells. Once the system has settled to a steady state in this way, measurements are made on key performance indicators (KPIs) of the cells to assess the overall network performance impact of making the parameter adjustments. The KPIs of a subset or the full set of best neighbour cells may be taken or even KPIs from a wider tier of cel Is.

At process element 338, the results of the measurements made at process element 336 are stored in the solutions repository 150 where they are used to assign a ranking of relative effectiveness of trial solutions to resolve network problems associated with a particular alarm. Thus a parameter adjustment event at process element 336 that resulted in improvement or only limited degradation in KPIs will be ranked higher as a candidate solution for the given alarm than a parameter adjustment event that resulted in greater degradation of KPIs.

In this way, the intelligent network server 102 implements a self-learning process via trial and error or different candidate solutions to achieve the best network performance enhancement in response to an alarm being triggered. If at process element 336, an unacceptable level of KPI degradation is measured, judged, for example, relative to a set of threshold KPI values, then the process returns to process element 334 to perform a different parameter adjustment in an attempt to achieve less performance degradation. To promote efficiency and speed, the intelligent network system may limit the number of trial parameter adjustments performed to a maximum number and select the best solution from the maximum number of parameter adjustments tested.

At process element 336, when a parameter adjustment with an acceptable KPI change associated with a trial parameter adjustment is found, then the network is allowed to proceed with that set of adjusted parameters pending restoration of site X to an operational status. At process element 340, the intelligent network server 102 utilises information stored in the responsibility matrix database 160 to identify an engineer responsible for site X and messages the relevant engineer by SMS or email (or by some other messaging mechanism) informing the engineer of the parameter changes implemented to compensate for the failure of site X. The relevant network operator/vendor may also be informed separately of these changes. Once site X has been restored to an operational state, the set of parameters read and recorded by the intelligent network server at process element 332 may be used to restore the system to a parameter state prior to implementation of the parameter adjustment. The process then returns to process element 312 to process any further incoming alarms.

Figure 4 is a flow chart schematically illustrating automatic reporting of network performance problems detected by the intelligent network server 102 via alarms. In this example, there is a separate, but parallel chain of reporting for each of three alarm categories comprising: (i) a radio alarm chain 442a to 450a; (ii) a microwave link alarm chain 442b to 450b; and (iii) an internet protocol (IP) link alarm chain 442c to 450c. At process element 410 the intelligent network server 102 (see Figure 1) receives multiple alarm inputs from the radio OSS, microwave link OSS, backhaul link OSS and IP OSS (not shown). For example, the IP OSS may have an alarm indicating a transmission problem in the LTE/LTE-A Evolved Packet Core. The alarms are categorised according to an alarm type. The responsibility matrix database 160 (see Figure 1) is consulted to extract contact details of appropriate people to inform in connection with a particular alarm in a particular network entity in a particular geographical location. Thus, at process element 430, the intelligent server 102 differentiates between different alarm categories and forwards notification of the alarm to a reporting sequence as determined from information in the responsibility matrix database 160.

A given alarm may be associated with a single action to resolve the underlying performance problem and to clear the alarm, but may alternatively be associated with multiple actions in order to resolve the problem. For example, a particular performance problem in the radio OSS may require action by engineers of an associated backhaul link to compensate for or to resolve that problem. Thus a problem in one OSS may trigger cooperative solutions involving one or more different parts of the network.

If at process element 430 the alarm is determined to correspond to a radio link, the process proceeds to process element 442a where a radio responsibility matrix is consulted. Similarly, a microwave alarm category will result in invocation of a microwave links responsibility matrix at process element 442b and an IP alarm category will result in invocation of an IP links responsibility matrix at process element 442c. The processing stages of process elements 442b through to 450b for microwave alarms and for process elements 442c through to 450c for IP link alarms are very similar to the corresponding process elements 442a through to 450a for the radio alarms, which will now be described in detail.

At process element 442a, recognition by the intelligent network server 102 of a radio alarm results in a query being sent to the responsibility matrix database 160 to retrieve contact details, roles and geographical regions of responsibility relevant to addressing the particular network performance problem flagged by the alarm. At process element 444a, the relevant responsible people are identified from the responsibility matrix and a Technical Task (TT) is logged in the intelligent network server system and assigned to a single responsible person/team or multiple responsible people/teams as prescribed by the responsibility matrix database 160. At process element 446a, contact details from the responsibility matrix database 160 are used to send messages to each matched person/team identified at process element 444a. The messaging may be performed in a number of different ways such as via SMS, mobile call, email or instant messaging. The TT is assigned to the responsible person(s) at process element 446a, and next at process element 448a, the intelligent network server 102 listens to radio alarm clearing logs to detect when the alarm in question has been cleared by the system. Although clearing of the alarm in this example is expected to occur as a result of technical intervention by an engineer in response to the TT, the intelligent network server 102 may alternatively may independently implement a software solution to address the alarm or may additionally perform tasks in software such as resetting of system parameters to avoid degradation of network performance pending resolution of the alarm by the notified engineer(s).

At process element 450a, if it is detected when listening for alarms at the previous process element 448a that the alarm has been cleared, then the intelligent network server 102 waits for a predetermined (but configurable) stability period, then closes the TT in the system log sends an automatic notification to the relevant responsible engineer(s) that the alarm situation has been resolved.

Finally, at process element 460, the intelligent network server 102 causes generation of statistical reports to identify each alarm and its associated clearing period and providing an indication of the time taken by the engineer(s) to respond to and resolve the problem associated with the respective alarm. Process element 460 receives output from all alarm categories, which in this case includes output from the radio alarm clearing event at process element 450a, the microwave alarm clearing event at process element 450b and the IP alarm clearing event at process element 450c.

Figure 5 is a flow chart that schematically illustrates a self-learning process implemented by the intelligent network-server 102 (see Figure 1) to refine solutions to network performance problems. In this case rather than the human intervention solutions of the flow chart of Figure 4, algorithms are run and/or system parameter values are changed upon initiation by the intelligent network server 102 to ameliorate network performance problems. Similarly to the flow chart of Figure 4, the intelligent network server 102 is configurable to store and implement performance enhancement solutions corresponding to different a plurality of different categories of network performance problem such as radio and microwave link performance problems. Considering the radio OSS performance-enhancement solutions of process elements 510a through to 590a, the process begins at process-element 510a where a Number of Key Performance Indicator (KPI) values, such as, for example, DCLR (Drop call Ratio), CFR (Call Failure Ratio), Data Throughput or Download speed, Signal Quality, BLER (Block Error rate) and Interference Ratio.

The KPI values indicate that performance of one or more radio links could be optimised or at least improved and depending upon a pre-defined solution selected from the solutions repository 150. For example, in the event of received signal strength for a particular signal being poor, the transmitter power associated with that signal could be increased and the interference effects of that power increase could be assessed by the system for overall impact on performance. The pre-defined solutions are each assigned a default ranking when the solutions repository 150 is initialised and those rankings will be modified depending upon feedback derived from on-going implementation of the pre-defined solutions. The rankings are thus expected to change over time and to adapt according to prevailing network conditions.

At process element 520a, the intelligent network server 102 reads received KPI results and checks for any deterioration in network performance revealed by analysis of the KPI values. When deterioration of one or more KPI values relative to an acceptable range or threshold is detected, a highest ranked solution from the solutions repository 150 is selected for implementation. At process element 530a, a result of implementing the first ranked solution is assessed based upon, for example, the resulting change in the KPIs. If more than one KPI has fallen out of a desirable range at process element 510a, then more than one respective top-ranked solution may be implemented and assessed at process element 530a. At process element 540a, the effects on the KPIs of a second ranked solution are tested by the intelligent network server 102 and the effects on at least a subset of the full set of received KPIs is assessed at process element 550a. The process of sequentially testing each ranked solution and assessing the results of those tests on the KPIs is repeated for at least a subset of the relevant ranked solutions that have been predefined in the solutions repository 550.

At process element 570a all of the most recently tested solutions are re-ranked so that the most effective solution is ranked highest. In some embodiments, weighting may be applied for each test sequence so that previous rankings are also taken into account despite a most recent ranking of a given solution having been evaluated. At process element 580a, it is determined whether or not the relative rankings of the implemented solutions have changed as a result of the most recent round of testing at process elements 520a through 560a. If there has been no change then the process returns to monitoring incoming KPI results for any deterioration at process element 520a.

However, if it is determined at stage 580a that there has in fact been a change to the rankings, then that change is incorporated in to the learning of the solutions repository 150 by effecting a change to the stored rankings. The change can be either cumulative to reflect effectiveness of the solutions over a number of trial implementations or it can be a complete refreshing of the rankings based on the most recently determined results. As shown in Figure 5 a similar set of process elements 50b through to 590b is implemented for the microwave links. These will not be described in detail due to the similarity of the processing sequence to the radio KPI sequence processing described above. However note that a pre-defined solution to a radio KPI may involve a change to a microwave link KPI and/or a backhaul link KPI and/or an IP link due to inter-dependencies between the different OSS categories.

According to the present technique, a performance problem detected by the intelligent network server based on network parameter indicators from any one network OSS may be addressed by invoking a performance-enhancement solution involving an adjustment to one or more network parameters from any other network OSS, not only the network OSS in which the problem was detected. For example, if a microwave terminal (serving a Radio unit "BTS/NodeB/eNB") suffers from a performance problem like interference or BER, then radio parameters of the radio unit (BTS/NB/eNB) may be auto adjusted such that traffic is offloaded from that serving BTS/NodeB/eNB to it to one or more neighbour radio units (BTS/NBieNB) having microwave terminals clear of alarms.

As a further example, if a radio site (BTS/NB/eNB) suffers congestion in transmitter resources due to an increase in the number of served users (due to a music concert for example) then a corresponding microwave IP terminal may be configured by the intelligent network server to auto-adjust its bandwidth by borrowing extra bandwidth from one or more other microwave IP terminals (not congested) served by the same MW Hub to solve the detected radio site congestion.

Figure 6 is a flow chart that schematically illustrates how the intelligent network server collates and processes information from the radio, microwave and IP management systems. In alternative embodiments further management systems such as the backhaul link management are also incorporated into the system. Alarm logs and parameter exports are obtained by the intelligent network server 102 from remote network sites via the Internet 104. A set of radio management system alarms/parameters 610, a set of microwave management system alarms/parameters 612 and a set of IP management system alarms/parameters 614 are all supplied to the intelligent network server 102 at process element 620. Other management system data may also be supplied. At process element 632, it is determined whether a detected alarm is a microwave alarm and, if so, at process element 642 the intelligent network server 102 (see Figure 1) causes collection of a full set of parameter data for the microwave downlink with which the alarm is associated. The collected parameters in this embodiment include frequency, path distance, microwave dish azimuth and transmitted power.

At process element 644, the parameter gathering is extended to collect parameter data from a microwave chain of links (communication path) in the same network region (e.g. geographical location). At process element 646, a number of possible solutions to the microwave link performance problem are tested. For example, the power of the microwave transmission is increased and/or the microwave links are re-routed and/or the capacity of the microwave link is changed. Having investigated and evaluated possible solutions at process element 644, the most favourable solution amongst those tested is implemented at process element 648. Also at process element 648, the intelligent network server 102 waits for the network to stabilise to the effects of the implemented solution and subsequently reads the alarm clear log to establish whether or not the chosen solution has in fact been effective. The intelligent network server 102 also exports parameters to assess the impact of the implemented solution and feeds the solution impact into an intelligent network reporting matrix module 650 and also to a solutions repository module 660.

If the intelligent network 620 detects an IP alarm from the IP management system data 614 at process element, 634 then it proceeds to process element 672, where it collects further parameters relevant to diagnosis and resolution of the defective IP link. For example, in this embodiment, the IP range and the subnet mask values are obtained. Then, at process element 674, the intelligent network system implements and evaluates the impact of a number of different possible solutions to the alarmed IP link failure. Possible solutions in this category include, for example, an IP range swap and a bandwidth change. Once the most effective trial solution has been established at process element 674, the best available corrective action is implemented and then the network is allowed to settle for a settlement period to assess the impact of the implemented solution. Also at process element 674, the intelligent network server reads the alarm clear log relevant to the alarm arising at process element 634. Feedback from the implemented solution is provided to both the intelligent network reporting matrix module 650 and the solutions repository module 660.

If the intelligent network detects a radio alarm at process element 636 in Figure 6, then it is established at process element 682 whether or not this radio alarm relates to a BTS/NodeB/eNodeB failure (i.e. a "down site"). If a down site is detected at process element 682, then processing according to the alarm sequence flow chart of Figure 3 is implemented (i.e. process elements 320 through to 340). However, if it is instead determined at process element 684 that the radio alarm relates to a dual stack problem (see Figure 7 described below) rather than a down site problem then a different set of performance solutions is implemented. For all types of alarm in each and every management system the selected corrective action, the results of the tested solutions and the ultimate impact of the chosen solution are fed back to both the intelligent network reporting matrix module 650 and the information repository module 660. The intelligent network reporting matrix module 650 and the information repository module 660 may each comprise processing circuitry for performing the specified functions such as the alarm processing function, the solution testing function, the solution ranking function, the reporting function and the engineer/operator reporting function.

Figure 7 schematically illustrates a dual stack problem in a 3G wireless network in which an IP link of the backhaul OSS develops a problem. As shown in Figure 7, a first UE 710 and a second UE 712 are configured to communicate with a plurality of 3G NodeBs 714a, 714b via a radio interface (air interface). Each of the NodeBs 714a, 714b has an "lub" interface 715 with an RNC 720. The lub interfaces are implemented as dual stack interfaces, which simultaneously implement IP and ATM (asynchronous transfer mode).

The lub link 715 is a packet-based communication link. The packet based data from the lub is passed by the RNC to the core network via an Serving GPRS Support Node (SGSN) and on to a gateway GPRS support node (GGSN) and then a Packet Data Network (PDN) 750.

In the arrangement of Figure 7, the intelligent network server 102 (not shown) listens to the NodeB performance parameters and any alarms that have been triggered and also checks the status of the IP part of the dual stack link on the lub interface 715. In the event that the bit error rate deteriorates on the IP link 715, the intelligent network system converts the dual stack link 715 from ATM+IP into ATM only until the problem with the IP link is resolved. Note that when the IP route is down the whole NodeB is effectively a down site unless remedial action is taken. To compensate for the failure of the current IP link on the lub interface 715, the intelligent network server 102 looks for an alternative (currently redundant) IP link and switches the NodeB such that the lub interface 715 uses the newly identified IP link instead of the problematic one. However, if no suitable alternative IP link is available, the relevant maintenance engineers determined from the responsibility matrix database 160 are alerted to address the problem by human intervention. Once the intelligent network server 102 has resolved the problem with the original IP link, it will switch the NodeB 714a and the link 715 from the ATM only configuration back to the dual stack (ATM+IP) configuration and release the newly identified IP link.

Figures 8A to 8D schematically illustrate empirical results of a case study where an intelligent network according to the present technique was implemented to compensate for a "down site" (BTS/NodeB/eNodeB failure). The graph of Figure 8A shows bars 810 indicating traffic volume at the site as a function of time and also shows: a profile 812 corresponding to a mean signal quality; a profile 814 corresponding to a call drop rate; and a profile 816 corresponding to a call failure rate. It can be seen that the call failure rate plateaus at a high value from 22 February through to 14 March due to a down-period occurring in that time interval.

The remedial effects on network performance of implementing intelligent network management of the down-site for Figure 8A are illustrated by Figure 8B, which show markedly improved traffic volume in the down period (previously negligible traffic). The mean signal quality 824 is also improved in the time interval corresponding to the down period in Figure 8A. Although the call failure rate 826 in the Figure 8B graph has peaks consistent with the call failure rate in the Figure 8A scenario when Phase I of the intelligent network is implemented, an improvement is seen from Figure 8B when Phase II of the intelligent network is implemented, the improvement being characterised by a reduction in the call drop rate to well below Figure 8A down period levels. The call drop rate 822 increases in the time interval of Figure 8B corresponding to the down period of Figure 8A, but this shows that some calls are now being successfully established, rather than none. A comparison of the bar chart representative of traffic volume shows that a negligible traffic volume in the down period of Figure 8A is improved to a respectable traffic volume in the down period in the graph of Figure 8B.

Phase I of Figure 8B involved adjusting network parameters of two cells associated with the down-site, the adjusted parameters comprising at least one of: power control, idle mode, handovers, parameters and tilts. These adjustments allowed 1600 Erlang of the 2000 Erlang carried prior to the site going down to be recovered. The Erlang is a unit of telecoms traffic density. The Phase I intelligent network adjustments allowed some key performance indicators such as improved mean signal quality to be satisfied.

Figure 8C is a graph of performance indicators associated with a different down -site from the one in Figure 8A. Again, a down period is apparent from a plateau in a call failure rate profile 832 from 22 February through to 14 March. A call drop rate 834 and mean signal quality 836 profile are also shown in the graph of Figure 8C. Figure 8D is a graph showing the performance enhancement effects achieved by implementing Phases I and II of the intelligent network according to the present technique. Similarly to the improvements seen in Figure 8B relative to Figure 8A, a comparison of the call failure rate between Figures 8C and D shows an initial peak in phase I but an overall reduction in Phase II of the intelligent network solution and there is a marked improvement both in the traffic bar chart and in the the mean signal quality value 844.

Figures 9A to 9C schematically illustrate trial results of an implementation of the intelligent network according to the present technique in a 2G portion of a wireless network, where a single task is implemented to add best neighbour cells with a view to improving KPIs. As shown in Figure 9A, a total number of cells controlled by a 2G Radio Network Controller was nine-hundred and twenty-four and the intelligent network implemented a performance enhancement solution from the solutions repository 150 (see Figure 1) that resulted in thirty-two nearest neighbour cells being added to the cells controlled by the RNC and one hundred and twenty extended neighbours being added.

Figure 9B is a graph showing a bar chart giving traffic volume in Erlangs as a function of time for the particular RNC and also shows a call drop profile line 912 as a function of time. The new neighbours were added on 19 June (06/19/2014 on the time axis of Figure 9B). It can be seen that as the RNC settles to adapt to the newly added neighbours, the number of call drops falls from a comparatively high value in the period from 15 June 2014 through to 19 June 2014 to a reduced value thereafter through to the 23 June 2014 cut-off. The effects of the single-task performance enhancement are summarised in Table 9C, which shows that the traffic volumes before and after the intelligent network performance enhancement is implemented are not appreciably different, dropping by only 2% after the trial performance enhancement. However, the number of call drops is reduced by 12% overall and the number of 2G external handovers (2G EXT HO) increases by 7% on average as a result of the intelligent network management. It will be appreciated that the intelligent network can be configured to optimise or at least improve certain key performance indicators at the expense of others, depending upon the objective to be achieved.

Figures 10A to 10D schematically illustrate results of a trial implementation of the intelligent network according to the present technique to a 3G neighbouring sequence comprising three RNCs corresponding to a single operator. As shown in the table of Figure 10A, a first RNC denoted RNC10 has control over a total of three hundred and twenty cells and has one hundred and twenty-two neighbours added and sixty-eight neighbours removed as a result of a performance enhancement solution implemented by the intelligent network. A second RNC, denoted "RNC32", has three hundred and fourteen neighbours added and one hundred and two neighbours removed as a result of a performance enhancement solution implemented by the intelligent network.

As shown in the graph of Figure 10B, the neighbours were added on 19 June 2014, resulting in a small overall increase of 5% in traffic handled by the cell and a decrease of 11% in the call drop rate. As shown in Figures 10D and 10E, the second RNC, denoted "RNC10", showed a similar response to the intelligent network performance enhancement, with a 1% enhancement in traffic controlled by RNC10 after the neighbours were added by the intelligent network relative to the traffic before and a 14.8% improvement in the call drop rate with fewer calls being dropped overall after the neighbours were added.

One or more software programs that may implement or utilize the various techniques described in the embodiments may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations. The program instructions may be provided on a transitory or a non-transitory medium. Where functionality has been described as being implemented by means of software that functionality could equally be implemented solely in hardware (for example by means of one or more ASICs (application specific integrated circuit)) or indeed by a mix of hardware and software.

Where functional units have been described as circuitry, the circuitry may be general purpose processor circuitry configured by program code to perform specified processing functions. The circuitry may also be configured by modification to the processing hardware.

Configuration of the circuitry to perform a specified function may be entirely in hardware, entirely in software or using a combination of hardware modification and software execution. Program instructions may be used to configure logic gates of general purpose or special-purpose processor circuitry to perform a processing function.

It should be understood that where the functional units described in this specification have been labelled as modules, this is to highlight their implementation independence. Note that a module may be implemented, for example, as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executable program code of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

A module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions. The modules may be implemented at least in part in a cloud computing environment, where processing functions are distributed across different geographical locations.

It should also be noted that whilst the accompanying claims set out particular combinations of features described herein, the scope of the present invention is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features or embodiments herein disclosed irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.

Claims (38)

1. CLAIMS: 1. Apparatus for monitoring a communication network, the apparatus comprising an intelligent network server having processing circuitry configured to: receive network performance indicators from a plurality of network Operational Support Systems, network OSS, the network OSS comprising at least two of a radio OSS, a microwave OSS and a backhaul OSS; identify a performance problem based upon the received network performance indicators; select a performance-enhancement solution to address the identified performance problem, wherein the performance-enhancement solution comprises an adjustment, initiated by the intelligent network server, of at least one network parameter selected from any one of the plurality of network OSS.
2. 2. The apparatus of claim 1, wherein the network performance problem is identified in one of the microwave OSS, the radio OSS and the backhaul OSS and wherein the selected performance-enhancement solution comprises at least one network parameter adjustment in a different one of the microwave OSS, the radio OSS and the backhaul OSS.
3. 3. The apparatus of claim 1, wherein the intelligent network server is configured to determine a category for the identified performance problem into one of a predetermined number of categories.
4. 4. The apparatus of claim 3 comprising a repository of performance-enhancement solutions for storing a plurality of trial solutions depending upon the determined category of performance problem, wherein the intelligent network server is configured to select the performance-enhancement solution from the repository of performance-enhancement solutions.
5. 5. The apparatus of claim 4, wherein the selection of the performance-enhancement solution from the plurality of trial solutions is based upon a ranking for each of the plurality of trial solutions.
6. 6. The apparatus of claim 5, wherein the ranking is updated by the intelligent network server, based upon a self-learning process comprising evaluation of results of implementation of the plurality of trial solutions.
7. 7. The apparatus of any one of the preceding claims, wherein the intelligent network server is configured to save a current state of a set of network parameter values to allow restoration of the parameter set to the current state after implementing the performance-enhancement solution.
8. 8. The apparatus of any one of claims 1 to 7, comprising a responsibility matrix database for storing contact information corresponding to at least one engineer responsible for addressing the detected performance problem.
9. 9. The apparatus of claim 8, wherein the intelligent network server is configured to initiate sending at least one of a telephone call, an SMS message, an email and an instant messaging message to the at least one engineer, specifying a required network maintenance action.
10. 10. The apparatus of any one of the preceding claims, wherein the performance problem corresponds to at least one of a Base Station Controller, a Radio network Controller and a Microwave System Controller.
11. 11. The apparatus of any one of the preceding claims, wherein the performance problem corresponds to deterioration in service quality on one of a radio link, a microwave link, an Internet Protocol link and a fixed line capacity.
12. 12. The apparatus of any one of the preceding claims, wherein network performance parameters received from the radio OSS comprise network performance parameters corresponding to at least two of: a 2G technology, a 3G technology and an LTE 30 technology.
13. 13. The apparatus of any one of the preceding claims, wherein the performance problem corresponds to a dual stack radio link, wherein the dual stack radio link substantially simultaneously uses Asynchronous Transfer Mode, ATM, and Internet Protocol.
14. 14. The apparatus of claim 13, wherein the identified problem relates to deterioration in the Internet Protocol component of the dual stack radio link and wherein the performance enhancement solution comprises converting the dual stack link to an ATM only link.
15. 15. The apparatus of claim 14, wherein the ATM link is converted back to a dual-stack link when the intelligent network server determines that the Internet protocol component of the original dual-stack link has recovered from the deterioration.
16. 16. The apparatus of any one of the preceding claims, wherein the communication network comprises network OSS corresponding to a plurality of different vendors and/or operators.
17. 17. The apparatus of any one of the preceding claims, wherein the intelligent network server is configurable to initiate implementation the performance-enhancing solution and to store a result of the implementation for use in calculation of the ranking of the plurality of trial solutions.
18. 18. A method of monitoring a communication network, comprising the steps of: 20 receiving at an intelligent network server, network performance indicators from a plurality of network Operational Support Systems, network OSS, the network OSS comprising at least two of a radio OSS, a microwave OSS and a backhaul OSS; identifying, using the intelligent network server, a performance problem based upon the received network performance indicators; selecting by the intelligent network server, of a performance-enhancement solution to address the identified performance problem, wherein the performance-enhancement solution comprises an adjustment, initiated by the intelligent network server, of at least one network parameter selected from any one of the plurality of network OSS.
19. 19. The method of claim 18, wherein the network performance problem is identified in one of the microwave OSS, the radio OSS and the backhaul OSS and wherein the selected performance-enhancement solution comprises at least one network parameter adjustment in a different one of the microwave OSS, the radio OSS and the backhaul OSS.
20. 20. The method of claim 18 or claim 19, wherein the intelligent network server is configured to determine a category for the identified performance problem into one of a predetermined number of categories.
21. 21. The method of claim 20, wherein the intelligent network server is configured to select the performance-enhancement solution from a repository of performance-enhancement solutions comprising a plurality of trial solutions depending upon the determined category of performance problem.
22. 22. The method of claim 21, wherein the selection of the performance-enhancement solution from the plurality of trial solutions is based upon a ranking for each of the plurality of trial solutions.
23. 23. The method of claim 22, wherein the ranking is updated by the intelligent network server, based upon a self-learning process comprising evaluation of results of implementation of the plurality of trial solutions.
24. 24. The method of any one of claims 18 to 23, wherein the intelligent network server is configured to save a current state of a set of network parameter values to allow restoration of the parameter set to the current state after implementing the performance-enhancement solution if required.
25. 25. The method of any one of claims 18 to 24, comprising reading from a responsibility matrix database contact information corresponding to at least one engineer responsible for addressing the detected performance problem.
26. 26. The method of claim 25, wherein the intelligent network server is configured to initiate sending at least one of a telephone call, an SMS message, an email and an instant messaging message to the at least one engineer, specifying a required network maintenance action.
27. 27. The method of any one of claims 18 to 26, wherein the performance problem corresponds to at least one of a Base Station Controller, a Radio network Controller and a Microwave System Controller.
28. 28. The method of any one of claims 18 to 27, wherein the performance problem corresponds to deterioration in service quality on one of a radio link, a microwave link, an internet protocol link and a fixed line capacity.
29. 29. The method of any one of claims 18 to 28, wherein the network performance parameters received from the radio OSS comprise network performance parameters corresponding to at least two of: a 2G technology, a 3G technology and an LTE technology.
30. 30. The method of any one of claims 18 to 29, wherein the performance problem corresponds to a dual stack radio link, wherein the dual stack radio link substantially simultaneously uses Asynchronous Transfer Mode, ATM, and Internet Protocol.
31. 31. The method of claim 30, wherein the identified problem relates to a deterioration in the Internet Protocol component of the dual stack radio link and wherein the performance enhancement solution comprises converting the dual stack link to an ATM only link.
32. 32. The method of claim 31, wherein the ATM link is converted back to a dual-stack link when the intelligent network server determines that the Internet protocol component of the original dual-stack link has recovered from the deterioration.
33. 33. The method of any one of claims 18 to 32, wherein the communication network comprises network OSS corresponding to a plurality of different vendors and/or operators.
34. 34. The method of any one of claims 18 to 33, comprising the intelligent network server initiating implementation the performance-enhancing solution and storing a result of the implementation for use in calculation of the ranking of the plurality of trial solutions.
35. 35. A computer program product embodied on a computer-readable medium comprising program instructions configured such that when executed by processing circuitry cause the processing circuitry to implement the method of any one of claims 18 to 34.
36. 36. An apparatus as substantially hereinbefore described with reference to the accompanying drawings.
37. 37. A method as substantially hereinbefore described with reference to the accompanying drawings.
38. 38. A computer program as substantially hereinbefore described with reference to the accompanying drawings.