Field of the invention

The present invention relates to methods of managing a telecommunications network. In particular, the invention relates to managing networks comprising multiple transmission domains.

Background

Network management systems provide network management capabilities to network administrators. However, these systems only manage data relating to one particular transmission domain. For example, Network Management Systems (NMS) is used to manage the 3GPP network and IP Config is used to manage the IP network.

Network Planning Engineers may be required to access different management systems and databases on a daily basis. Therefore, network management activities undertaken by network administrators require expertise in these different systems and time spent maintaining the network using these systems. The daily activities covers performance monitoring, IP design, capacity planning & audit actions in the transmission domain.

Summary

In contrast to existing network management systems, the present invention proposes a network management platform comprising a data processing module, which reads data from different network management systems and saves it in a common database. The proposed system also applies logic and analytics to the data. The data is presented to the user as dashboards that cover different transport networks and provide performance insights.

As described above, Network Planning Engineers using prior art systems may be required to access different management systems and databases on a daily basis (performance monitoring, IP design, capacity planning & audit actions in the transmission domain). This manual operation is inefficient and may consume a lot of time in the daily activities of the engineer. The proposed methods may enable the networks to be managed more efficiently and, in some cases, automatically. Using the proposed methods, one automated platform may be provided that connects automatically to the different systems. In this way, Internet Protocol (IP) network planning activities may be optimized or performed more efficiently, in order to reduce the time required for manual activity by the user.

A method of managing network performance and/or configuration data in a telecommunications network is provided. The method comprises: writing, to a database, network performance and/or configuration data relating to a first transmission domain from a first network management system; writing, to the database, network performance and/or configuration data relating to a second transmission domain from a second network management system; reading, at a data management platform, the network performance and/or configuration data relating to the first transmission domain and the second transmission domain from the database; combining the network performance and/or configuration data relating to the first transmission domain and the second transmission domain to generate aggregated performance and/or configuration data; and sending the aggregated performance and/or configuration data via a user interface.

Advantageously, the proposed method provides a way of applying analytics, correlation, data processing on the E2E collected performance and/or configuration data, in order to manage the transport network more effectively. The proposed method may enable a user of the network management platform to identify potential limitations in the overall system. As a result, the network management platform and proposed methods may improve user experience, even without requiring major network investments.

Transmission domains (also referred to as a “transport domains”) are distinct portions of the telecommunications network. Distinct transmission domains may employ different data transmission methods. For example, a microwave link network may be used to carry cellular telephone calls between cellular networks at different cell sites, a backhaul network may connect a cell site network to a core network, a backbone network may connect multiple geographically distributed networks, which may each be distinct from each other. If geographically distributed networks are in different countries then the characteristics of the networks may be different due to local requirements and restrictions. Each of the networks (or network portions) described above may be referred to as a different transmission domain.

Performance data may also be referred to as “utilisation data” or “traffic data”.

The second transmission domain may be a different transmission domain to the first transmission domain.

The method may further comprise writing, to the database, network performance and/or configuration data relating to one or more further transmission domains from one or more respective network management systems. For example, the method may further comprise: writing, to the database, network performance and/or configuration data relating to a third transmission domain from a third network management system; reading, at the data management platform, the network performance and/or configuration data relating to the third transmission domain from the database; combining the network performance and/or configuration data relating to the first transmission domain, the second transmission domain and the third transmission domain to generate aggregated performance and/or configuration data.

The first transmission domain may be a 3GPP domain (e.g. a cellular mobile telecommunications network).

The second transmission domain may be an internet protocol, IP, domain (e.g. a WAN network).

The proposed methods may be used for aggregating data across different transport domains that would normally be handled by different network management systems (e.g. NMS and IP Config). The different transport domains across which data may be aggregated include:

Different Network Sites

Access Microwave Network

Backhaul Network

Core Packet Network

Single Backbone Network

International Network Different network sites may comprise transmission KPIs end to end (such as Latency, Jitter, Packets drops, and the like).

The method may further comprise: receiving, via the user interface, modified configuration data; and writing the modified configuration data to the database.

The method may further comprise: processing the modified configuration data in the database during an approval cycle; and updating the first network management system and/or the second network management system with the modified configuration data.

By updating the first network management system and/or the second network management system with the modified configuration data, configuration changes may be propagated from the database to the network management systems.

The method may further comprise updating the first network management system and/or the second network management system with the modified configuration data by automatically generating computer-readable instructions that, when executed via a command interface of the first network management system and/or the second network management system causes the first network management system and/or the second network management system to update the network configuration data with the modified configuration data.

There are numerous use cases for applying configuration changes to network systems. In prior art systems, an engineer skilled in many different systems would have to apply configuration changes manually to each system. Using the proposed methods, the command-line instructions to apply configuration updates may be generated automatically. As a result, the time required for a user to manually generate command-line instructions to modify network configurations may be reduced.

Updating the first network management system and/or the second network management system with the modified configuration data may further comprise executing the computer- readable instructions via the command interface of the first network management system and/or the second network management system. The method may further comprise: performing an update cycle comprising the steps of: writing, to the database, updated network performance and/or configuration data relating to the first transmission domain from the first network management system; writing, to the database, updated network performance and/or configuration data relating to the second transmission domain from the second network management system.

In this way, the present invention provides a method in which updated configuration and performance values are written to the database to reflect changes in the telecommunications network. This allows changes (in configuration and/or performance data) to propagate from the first and second network management systems to the data management platform.

The method may further comprising scheduling a plurality of update cycles to occur at regular time intervals (e.g. hourly, daily, weekly, fortnightly, monthly, and the like).

The method may further comprise: receiving, via the user interface, a set of instructions for performing actions via the first network management system and/or the second network management system; and automatically generating computer-readable instructions that, when executed via a command interface of the first network management system and/or the second network management system causes the first network management system and/or the second network management system to perform the actions.

In this way, the proposed methods may generate IP scripts to perform custom actions on network management systems in an efficient manner.

The aggregated performance and/or configuration data may comprise aggregated configuration data. The method may further comprise: performing an audit cycle (an audit of the telecommunications network), wherein the audit cycle comprises the following steps: determining, based on the aggregated configuration data, one or more of the following parameters: quality of service, QOS, parameters, security parameters, and configuration consistency parameters, configuration completeness parameters; and comparing each of the one or more determined parameters to a respective threshold; and generating an audit report based on the result of the comparisons.

The method may further comprise sending the audit report via the user interface or via an electronic messaging service (e.g. email).

The method may further comprise: performing a network performance check cycle, wherein the network performance check cycle comprises the following steps: determining, based on the aggregated performance data, one or more key performance indicators, KPIs, for each of one or more communications links (across all transmissions domains) in the telecommunications network; comparing each of the one or more determined KPIs to a respective threshold and generating a performance report based on the result of the comparisons.

Analysis may be conducted on a link-by-link and/or per-domain basis. KPIs may comprise Maximum throughput , utilization, Latency, lub/S1 Limitation, and the like.

The method may further comprise sending the performance report via the user interface or via an electronic messaging service (e.g. email). The method may further comprise sending a notification via the user interface or via an electronic messaging service (e.g. email) only if one or more of the KPIs are the wrong side of the respective threshold (and not sending an email if all of the KPIs are within acceptable ranges).

The method may further comprise: storing historical network performance data in the database; and determining the one or more thresholds based on the historical network performance data. Where this application refers to “historical” data, “historical” data is defined as any data relating to past network conditions (i.e. anything that happened before the current conditions). For example, the historical data may comprises aggregated data from previous days, KPIs from previous days, and the like. Current data may be stored in anticipation of it becoming “historical” data.

Thresholds may be determined automatically or may be user-defined. The method may further comprise receiving, via the user interface, one or more user-defined thresholds.

The method may further comprise: storing historical network configuration data in the database; and determining the one or more thresholds based on the historical network configuration data.

The configuration data is optional because the network performance is of greatest interest. However, if network configuration settings have been changed and might lead to expected changes in performance then those changes can be taken into account when conducting the review and determining thresholds (and any discrepancies between expected network performance and observed network performance may be noted).

The method may further comprise: storing historical network performance data in the database; and performing an historical performance check cycle, wherein the historical performance check cycle comprises the following steps: determining, based on the historical network performance data, variations in one or more key performance indicators, KPIs, over time for each of one or more communications links (e.g. across all transmissions domains) in the telecommunications network; determining, for each of the one or more determined KPIs, whether the KPI is approaching a respective threshold or is consistently within a predetermined margin of the threshold; and generating an historical performance report based on the result of the comparisons.

In other words, the method may comprise reviewing the data for parameters that are worsening over time and reviewing the data for parameters that are consistently close to the threshold. This may identify problems that would not necessarily raise an alarm but may be significant over the long-term (traffic misrouting or caching nodes inefficacy).

Optionally, the method may also comprise storing historical network configuration data in the database and determining variations in the one or more KPIs may be based on the historical network configuration data, as well as the historical network performance data.

The method may further comprise: storing historical network performance data in the database; and estimating, based on the historical network performance data, future capacity requirements of the telecommunications network.

Optionally, the method may also comprise storing historical network configuration data in the database and estimating future capacity requirements of the telecommunications network may be based on the historical network configuration data, as well as the historical network performance data.

In this way, the aggregated performance and/or configuration data may comprise capacity forecast data.

The method may further comprise sending the estimated future capacity requirements via the user interface or via an electronic messaging service (e.g. email).

The method may further comprise: determining proposed configuration data to meet the estimated future capacity requirements.

The proposed configuration data may be determined automatically.

The proposed configuration data may comprise output requirements (such as new hardware and updated configuration) to cope with demand (e.g. in terms of the new hardware required and new WAN links that need to be established).

The method may further comprise: receiving, via the user interface, proposed capacity data; simulating, based on the proposed capacity data, performance of the telecommunications network; determining, based on the simulation, one or more predicted key performance indicators, KPIs, for the proposed capacity data; generating a simulation report comprising the one or more predicted KPIs.

The method may further comprise: receiving, via the user interface, proposed network configuration data; simulating, based on the proposed network configuration data, performance of the telecommunications network; determining, based on the simulation, one or more predicted key performance indicators, KPIs, for the proposed network configuration data; generating a simulation report comprising the one or more predicted KPIs.

Simulating the performance of the telecommunications network may be further based on historical network data (e.g. network performance data, capacity data and/or network configuration data).

The one or more predicted KPIs may be determined for each of one or more communications links and across all transmissions domains in the telecommunications network.

The method may further comprise simulating performance and providing KPIs for predicted capacity changes.

The method may further comprise sending the simulation report via the user interface or via an electronic messaging service (e.g. email).

The method may further comprise comparing each of the one or more determined KPIs to a respective threshold.

The method may further comprise updating the configuration with the proposed configuration data, if the KPIs are within predetermined ranges (or are above or below the predetermined thresholds). The aggregated performance and/or configuration data may comprise data relating to one or more geographically distributed network elements. The method may further comprise identifying a geographic location of each of the one or more network elements. Sending the aggregated performance and/or configuration data via a user interface may comprise plotting the data relating to the one or more geographically distributed network elements on a map, based on the respective geographic location of each of the one or more network elements.

The map may be useful for the user to design rollout sites and new connection links.

The method may further comprise triggering an alarm if transmission network data parameters exceed (or fall below) threshold values.

The transmission network data parameters may comprise: number of free hardware ports per node, resilience status, traffic peaks, and the like. The thresholds may be set based on operational and/or business needs.

A data management platform for a telecommunications network is also provided. The data management platform is configured to perform any of the methods described above.

Computer software is also provided. The computer software, when executed by a processor, causes the processor to perform any of the methods described above.

Brief description of the drawings

The present invention will now be described with reference to a number of non-limiting specific examples.

Figure 1 illustrates the architecture of a network management platform according to a specific example.

Figure 2 illustrates the IP Scripts Optimization Module of the network management platform.

Figure 3 illustrates the Capacity Planning Module of the network management platform. Figure 4 illustrates the Audit Module of the network management platform.

Figure 5 illustrates the Performance Module of the network management platform.

Figure 6 illustrates the Data Analytics Module of the network management platform.

Figure 7 illustrates the Digital Transport Map Module of the network management platform.

Figures 8A, 8B and 8C illustrate examples of digital transport maps produced by the network management platform.

Detailed description

A network management platform comprises a data processing module. The data processing module reads data from a plurality of network management systems and writes the data to a database. The network management platform also comprise one or more additional modules. Each of the one or more additional modules applies logic and analytics to the data. The network management platform may be configurable with a number of different user accounts (often referred to simply as “a user” or “users”). The data may be presented to the user via one or more dashboards. The dashboards may illustrate different transport networks and geographic locations, for example. The additional modules may determine performance parameters based on the data and the dashboards may provide performance insights to the user, based on the performance parameters.

As described above, prior art systems perform performance monitoring on a per-domain basis. In contrast, the proposed system aggregates data from multiple a plurality of transmission domains. The proposed system also processes the data from the plurality of domains and presents it to the user in a unified interface (“dashboard”).

Using prior art systems a user (such as a network manager or engineer) may need to perform IP design activities by writing hundreds of lines of IP configuration. In contrast, the proposed system allows the network manager to perform similar IP design operations using fewer than 10 inputs.

The proposed system also performs capacity planning and audit operations in a flexible and configurable way. In contrast, prior art systems are not generally customisable and require the network manager to maintain a plurality of separate systems and perform capacity planning and audit operations by visiting those separate systems individually.

Figure 1 illustrates the architecture of the network management platform (also called the “Transport Toolbox”). The network management platform may comprise one or more of the following components:

NMS (TX/Radio)

IP Configuration (Huawei NCE)

Machine to Machine I RPA

Data Processing

Databases/Storage

OpenStreetMap

Local IP Databases IP Templates

Backend (Python)

Flask

Front End (HTML/JS)

A system for gathering data from Network management and IP config Systems is provided. The components from which data are gathered include the following elements illustrated in Figure 1 :

Network Management Systems, NMS (TX/Radio)

IP Configuration (Huawei NCE)

Machine to Machine I RPA

The Data processing module reads data from various management systems and databases (e.g. NMS, IP Configuration, Huawei NCE, and the like). The data collected may include performance data, such as:

Maximum utilization;

Latency;

Packet drops;

Traffic congestion;

Jitter;

Microwave ACM “Adaptive Coding Modulation”

Capacity; and

Data Volume. The data processing module may also collect configuration data, such as:

Node configuration;

QOS;

Security control; and Ports Status.

The data is collected using machine to machine communication between the network management systems and the network management platform. Then the data is processed using control engine (also referred to as the “backend”) and stored in the database.

Data may be collected from the network management systems during a maintenance window (e.g. a regular maintenance interval once per day). The data is processed by the backend. The resolution of collected data may be approximately 15 minutes per sample. The frequency of data collection may be varied based on user requirements, as well as requirements of the network management systems.

Data related to particular network nodes may be stored together. Nodes related to a certain network section may be stored together. The user may have the possibility to filter the data per node or per network section.

The data may be processed after collection from different management systems to prepare the data for use for any other application (e.g. sites IPs, routers loopback, and the like).

The control engine

The backend may interface with the processed data from the database. The database may be populated using a data processing module that reads data directly from the network management systems (such as NMS and/or IP configuration).

If a user changes a setting or value in the front end of the network management platform, this change may not reflect directly on the backend/frontend of the relevant network management system but will reflect on the database. A change management approval cycle may be undertaken to execute the change actions on the network management systems. If configuration changes are needed, the user may specify the required changes with a small number of inputs. The backend may create the needed command lines, without applying the changes on the network management system. A change management approval cycle may be performed, to confirm that it is acceptable to proceed with the changes. Then, the changes may be implemented through execution of the command lines on the relevant network management system.

For example, in case of IP configuration needed, the backend may create the needed command lines with minimum number of inputs, without applying it to node. The implementation is done through the normal execution process after taking change management approval to proceed with the action.

For the performance module or the digital capacity map module, any filtration may be reflected automatically on front end from the data stored in database.

When the user changes a setting in the front end, this is passed through to the backend, which updates the database. A separate automation loop operates to store the data daily from the network management systems after processing.

IP Scripts Optimization Module

Figure 2 illustrates the IP Scripts Optimization Module, which comprises the following components:

Template Selection

Manual Inputs

Optimization Stage

Control Engine

IP Databases

Current Network Configuration

Optimized IP Script

The time required to create IP Scripts may be reduced through introducing the control engine, to get the existing nodes configuration and access the different transmission databases. Creating IP Scripts may be a daily task for the user. The rise in data throughput over time due in part to new technologies (such as 5G) reflect a significant increase in the number & complexity of IP Scripts needed by the user. The IP Scripts module in a specific example provides group of standard IP templates (27 templates) with very few inputs (Less than 10). Using the IP scripts module, a user can create a new template based on the use case. The main optimization is achieved through having access to the router IP configuration data & different local databases and using them in creating the new IP script. This module reflects a significant improvement in the accuracy and also decreases the requirement for the user to manually create scripts (and so may reduce the workload of the engineer by streamlining the process and improving efficiency). If required, the new IP scripts will be applied on the system after obtaining approval from operation and change management teams.

IP Scripts provides an automated tool that uses a programming & GUI interface to create IP configuration designs, instead of manual methods in creating IP scripts. The new tool is connected with different databases and systems. The tool optimizes the required inputs, saves time and enhances accuracy for any new IP scripts. Automation of IP designs results in significant improvements in accuracy and makes the process more efficient (and so decreases the workload of the engineer).

In the IP scripts optimization module, the inputs received at the front end from a user are provided by a combination of template selection and manual inputs. The optimization stage comprises the control engine, which operates on the IP databases and the current network configuration. Finally, the output is the optimized IP script.

In some examples, the scripts are not sent automatically to IP Configuration to be applied. Instead, the optimized scripts may go through an approval process first (so there is no direct physical effect on the system, without approval).

Capacity Planning Module

Figure 3 illustrates the Capacity Planning Module, which comprises the following components:

Control Engine

Current Network WAN Utilization

Current Network Hardware Utilization

Verification Stage No: Automated Expansion Mail Yes: No Action

Verification Stage: Verify Links and H/W Utilization Versus Expansion Threshold

Capacity planning is one of the major activities in a transmission network, especially if the operator is leasing links from another service provider. Proper design for the capacity in the LAN and WAN domains will avoid wasting CAPEX & OPEX in unused links or hardware. Also, the delay in the expansion will reflect in traffic throttling and losing customer experience. The capacity planning module is a new module that provides a simple and fast way to provide the needed links and hardware expansion based on the current network utilization, the expected traffic increase and the design threshold. The capacity planning module introduces automation in the capacity planning process to optimize the expansion cost through ordering the expansion automatically and determining the actual directions and hardware that need expansion.

The Capacity Planning Module provides a capacity forecast, which automates a detailed transmission forecast with cancellation plan. The Capacity Planning Module also reports on ports utilization, and can automate hardware ports utilization reports. The Capacity Planning Module enables automatic planning for needed LAN and WAN links expansions, based on network status. As a result of the functionality provided by the Capacity Planning Module, it may be possible to reduce the time spent during capacity planning time from hours to minutes.

The Capacity planning module is represented at the front end in two front end interfaces, one for H/W Planning and the other for WAN links planning:

H/W Planning front end includes the list of nodes that are highly utilized and need urgent H/W expansion. User can filter any node and check the number of used and free ports for each type of ports. An automatic mail may be sent to the concerned teams if the nodes reaches to a certain used ports utilization value.

WAN Links Planning front end permits the user to enter two values: the required design threshold and expected traffic increase. The backend will check the current links utilization and will provide list with all needed WAN expansion per aggregation point and per type (1G/10G,...).

The expansion threshold may be configurable. An user can define the expansion threshold based on the need and speed of expansion. The Automated Expansion mail is an automated message, which may be sent to the concerned teams if the node reaches a certain ports utilization percentage to proceed with expansion.

Audit Module

Figure 4 illustrates the Audit Module, which comprises the following components:

Control Engine

Current Network Configuration

Standard Network Configuration

Verification Stage

No: Automated Fixing mail

Yes: No Action

* Verification Stage : Verify current configuration against Standard Network Configuration

The Audit Module provides a regular health check for transmission network configuration

The Audit Module provides an automated health check for the current nodes configuration vs the standard design and identifies and discrepancies and how to fix them.

The Audit Module may review a range of configuration values, which may include:

• Security o Review security controls

• QOS o Review QOS over network sections

• Missing Configuration o Review configuration and fix missing ones

Auditing the current network configuration against the golden design may be a regular task for the user (e.g. an IP network engineer). The Audit module provides an automated daily report for some of important network configuration like QOS or security control. Introducing automation in this important task may save a lot of time and effort compared to checking node by node configuration manually. Moreover, the Audit Module may speed up the process of fixing problems by taking action against risks like traffic congestion or network attacks. This may improve the efficiency and security of the network.

At the front end, the Audit planning module is presented as results based on the configuration status (e.g. of the previous day).

A function of the automated fixing mail is to flag inconsistencies between the golden design and the current network configuration. Issues may be automatically diagnosed and suggestions for resolving the issues may be provided.

The fixing mail highlights the discrepancies between a current configuration and golden design parameters. It is sent to one or more users to review and take the required approval to proceed with fix action.

Performance module

Figure 5 illustrates the Performance Module, which comprises the following components: Control Engine

Transport Network Management Systems

Transport KPIs Database

Automated Dashboard

‘Transport Network Management Systems: Include (Sites Probes, Microwave, Backhaul and Core Routers, International links, and the like)

The Performance Module may include a dashboard, illustrating historical network performance data (e.g. 14 days of history). The dashboard may further illustrate utilization, capacity violations, and the like. The Performance Module may send regular (e.g. daily) messages comprising updates to one or more users. The detailed daily report may provide a summary of network performance on a per-domain basis. The Performance Module may store historical data for all domains.

The Performance Module may provide an automated performance report for the transmission network. The Performance Module may organized data for the whole transmission network in one database. The Performance Module may provide an automated dashboard for the transport network sections, including the historical performance for each link. This aggregation of data may enable holistic insights to be drawn from performance across transport domains of the network (paving the way for “big data” applications).

The Performance Module covers the major performance KPIs in all transport domains, such as maximum throughput, utilization, latency, lub/S1 limitation, and the like. This module provides an end to end view for the performance of all transport domains from access to international area in one system, instead of using different systems.

Data analytics module

Figure 6 illustrates the Data Analytics Module, which comprises the following components: Control Engine Current Network KPIs Verification Stage

No: Automated Notification Mail

Yes: No Action

Verification Stage: Verify Against (Network Peaks, Abrupt Traffic Changes, Resilience Threshold & Network Section Correlation Threshold)

The Data Analytics Module provides an automated dashboard for the network statistics, abrupt traffic change, network resilience status, and the like.

The Data Analytics Module may compare statistics to threshold values. Verification may be performed for each of the thresholds.

There are two types of threshold values:

1 . Adjustable threshold values, which are based on user requirements such as in the following sub modules: Abrupt Throughput increase, Resilience Status, Network Sections Correlations. For example, if there is change of 30% or more in throughput direction, a notification mail may be sent to one or more users to investigate the reasons.

2. Learned threshold values based on historical data in the database like in the following sub modules: Network Peak Statistics. For example, compare the international links aggregated throughput versus the last peak achieved in the network and, if it is exceeded, a notification mail may be sent to one or more users to inform them.

An automated notification mail may be sent to one or more users (e.g. a network engineer or management) to be aware with the new change that happened in the network profile, which may lead action being taken.

Digital Transport Map Module

Figure 7 illustrates the Digital Transport Map Module (also referred to as the “Digital capacity map” module), which comprises the following components:

Control Engine

Transport Network KPIs

Digital Tiles

Map Database

Automated Digital Transport Map

The Digital Transport Map Module provides an automated digital transport map for the whole transport domains and vendors including different transmission KPIs. As a result, the Digital Transport Map Module may provide new insights on the whole transmission network. The Digital Transport Map Module may also perform fast root cause analysis for transmission performance issues.

For each digital tile or node on the digital transport map a user can apply filtering from the map to select the transmission domain links and can also filter the highly utilized transmission links on a per-domain basis.

Additional information may be provided alongside the map. As illustrated in Figure 8A, each node/tile may have a corresponding icon, illustrates as an “i” in Figure 8A. In all transmission domains, a user can get the maximum utilization per link. A colour of the link or node may indicate a congestion of the link or node. For example, red being highly congested, orange being moderate and green being clear.

In International domain, a user can get the maximum latency on the link beside the maximum utilization. In microwave domain, user can get adaptive modulation problems beside the maximum utilization. In end to end lub/S 1 domain, a user can get best efforts delay, signalling delay, frame loss on the uplink and downlink per site, and the like.

Figures 8A, 8B and 8C illustrate examples of the digital transport map.

The network management platform may comprise a local server, enabling the Digital Transport Map Module to provide multi-layered data displayed over a local map. The Digital Transport Map Module may provide a regular (e.g. daily) high level view for mobile transport network performance. The Digital Transport Map Module may perform fast correlation for transmission performance issues.

IP Design Module

The IP design module comprises a low-level IP design component, which can help to identify new rollout sites and new links connections. The IP design module further comprises IP scripts, which may assist with network management activities such as load balancing, cutover offload, and the like. The IP design module further comprises a nodes integration feature, which can help to identify New Nodes TX integrations (SGW,RNC,BSC, IP Routers).

Using the IP design module, network management activities may be achieved using fewer than 10 inputs, instead of tens or hundreds of configuration lines (as required in the prior art). As a result, the IP design module may provide a 30% time saving in IP Designs issuance and may reduce human errors in IP Design.

The various modules of the network management platform are able to communicate with a range of different network management systems, including:

NCE (Huawei)

UPM (Nokia)

SolarWinds

SOEM (Ericsson)

NMS (SIAE)

OSS (Ericsson)

PRS (Huawei)

Probes (VIAVI)

Open Street Map (Local) Databases (Local)

IP Templates (Local)

Some modules may be configured to communicate with a subset of the available systems. For example: the performance module may be configured to communicate with NCE, UPM, SolarWinds, SOME, NMS, OSS, PRS, Probes and Databases; the digital capacity map module may be configured to communicate with NCE, UPM, SolarWinds, SOME, NMS, OSS, PRS, Probes, Open Street Map and Databases; the IP design module may be configured to communicate with NCE, Databases and IP Templates; the capacity planning module may be configured to communicate with NCE, UPM and Databases; and the audit module may be configured to communicate with NCE and Databases.

Unlike other Network Management Systems, which are designed as an operation platform, the proposed network management platform also provides a planning platform. The network management platform supports many of the same features as the network management systems, including

Downward Interface

Upward Interface

System Management

Resource Management.

The network management platform may further provide a Configuration Module, Topology Module and Performance Module. The network management platform further provides a number of modules that are not supported by other Network Management Systems, including: Optimized IP Scripts Module, Capacity Planning Module, Audit Module, Data Analytics Module, Digital Transport Map Module.

If the network management platform is only a planning platform, and is not required to perform as an operation platform for realtime network management, there may be no need for the network management platform to support a Circuit Scheduling Module or an Alarm Module.

Some example network management platform use cases are provided below:

The digital transport map is used by the management team to check on the overall performance of transmission network, and to monitor the progress in different transmission domains. The transport dashboard is sent daily to all transmission team members including the management team through e-mail to give them a top-level view on the status of all ongoing streams. The e-mail provides links to the different network management platform modules for further information.

The IP design script reduced the IP design process duration from several hours to a couple of minutes. This helped us save resources across the 4 years since its deployment.

The Data Analytics module is used to check the unusual behaviours that impact the transport network and don’t reflect in alarms like traffic misrouting or caching nodes inefficacy, and also it provides fast root cause analysis for sites transmission problems.

As used herein, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" means "one or more”. Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including but not limited to", and are not intended to (and do not) exclude other components.

Although embodiments according to the disclosure have been described with reference to particular types of devices and applications (particularly a network management platform managing data from network management systems, including NMS and IP Config) and the embodiments have particular advantages in such case, as discussed herein, approaches according to the disclosure may be applied to other types of networks. The specific structural details of the platform and servers, whilst potentially advantageous (especially in view of known 3GPP and IP constraints and capabilities), may be varied significantly to arrive at devices and methods with similar or identical operation. Each feature disclosed in this specification, unless stated otherwise, may be replaced by alternative features serving the same, equivalent or similar purpose. Thus, unless stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the invention and does not indicate a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any nonclaimed element as essential to the practice of the invention. Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. All of the aspects and/or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. As described herein, there may be particular combinations of aspects that are of further benefit, such the aspects of determining a set of compensation parameters and applying a set of compensation parameters to measurements. In particular, the preferred features of the invention are applicable to all aspects of the invention and may be used in any combination. Likewise, features described in non- essential combinations may be used separately (not in combination).