WO2024250199A1

WO2024250199A1 - Device and method for network performance analysis

Info

Publication number: WO2024250199A1
Application number: PCT/CN2023/098935
Authority: WO
Inventors: Shaked LEIBZIRER; Felix GOLDBERG; Leon Bruckman; Ilan Bar; Jiading RAO; Pavel Kisilev
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-06-07
Filing date: 2023-06-07
Publication date: 2024-12-12
Anticipated expiration: 2025-12-07
Also published as: CN121264012A

Abstract

A device and method for network performance analysis are provided. The device is configured to receive network data. Then, the device parses the received network data into a data set, where the data set comprises a topology of the network. The device is further configured to determine one or more performance metrics of the network based on the data set, based on a mean time between failures (MTBF) and based on a time needed to repair faults in the network. Further, the device is configured to determine a performance of the network based on the one or more performance metrics.

Description

DEVICE AND METHOD FOR NETWORK PERFORMANCE ANALYSIS

TECHNICAL FIELD

The present disclosure relates to a device for network performance analysis. The disclosure further provides a corresponding method for network performance analysis and a computer program product to perform the method.

BACKGROUND

When building a new network or when planning new service types and network upgrades, operators face several challenges related to network reliability. Operators wish to provide a sizable competitive advantage to their products by allowing an in-depth analysis and understanding of the network performance evolvement in order to extend their business portfolio.

Conventional solutions are based on reliability block diagrams (RBDs) , Markov processes and survival signatures. However, they do not take into consideration crucial factors of real-life telecom networks since, e.g., the network is modelled as a single unit or considers only link failures while excluding node failures. Further, the conventional solutions require hours-long running time of traditional tools.

Moreover, currently there is no consensus on accepted network performance metrics. Most academic and commercial tools currently handle reliability of network systems by addressing mainly connectivity-based metrics. Further, conventional deployed networks have high redundancy and, thus, the commonly used reliability metrics do not provide a meaningful comparison basis.

SUMMARY

In view of the above, this disclosure has the objectives to improve conventional solutions for network performance analysis, to achieve real time assessment of the network performance, to support large-scale networks, and to allow performing an analysis comparison of different network topologies.

These and other objectives are achieved by the solutions of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

According to a first aspect, a device for network performance analysis is provided. The device is configured to: receive network data, parse the received network data into a data set, where the data set comprises a topology of the network; determine one or more performance metrics of the network based on the data set, based on a mean time between failures (MTBF) and based on a time needed to repair faults in the network; and determine a performance of the network based on the one or more performance metrics.

This provides the advantage of providing a real time evaluation of the performance of the network.

Further, the calculation the one or more performance metrics based on the MTBF and the time needed to repair faults of all the network’s hardware provides the advantage of supporting a comprehensive reliability-driven analysis of the network based on its hardware statistics, and provide accurate and realistic results.

Further, the determined performance of the network may take into consideration failures of both links and nodes of the network, which can be effectively used in the network design stage in order to recommend or illustrate a preferable architecture.

In an implementation form of the first aspect, the network data includes a schematic description of the network or a parametric description of the network.

In an implementation form of the first aspect, the device is further configured to generate the data set based on the received network data when parsing the network data into the data set, and generate a routing scheme through the network based on the received network data. The routing scheme includes an expected load-balancing of the network when a failure occurs.

In an implementation form of the first aspect, the time needed to repair faults in the network includes a mean time to repair (MTTR) .

In an implementation form of the first aspect, determining the one or more performance metrics of the network based on the data set, based on the MTBF, and based on the time needed to repair faults in the network includes: performing a numerical simulation over a predefined time of operation of the network using the data set, the MTBF and the MTTR; and determining the one or more performance metrics of the network based on one or more results of the numerical simulation and based on the generated routing scheme.

In an implementation form of the first aspect, the numerical simulation includes sampling one or more failure occurrences in the network based on the MTBF, additionally or alternatively sampling one or more times to repair faults based on the MTTR.

The numerical simulation may decouple a sampling procedure and an evaluation procedure of the performance metrics, thus allowing a flexible assessment of different network topologies, different scenarios and business objectives.

The numerical simulation may comprise a discrete event Monte-Carlo simulation.

In an implementation form of the first aspect, the one or more results of the numerical simulation include at least one of: a list of congestion events of the network, a size of the network, and a duration of the congestion events.

In an implementation form of the first aspect, the one or more performance metrics include at least one of: a connectivity metric, a total number of failed links and nodes of the network during a simulation period time, a low congestion metric, a maximum congestion level occurrence of a link during the simulation period time, an average congestion area during the simulation period time, a complementary cumulative distribution Function (CCDF) with a congestion duration, and a network expected convergence time.

Notably, the one or more performance metrics may incorporate an aging factor of the network and may integrate essential aspects of the network, wherein the essential aspects of the network may comprise both physical (i.e., connectivity) and logical (i.e., congestion level) aspects.

In an implementation form of the first aspect, determining the performance of the network based on determined one or more performance metrics includes performing an analysis of the determined one or more performance metrics.

In an implementation form of the first aspect, determining the performance of the network based on determined one or more performance metrics further includes performing a comparison of two or more network architectures based on the determined one or more performance metrics.

This provides the advantage of enabling the comparison among different configurable large network architectures, taking into consideration multi-objectives performance aspects.

In an implementation form of the first aspect, the device further comprises a display device configured to display the determined performance of the network, additionally or alternatively to display the comparison of the two or more network architectures.

According to a second aspect, a method for network performance analysis is provided. The method includes: receiving network data; parsing the received network data into a data set, where the data set comprises a topology of the network; determining one or more performance metrics of the network based on the data set, based on a MTBF and based on a time needed to repair faults in the network; and determining a performance of the network based on the one or more performance metrics.

In an implementation form of the second aspect, the network data includes a schematic description of the network or a parametric description of the network.

In an implementation form of the second aspect, the method further comprises generating the data set based on the received network data when parsing the network data into the data set, and generating a routing scheme through the network based on the received network data. The routing scheme includes an expected load-balancing of the network when a failure occurs.

In an implementation form of the second aspect, the time needed to repair faults in the network includes a MTTR.

In an implementation form of the second aspect, determining the one or more performance metrics of the network based on the data set, based on the MTBF, and based on the time needed to repair faults in the network includes: performing a numerical simulation over a predefined time of operation of the network using the data set, the MTBF and the MTTR; and determining the one or more performance metrics of the network based on one or more results of the numerical simulation and based on the generated routing scheme.

In an implementation form of the second aspect, the numerical simulation includes sampling one or more failure occurrences in the network based on the MTBF, additionally or alternatively sampling one or more times to repair faults based on the MTTR.

The numerical simulation may comprise a discrete event Monte-Carlo simulation.

In an implementation form of the second aspect, the one or more results of the numerical simulation include at least one of: a list of congestion events of the network, a size of the network, and a duration of the congestion events.

In an implementation form of the second aspect, the one or more performance metrics include at least one of: a connectivity metric, a total number of failed links and nodes of the network during a simulation period time, a low congestion metric, a maximum congestion level occurrence of a link during the simulation period time, an average congestion area during the simulation period time, a CCDF with a congestion duration, and a network expected convergence time.

In an implementation form of the second aspect, determining the performance of the network based on determined one or more performance metrics includes performing an analysis of the determined one or more performance metrics.

In an implementation form of the second aspect, determining the performance of the network based on determined one or more performance metrics further includes performing a comparison of two or more network architectures based on the determined one or more performance metrics.

In an implementation form of the second aspect, the method further comprises displaying, by a display device, the determined performance of the network. Additionally or alternatively, displaying, by the display device, the comparison of the two or more network architectures.

The method according to the second aspect comprises the features of the corresponding implementation forms of the device of the first aspect.

According to a third aspect, a computer program product is provided, including a program code for carrying out, when implemented on a processor, the method according to the second aspect and its implementation forms.

The computer program product according to the third aspect comprises the features of the corresponding implementation forms of the method of the second aspect.

The method according to the second aspect and the computer program product according to the third aspect and their implementation forms provide the same advantages and effects as described above for the device of the first aspect and its respective implementation forms.

The solutions according to present disclosure may provide the following advantages:

● Enabling real time performance evaluation and reliability-driven comparison of different network implementations.

● Supporting comprehensive reliability-driven analysis for large-scale networks based on its hardware statistics.

● Incorporating essential aspects of the network (both logical and physical) within the performance metrics.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

FIG. 1 schematically depicts a device for network performance analysis according to this disclosure;

FIGS. 2A-2B schematically depict an exemplary implementation of the device for network performance analysis according to this disclosure;

FIG. 3 schematically depicts a device for network performance analysis according to this disclosure;

FIG. 4 shows an example of a comparison of a performance metric for two different network architectures;

FIG. 5 shows an example of a comparison of another performance metric for two different network architectures;

FIG. 6 shows an example of a comparison of a further performance metric for two different network architectures;

FIG. 7 shows an example of a comparison of a further performance metric for two different network architectures;

FIG. 8 shows a method for network performance analysis according to this disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows an exemplary embodiment of a device 100 for network performance analysis according to this disclosure.

The device 100 according to this disclosure may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the device 100 described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors. The device 100 may further comprise memory circuitry, which stores one or more instruction (s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the device 100 to be performed. The processing circuitry may comprise one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device 100 to perform, conduct or initiate the operations or methods described herein.

The device 100 may be implemented in, or may be part of, an orchestrator of a network.

The device 100 is configured to receive (or obtain) network data 101. The network data 101 may comprise a schematic description of the network or a parametric description of the network. For example, the schematic description of the network may comprise one or more JSON files.

Then, the device is configured to parse the received network data 101 into a data set 102, the data set 102 comprising a topology of the network.

In this disclosure, the terms architecture and topology may be used interchangeably.

While parsing the network data 101 into the data set 102, the device 100 is configured to generate the data set 102 based on the received network data 101, and to generate a routing scheme through the network based on the received network data 101. The routing scheme comprises an expected load-balancing of the network when a failure occurs.

The generation of the data set 102 may comprise generating a configurable graph. The configurable graph may comprise a graph data structure, the graph data structure comprising physical information of a graph that represses the received data 101, and therefore comprising physical information of the received data 101, in such a way that one or more different parameters of one or more components of the network may be configurable (not hard coded) .

The generated routing scheme may be related to a location-based clustering of one or more components of the network for which a set of routes can be generated. The set of routes can be derived from an equal-cost multi-path routing (ECMP) strategy. The routing scheme, hence, may illustrate the expected network load-balancing upon a failure in a correspondent element of the network.

That is, the routing scheme may exploit a hierarchical structure of common telecommunication networks to cluster the network components based on their location. The routing scheme may comprise one or more of the following features:

● A type of hardware that may lead to a failure in the observed component (e.g., a link can fail due to the failure in the fiber itself or in the edges ports) .

● For each aforementioned type, a set of links that illustrates the expected network load-balancing upon a failure in the observed element, as derived from the ECMP strategy.

Further, the device 100 is configured to determine one or more performance metrics 105 of the network based on the data set 102, based on a MTBF 103 and based on a time needed to repair faults in the network 104.

The time needed to repair faults in the network 104 comprises a MTTR.

Further, the device 100 may run a Discrete Event Simulator (DES) for one or more failure or repair events in one or more links or nodes of the network that occur over a specified period (nominally 20 years) of operation.

That is, the device 100 is further configured to determine the one or more performance metrics 105 of the network based on the data set 102, based on the MTBF 103 and based on the time needed to repair faults in the network 104 by performing a numerical simulation over a predefined time of operation of the network using the data set 102, the MTBF 103 and the MTTR. Further, the device is configured to determine the one or more performance metrics 105 of the network based on one or more results of the numerical simulation and based on the generated routing scheme.

The numerical simulation comprises sampling one or more failure occurrences in the network based on the MTBF 103. Additionally or alternatively, the numerical simulation comprises sampling one or more repair faults based on the MTTR.

The term sampling may refer to a time series generated from a distribution function that depends on one or more input features of the network. The distribution function may comprise, for example, a Weibull distribution given bywith β=1 and θ = MTBF or MTTR. Each element in the time series may represent an event that is either a failure or a repair of a component of the network.

A failure probability for each element (link and/or node) of the network is defined as where t is a time from the last repair event or from the beginning of the simulation. For each failure event there is a matching repair event, occurring at a MTTR period after the failure event.

Each sampling represents a failure or a repair event that changes the network physical topology and its load distribution. For each event, the numerical simulation may assess a new state of the network in terms of the one or more performance metrics 105, e.g., whether the network remains connected, what are the current links bandwidth utilization levels, and the like. In other words, the samplings are used to emulate the physical changes occurring in the network hardware over time, and the simulation evaluates the mentioned metrics for a resultant sub-network. The final results are one or more cumulative measurements derived from each event.

The numerical simulation, thus, may enable to decouple the sampling and the evaluation (determination) of the one or more performance metrics 105. That is, the device 100 may allow to separate the mathematical modelling and the determination procedure, thus allowing a flexible assessment of different network scenarios (or architectures) and business objectives.

For example and not as a limitation, the numerical simulation may be a discrete event Monte-Carlo simulation.

The one or more results or output of the numerical simulation comprise at least one of a list of congestion events of the network, a size of the network, and a duration of the congestion events.

Additionally or alternatively, the one or more results of the numerical simulation may comprise a list of congestion events together with a size (number of links) , duration, and associated convergence time (if applicable) of the network.

The one or more performance metrics 105 comprise at least one of: a connectivity metric, a total number of failed links and nodes of the network during a simulation period time, a low congestion metric, a maximum congestion level occurrence of a link during the simulation period time, an average congestion area during the simulation period time, a CCDF with a congestion duration, and a network expected convergence time.

In other words, the device 100 may calculate two sets of metrics for any network topology, wherein the two sets of metrics may comprise physical network (protocol excluded) metrics and logical network (protocol included) metrics.

The physical network metrics may comprise, for example and not as a limitation, one or more of:

a) Connectivity metric -percentage of time during which X %among end-users were reachable, with 0 ＜ X ≤ 100.

b) Total number of failed links and nodes during the simulation period time.

The logical network metrics may comprise, for example and not as a limitation, one or more of:

a) Low congestion metric –Percentage of time during which the network did not suffer from congestion (which may occur due to failures that lead to over load in the protecting links) .

b) For each bandwidth utilization case (e.g., 37%) , the maximum congestion level (in percentage) occurrence for one or more links during the simulation period time may be determined.

c) For each bandwidth utilization case (e.g., 37%) , a maximum congestion extent (number of simultaneously congested links) during the simulation period time may be determined.

d) For each bandwidth utilization case (e.g., 37%) , an average congestion extent (number of simultaneously congested links) during the simulation period time may be determined.

e) For each bandwidth utilization case (e.g., 37%) , the CCDF with congestion duration of the topology suffering from a congestion area (congestion link number) greater than a stated congestion area may be determined.

It is to be mentioned that the routing scheme may be used during the determination of the low congestion metric 105 and the network expected convergence time over the course of the simulation period time metric 105.

Further, the device 100 of FIG. 1 is configured to determine a performance of the network 106 based on the one or more performance metrics 105.

The determination of the performance of the network 106 based on the one or more performance metrics 105 comprises performing, by the device 100, an analysis of the determined one or more performance metrics 105. The analysis may be, for example, a statistical analysis of the one or more performance metrics 105.

Then, the device 100 may be further configured to generate one or more appropriate graphs, each graph illustrating the determined one or more performance metrics 105. Additionally or alternatively, the device 100 may be further configured to generate one or more appropriate graphs, each graph illustrating the determined performance of the network 106.

That is, the device 100 according to this exemplary embodiment, thus, may calculate specific reliability-oriented performance metrics 105 for a certain network topology.

The determination of the performance of the network 106 based on the one or more performance metrics 105 further comprises performing a comparison of two or more network architectures based on the determined one or more performance metrics 105.

That is, for each network topology, the device 100 may determine a respective set of performance metrics, each set comprising the one or more performance metrics 105. The device 100 may then compare the determined two or more sets of performance metrics, thereby comparing the performance of the respective two or more network architectures.

Based on the above disclosure, it is to be understood that the device 100 may use a four-stage mechanism to provide a comprehensive statistical analysis of the performance of the network. An exemplary implementation of the above-disclosed four stages of the device 100 is depicted in FIGS. 2A and 2B. In the figures, same elements are labelled with the same reference signs.

The left side of FIG. 2A depicts an example of the network data 101 received by the device 100. Next, the device 100 may generate the data set 102 by, for example and not as a limitation, converting the network topology into a directed multi-graph, as shown in the right part of FIG. 2A.

Next, the left part of FIG. 2B depicts an exemplary numerical simulation 208 performed by the device 100, for example the discrete event Monte-Carlo simulation, which integrates the real specifications of the components of the network, the time to repair faults, i.e., the MTBF 103, and the MTTR 207. Further, the numerical simulation 208 takes into account the aging of the network.

Further, the right part of FIG. 2B depicts the determined performance of the network 106, by showing two exemplary comparisons 209-1, 209-2 of two network architectures, each comparison 209-1, 209-2 being based on a different performance metric 105.

FIG. 3 shows an exemplary embodiment of the device 100 for network performance analysis according to this disclosure, which builds on the device 100 of FIG. 1. Same elements are labelled with the same reference signs.

In this exemplary embodiment, the device 100 further comprises a display device 310 configured to display the determined performance of the network 106, additionally or alternatively the comparison 209 of the two or more network architectures.

The device 100 of FIG. 1 and FIG. 3 according to this disclosure can be used to compare, for example and not as a limitation, two backbone network configurations (or network architectures) . By way of example and not as a limitation, a first backbone configuration may comprise a large centralized switch, referred to as "Big-boxes" configuration, and a second backbone configuration may comprise of a set of small switch boxes, referred to as "Spine-Leaf" configuration. The analysis of the network performance for each network configuration determined by the device 100 proves and showcases an advantage of the Big-Box configuration in contrast with the Spine-Leaf configuration regarding reliability.

FIG. 4 shows an exemplary comparison 209 of a performance metric 105 determined by the device 100 for the Big-Box architecture and for the Spine-Leaf architecture. From FIG. 4, it can be concluded that for every case of bandwidth utilization, the maximum number of affected links upon a congestion occurrence in the Big–Box configuration is almost negligible while in the Spin-Leaf configuration there are events in which hundreds of links are impaired. These results may be crucial for the network, since a higher number of congested links can be related to a higher number of impaired services.

FIG. 5 shows an exemplary comparison 209 of the above-disclosed logical performance metric b) as determined by the device 100 for the Big-Box architecture and for the Spine-Leaf architecture. The exemplary comparison 209 of FIG. 5 reveals that for every case of bandwidth utilization, the maximum congestion of a link is significantly smaller in the Big–Box configuration than in the Spine-Leaf configuration.

Further examples of comparisons 209 are shown in FIGs. 6 and 7. In FIG. 6 an exemplary comparison 209 of the above-disclosed logical performance metric d) determined by the device 100 for the Big-Box architecture and for the Spine-Leaf architecture is depicted.

FIG. 7 shows an exemplary comparison 209 of the above-disclosed logical performance metric e) determined by the device 100 for both the Big-Box architecture and the Spine-Leaf architecture.

The device 100 of the embodiments of FIG. 1 and FIG. 3 according to this disclosure, hence, may allow a real time (of the order of seconds to a few minutes) and an effective assessment of load-driven network performance metrics, including the convergence time. This further may provide with location-awareness routing scheme generation. Further, the device 100 may support the performance analysis of very large networks (for example but not restricted to networks comprising up to 500,000 links and 20,000 nodes) .

Further, the device 100 according to this disclosure may be applied to any type of telecommunication network (wired, wireless) . Moreover, the device 100 can be adapted to compute and compare reliability of different industrial production lines that are based on MTBF and MTTR.

FIG. 8 shows an exemplary embodiment of a method 800 for network performance analysis. The method 800 may be performed by the exemplary embodiments of the device 100 of FIG. 1 and FIG. 3 as disclosed above.

The method 800 comprises a step 801 of receiving network data 101.

Then, the method 800 comprises a step 802 of parsing the received network data 101 into a data set 102. The data set 102 comprises a topology of the network.

Further, in step 803, the method 800 comprises determining one or more performance metrics 105 of the network based on the data set 102, based on a mean time between failures, MTBF 103, and based on a time needed to repair faults in the network 104.

The method 800 further comprises a step 804 of determining a performance of the network 106 based on the one or more performance metrics 105.

The method 800 may further comprise actions according to the exemplary embodiments of the device 100 of FIG. 1 and FIG. 3. Hence, the method 800 achieves the same advantages as the device 100 disclosed above.

This disclosure further provides a computer program product comprising a program code for carrying out, when implemented on a processor, the method 800. The computer program may be included in a computer readable medium of the computer program product. The computer readable medium may comprise essentially any memory, such as a ROM (Read-Only Memory) , a PROM (Programmable Read-Only Memory) , a 15 EPROM (Erasable PROM) , a Flash memory, an EEPROM (Electrically Erasable PROM) , or a hard disk drive.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and

effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word "comprising" does not exclude other elements or steps and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

A device (100) for network performance analysis, configured to:

receive network data (101) ;

parse the received network data (101) into a data set (102) , wherein the data set (102) comprises a topology of the network;

determine one or more performance metrics (105) of the network based on the data set (102) , based on a mean time between failures (103) , MTBF, and based on a time needed to repair faults in the network (104) ; and

determine a performance of the network (106) based on the one or more performance metrics (105) .
The device (100) according to claim 1, wherein the network data (101) comprises a schematic description of the network or a parametric description of the network.
The device (100) according to claims 1 or 2, wherein the device (100) is configured to:

generate the data set (102) based on the received network data (101) when parsing the network data (101) into the data set (102) ; and

generate a routing scheme through the network based on the received network data (101) , the routing scheme comprising an expected load-balancing of the network when a failure occurs.
The device (100) according to one of the preceding claims, wherein the time needed to repair faults in the network (104) comprises a mean time to repair, MTTR, (207) .
The device (100) according to one of the preceding claims, wherein determining the one or more performance metrics (105) of the network based on the data set (102) , based on the MTBF (103) and based on the time needed to repair faults in the network (104) comprises:

performing a numerical simulation (208) over a predefined time of operation of the network using the data set (102) , the MTBF (103) and the MTTR (207) ; and

determining the one or more performance metrics (105) of the network based on one or more results of the numerical simulation (208) and based on the generated routing scheme.
The device (100) according to claim 5, wherein the numerical simulation (208) comprises:

sampling one or more failure occurrences in the network based on the MTBF (103) ; and/or

sampling one or more times to repair faults based on the MTTR (207) .
The device (100) according to claims 5 and 6, wherein the one or more results of the numerical simulation (208) comprise at least one of: a list of congestion events of the network; a size of the network; and a duration of the congestion events.
The device (100) according to one of the preceding claims, wherein the one or more performance metrics (105) comprise at least one of: a connectivity metric; a total number of failed links and nodes of the network during a simulation period time; a low congestion metric; a maximum congestion level occurrence of a link during the simulation period time; an average congestion area during the simulation period time; a Complementary Cumulative Distribution Function, CCDF, with a congestion duration; and a network expected convergence time.
The device (100) according to any one of the preceding claims, wherein determining the performance of the network (106) based on determined one or more performance metrics (105) comprises:

performing an analysis of the determined one or more performance metrics (105) .
The device (100) according to claim 9, wherein determining the performance of the network (106) based on determined one or more performance metrics (105) further comprises:

performing a comparison (209) of two or more network architectures based on the determined one or more performance metrics (105) .
The device (100) according to any one of the preceding claims, wherein the device (100) further comprises a display device (310) configured to:

display the determined performance of the network (106) ; and/or

display the comparison (209) of the two or more network architectures.
A method (800) for network performance analysis, comprising:

receiving (801) network data (101) ;

parsing (802) the received network data (101) into a data set (102) , wherein the data set (102) comprises a topology of the network;

determining (803) one or more performance metrics (105) of the network based on the data set (102) , based on a mean time between failures, MTBF (103) , and based on a time needed to repair faults in the network (104) ; and

determining (804) a performance of the network (106) based on the one or more performance metrics (105) .
A computer program product comprising a program code for carrying out, when implemented on a processor, the method (800) according to claim 12.