Performance pattern correlation

A method includes identifying a plurality of network components in a network topology of a data transmission network, identifying data transmission performance patterns based on at least one key performance indicator (KPI) for each of the plurality of network components, identifying at least one data transmission issue in the network, and identifying a model degraded performance pattern associated with the at least one data transmission issue. The method may also include matching the model degraded performance pattern to the data transmission performance patterns to form matched performance patterns, and identifying a root-cause component from the network components based on the matched performance pattern.

BACKGROUND

Voice and data networks may experience degradation of performance resulting from many different issues in the network. These issues may include backhaul issues, such as a noisy or failed link, an overloaded link, damaged cable, dirty fiber, a crashed server or an overloaded server; etc. Issues may also arise based on software problems, such as incorrect buffer settings, incorrect format for packets, excessively delayed packets, corrupt, or missing packets, corrupt routing tables, etc. Problems may be intermittent or continuous. Intermittent problems tend to be more difficult to diagnose than continuously present problems.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description is exemplary and explanatory only and is not restrictive of the invention, as claimed.

Systems and/or methods described herein may identify a data transmission performance pattern based on measurement of key data transmission performance indicators over a time. The key data transmission performance indicators may include latency, jitter, frame loss, etc. In some instances, devices that communicate data over a network may receive degraded data. The systems may identify one or more root-cause components of degraded performance based on correlation between a degraded data transmission performance pattern and the root-cause component in a network. The root-cause component may be a network element associated with data transmission that introduces the data transmission issue into the network.

Consistent with embodiments described herein, the systems may monitor network performance and match performance changes/degradation to root-cause components and identify the solutions. The systems may be used in conjunction with self-optimizing tools to ensure peak performance of the network.

FIG. 1is a block diagram of an exemplary network100in which systems and methods described herein may be implemented. As illustrated, network100includes a number of test user equipment (TUE) devices102-1,102-2and102-x(collectively referred to as TUEs102or individually as TUE102), an external test server104, a performance pattern matching (PPM) device106, a plurality of key process monitors108, a packet data network (PDN)110(e.g., the Internet or a proprietary packet data network), an evolved packet core (EPC) network120, and an access network (AN)130. EPC120may include a mobility management entity (MME)122, a serving gateway (SGW)124, a PDN gateway (PGW)128, and an internal test server140. AN130may include an evolved universal terrestrial radio access network (E-UTRAN)132and a number of eNodeBs (eNBs)134-1and134-2or enhanced node base stations (collectively referred to as eNBs134or individually as eNB134). Devices/networks of network100may interconnect via wired and/or wireless connections.

Two TUEs102, two eNBs134, a single external test server106, PDN110, EPC120, AN130, MME122, SGW124, PGW128, E-UTRAN132, and internal test server140have been illustrated inFIG. 1for simplicity. In practice, there may be more or fewer devices or components. For example, a typical network100includes millions of subscriber user devices, thousands of eNBs134, hundreds of SGWs124and several PGWs128effectively forming a hierarchical access network in which traffic passes from PDN110to TUE102via, for example, a particular PGW128, SGW124, and eNB134. Although not shown, EPC120may include additional devices that facilitate network functions associated with the subscriber, such as a policy and charging rules function (PCRF) device, a broadcast multicast service center (BMSC), and a multimedia broadcast multicast service gateway (MBMS GW), a home subscriber server (HSS)/authentication, authorization, and accounting (AAA), etc.

TUE102may include any device that is capable of communicating over AN130, EPC network120, and/or PDN110. For example, TUE102may include a radiotelephone, a personal communications system (PCS) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a wireless telephone, a cellular telephone, a smart phone, a personal digital assistant (PDA) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a laptop computer, a personal computer, a tablet computer, or other types of computation or communication devices. In an exemplary implementation, TUEs102may include a pocket test user device. TUE102may operate according to one or more versions of the LTE communication standard.

External test server104may include a server configured to generate a test data flow142between the TUE102and external server104. The test data flow may be used to determine the throughput of network100(e.g., transmission control protocol (TCP) and/or user datagram protocol (UDP) based transmissions), and may be implemented using a bandwidth performance measuring tool, such as hypertext transfer protocol performance testing tool (HTTPERF) or an Internet performance testing tool (IPERF). The test data flow may be transport layer (layer 4 (L4), or TCP) flow that may be used as a network performance measuring tool in network100. The test data flow may be sent from the external test server102to the TUE102via particular network elements, such as a particular MME122, SGW124, PGW128, etc. Although not shown inFIG. 1, the test data flow may be sent through other devices in network that may be positioned between illustrated components (e.g., router, repeaters, etc., between SGW124and eNB134-2).

KPMs108may include small form factor probes (SFPs) that measure the performance of each network element. KPMs108may be implemented as part of a performance monitoring system to measure the ongoing performance of each network element in delivering the test data flow142based on key performance indicators (KPIs), such as described below with respect toFIGS. 2,3A and3B. For example, the KPIs may include jitter, frame loss, latency, or other measure of the data transmission performance of network100. The KPMs108may measure the performance based on KPI's for data flows between particular network elements over time frames appropriate to the particular KPI (e.g., seconds or milliseconds for latency). As shown inFIG. 1, KPMs108may be implemented to measure the performance of PGW128, MME122, SGW124, eNBs134, etc., in transmitting test data flow142from external test server104to TUE102.

PDN110includes a network that provides data services (e.g., via packets or any other Internet protocol (IP) datagrams). For example, PDN110may include the Internet, an intranet, an asynchronous transfer mode (ATM) network, etc.

EPC network120may include core network architecture of the 3rd Generation Partnership Project (3GPP) LTE wireless communication standard. In one example, EPC network120may include an all-IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies. In another example, EPC network120may provide packet-switched voice services (e.g., which are traditionally circuit-switched) using an IP multimedia subsystem (IMS) network. EPC120may include MME122, SGW124, PGW128, and internal test server140.

PGW128includes one or more data transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a network interface controller (NIC), a hub, a bridge, a proxy server, an optical add/drop multiplexer OADM, or some other type of device that processes and/or transfers data. PGW128provides connectivity of TUE102to external packet data networks (e.g., to PDN110) by being a traffic exit/entry point for TUE102. As described briefly above, TUE102may connect to PGW128via one or more tunnels established between eNB134and PGW128, such as one or more GPRS Tunneling Protocol (GTP) tunnels. TUE102may simultaneously connect to more than one PGW for accessing multiple PDNs. PGW128may perform policy enforcement, packet filtering for each user, charging support, lawful intercept, and packet screening. PGW128may also act as an anchor for mobility between 3GPP and non-3GPP technologies.

MME122is responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for TUE102. For example, MME122maintains information regarding a current state (e.g., powered on, location, etc.) of TUE102. MME122is also involved in the bearer activation/deactivation process (e.g., for TUE102) and operates to choose a particular SGW124for TUE102at an initial attach time and at a time of intra-LTE handover. In addition, MME122authenticates TUE102(e.g., via interaction with HSS122). Non-access stratum (NAS) signaling terminates at MME122and MME122generates and allocates temporary identities to UEs (e.g., TUE102).

Furthermore, MME122may check authorization of TUE102to connect to a service provider's Public Land Mobile Network (PLMN) and may enforce roaming restrictions for TUE102. MME122may be a termination point in EPC network106for ciphering/integrity protection for NAS signaling and may handle security key management. MME122may provide a control plane function for mobility between LTE and second generation mobile telecommunications or third mobile generation telecommunications (2G/3G) 3GPP access networks with an S3 interface (i.e., an interface that provides the connection between a serving general packet radio service (GPRS) support node (SGSN) and MME122in an LTE network) terminating at MME122.

SGW124routes and forwards user data packets, acts as a radio mobility anchor for a user plane during inter-eNB handovers, and also acts as an radio anchor for mobility between LTE and other 3GPP technologies (referred to as “inter-3GPP mobility”). As shown, SGW124is connected to eNBs134to provide a radio layer mobility control plane. In addition, SGW124manages and stores contexts associated with TUE102(e.g., parameters of an IP bearer service, network internal routing information, etc.).

Internal test server140may generate and/or control data flows between network devices within EPC120. In one implementation, internal test server140may be implemented in con junction with PPM106to monitor the performance of elements within network100to capture KPIs, such as packet loss, latency, jitter, and similar parameters.

PPM106may receive performance patterns (e.g., a latency pattern, a frame loss pattern, etc.) for each network node or element, including data transmission performance patterns from MME122, SGW124, PGW128, etc. PPM106may perform KPI layer correlation (e.g., based on a rate of change of the KPI) to identify the root-cause of data transmission issues that may affect the quality of the data transmitted from external test server104to TUE102. PPM106may use for pattern matching to find correlated elements that are degrading data transmission services, such as described below with respect toFIGS. 2 to 6.

AN130includes a communications network that connects subscribers (e.g., TUE102) to a service provider. In one example, AN130may include a WiFi network or other access networks (e.g., in addition to E-UTRAN132).

E-UTRAN132includes a radio access network capable of supporting high data rates, packet optimization, large capacity and coverage, etc. E-UTRAN132includes a plurality of eNBs14.

eNBs134includes network devices that operate according to one or more versions of the LTE communication standard. For example, eNBs134may be configured to respond to UE requests, forward information regarding TUEs102to MME122and/or SGW124, set up tunneling sessions with other devices (e.g., SGW124and PGW128), etc. eNBs134are base stations in network100and may include control plane connections to other network elements.

In implementations described herein, data transmission performance patterns associated with particular may be monitored and, in some instances, recorded. Performance patterns associated with particular data transmission issues may be identified and pattern matching processes may be implemented to correlate to the data transmission issues with root-causes of the data transmission issues (e.g., a root-cause component that introduces the data transmission issue to the data flow).

FIG. 2is a diagram of exemplary functional components of PPM106. PPM106may comprise machine-readable instructions, hardware, or a combination of hardware and machine-readable instructions. PPM106may include a test control module210, a performance pattern identification module220, and an optimization module230. According to an embodiment, PPM106may be a component of a testing device, such as external test sever104or internal test server140as described with respect toFIG. 1above. Alternatively, PPM106may be implemented as a separate device that is operably connected to the testing device (e.g., PPM106may be connected to internal test server140via a wireless or wired connection) or deployed at a separate location that receives reports from KPMs108. The configuration of components of PPM106illustrated inFIG. 2is for illustrative purposes only. Other configurations may be implemented. Therefore, PPM106may include additional, fewer and/or different components than those depicted inFIG. 2.

Test control module210may implement and identify test data flows to determine performance patterns associated with network elements, for example in conjunction with external test server104. Test control module210may perform monitoring functions in network100for data transmission performance issues. Test control module210may also initiate diagnostic functions for data transmission issues in network100based on identified data transmission issues. For example, test control module210may receive reports of data transmission issues in the network100(e.g., from user devices) and generate test flows and/or identify baseline flows (prior to introduction of data transmission issues) from external test server104to pocket test applications running in TUEs102.

Performance pattern identification module220may receive performance pattern reports from (or associated with) particular network elements (e.g., a particular SGW124, eNB134, etc.). KPMs108may provide performance pattern reports regarding performance pattern associated with network elements based on KPIs to performance pattern identification module220. KPMs108may provide the performance pattern reports periodically, based on data transmission events, or constantly. The status report may include a performance pattern based on KPIs for each network element (i.e., eNB134), such as a latency pattern, frame loss pattern, etc., for example as shown inFIGS. 3A and 3B. The performance pattern for each network component that transmits the test data flow may be measured and provided to performance pattern identification module220.

FIG. 3Ashows performance patterns300for baseline behavior of the data transmission. The performance patterns300in this instance include a latency pattern310and a frame loss pattern320. The performance patterns300for baseline behavior may be measured at a point in network100at which the test data flow does not include any data transmission issues (i.e., the data transmission performance pattern is a “clean” performance pattern at that point in the network). The latency pattern310is measured in terms of latency302and the frame loss pattern320in terms of frame loss322over a monitored time304. The time frame of the performance patterns may be based on the corresponding KPI (e.g., milliseconds for latency). The latency of the test data flow in this instance is constant, reflecting that the test data flow does not include data transmission issues at the particular point in network100at which the clean performance pattern was measured (e.g., at PGW128for the data transmission between PGW128and SGW124). Similarly, the frame loss pattern320indicates that there is minimal frame loss at that particular point in network100. In other words, latency pattern310and frame loss pattern320reflect the performance pattern of the test data flow at a point in the network prior to introduction of the data transmission issues to the test data flow via a root-cause component for data transmission issues.

FIG. 3Bshows performance patterns350measured at a point in network100at which the test data flow includes data transmission issues (i.e., the data transmission performance pattern is a “degraded” performance pattern at that point in the network). The latency pattern360of the test data flow in this instance fluctuates, reflecting that the test data flow includes data transmission issues at the particular point in network100at which the degraded performance pattern was measured (e.g., after SGW124for the data transmission between SGW124and eNB134). Similarly, the frame loss pattern320indicates that there is increasing frame loss at that particular point in network100. In other words, latency pattern310and frame loss pattern320reflect the performance pattern of the test data flow at a point in the network after data transmission issues have been introduced to the test data flow via a root-cause component for data transmission issues. The degraded performance patterns350may indicate a data transmission issue that currently affects the data transmission received by TUE102. Alternatively, the degraded performance pattern may be a precursor to data transmission issues that may be experienced by the user. For example, if the performance pattern indicates that the latency is increasing, eventually the test data flow may experience packet loss. Once packet loss occurs, the exponential function will result in decreased throughput because of the circular function of resending packets.

In instances in which data transmission issues are identified in the network, performance pattern identification module220may implement pattern matching to locate correlated elements that are degrading the data transmission. Performance pattern identification module220may implement the pattern matching process in a similar manner as described below with respect toFIG. 6to determine common points of failure and where problems occur based on KPIs. Performance pattern identification module220may determine a particular type of data transmission issue based on matching the performance pattern with a previously stored performance pattern that corresponds to a particular type of data transmission issue and/or root-cause.

Optimization module230may perform optimization processes to address the identified data transmission issues based on results generated by performance pattern identification module220in the performance matching process. For example, optimization module230may provide machine-readable instructions for a reconfiguration engine to dynamically redirect available resources in instances in which the data transmission is starting to back up at a particular component in the network. For example, optimization module230may redirect traffic e.g. from web traffic to voice traffic, change weights of queues or increase the buffer length. In some implementations optimization module230may change the priority that is assigned to a particular application on a central processing unit (CPU) of the root-cause component (i.e., increased CPU cycles for the particular application). In addition to shifting traffic, optimization module230may provide instructions to take action to take defective network elements out of the network100. Optimization module230may also provide results to technicians in instances in which self-optimization does not provide an appropriate resolution of the data transmission issues (e.g., optimization module230may provide a notification that additional bandwidth may be required).

FIG. 4illustrates a tree structure network topology400. As shown inFIG. 4, network topology400may include network components (or nodes) including PGW128, and a plurality of SGWs124, next generation multiplayer switches (ngMLSs)430, cell site routers (CSRs)432and TUEs102(illustrated as TUE102-1to TUE102-x), arranged at different levels throughout the tree structure network topology. Although a particular configuration of been illustrated inFIG. 1for simplicity. In practice, there may be more or fewer devices or components and the devices or components may be arranged differently in the network topology. Data transmission issues in network topology400are described with respect toFIGS. 5A and 5Billustrate errors in layers of the network500.

Network topology400may be arranged in hub and spoke model in which an initial data transmission may be sent from PGW128to a particular TUE102via intermediate components, such as a particular SGW124, ngMLs430and CSR432. CSRs432and ngMLS430are network devices that The tree structure network topology400also includes an associated representation of a transport layer410that may provide end to end communication services for applications (i.e., from PGW124to TUE102) and data link layers420-1to420-4that transfer data between each level of network components.

In some instances, a component or device may have a data transmission issue that leads to degradation of performance. For example, PGW128may transmit data with a clean performance pattern (CPP)440to a particular TUE102(e.g., TUE102-x). However, in some instances, data transmission errors may be introduced to the data flow. The data transmission errors may be observed (or measured) at different layers of the network topology400.

The systems and methods may identify a sequence of network components that transmit a test data flow. The systems may identify matched performance patterns correlated with data transmission issues. The systems may identify a highest network component in the network topology at which the matched performance pattern occurs as the root-cause component.

As shown inFIG. 5A, retransmission rate502is measured across the transport layer410(shown inFIG. 5Aas transport layer410-1to410-2) while frame loss occurs at the data link layer420(shown inFIG. 5Aas data link layer420-1to data link layer420-2).

In some instances, as described with respect toFIG. 5B, the systems and methods may be applied to determine a root-cause component of a data transmission issue. For example, a data transmission between a TUE102and an external test server104may be affected by different data transmission issues that manifest (i.e., cause change) in the retransmission rate502and frame loss504measured at different layers and/or across different components of the network. The data transmission issues may include Radio frequency (RF) or eNB issues (shown inFIG. 5Bas ENBI552), Ethernet backhaul transport issues (shown inFIG. 5Bas EBTI554), and internal or external network issues (shown inFIG. 5Bas NI566). In many instances, ENBI552and NI566may affect the retransmission rate502while EBTI554may affect both the retransmission rate502and frame loss504. The time frame over which the different data transmission issues manifest and/or degrade the quality of data transmission in the network may vary from milliseconds to minutes to days.

EBTI554may include data transmission issues as a result of dirty fiber, laser deterioration over time, fiber degradation over time, etc. In instances in which the EBTI554include laser deterioration over time, the systems may predict failure of the lasers by querying the laser light levels of boxes (e.g., tracking the laser light levels over months) and extrapolating to determine a point at which the laser should be replaced in order to maintain a target performance. Similarly, fiber may degrade over time resulting in polarization mode dispersal.

NI566may include incorrect data transmission settings, such as incorrect buffer settings that affect the latency of data transmission in the network. The system may measure different information elements associated with data transmission over time and predict future problems based on a precursor of another problem manifesting in the performance pattern (e.g., the system may model the point at which data transmission issues pass a predetermined threshold using a predictive model). For example, the system may predict changes in latency based on the relationship between buffer use and latency (e.g., the more full the buffer gets the more latency in the network increases).

FIG. 6illustrates logic components of performance pattern matching module220. As shown inFIG. 6, performance pattern matching module220may include a network topology logic610, a transmission issue pattern logic620, a performance pattern correlation logic630and a root-cause component location logic640.

Network topology logic610may identify a network topology of a network, including interconnections between network elements. Network topology logic610may provide a map that may be used to trace the path of data flows in the network.

Transmission issue pattern logic620may maintain a database of performance patterns and identified interrelationships between KPIs (at particular components or across a chain of components that transmit a data flow) that allows the system to predict the probable incidence of data transmission issues in the network. Transmission issue pattern logic620may identify and model KPI's (e.g., Poisson model, etc.) for network elements. Transmission issue pattern logic620may identify interrelationships between different KPIs and correlate the different KPI's to determine recurring anomalies and extrapolate (e.g., using Markov chains) to determine a predictive model of data transmission issues in the network and associated model degraded performance pattern. For example, jitter and frame loss may indicate borderline failures. Transmission issue pattern logic620may take each type of performance pattern over a time period and match the performance pattern to data transmission issues. Transmission issue pattern logic620may correlate different categories of data associated with the network elements based on the different KPI-based mathematical models associated with the network elements (e.g., operating systems and applications).

Transmission issue pattern logic620may identify different inherent structural dependencies and anomalies associated with particular network elements. For example, transmission issue pattern logic620may identify correlated behavior based on changes one or two standard deviations away from baseline (i.e., dependence between different KPIs and network elements). In some implementations, the models of performance patterns associated with the test data flow may be adjusted based on identified sources of other data transmission issues in instances in which there are multiple sources of data transmission issues in the network.

Performance pattern matching logic630may identify matches in performance pattern and data transmission related KPIs. Performance pattern matching logic630may perform a process of searching for a match between performance patterns at a particular network component that may be correlated with a performance pattern based on a KPI for another network component to identify root-cause components in the network topology (e.g., changes in a first KPI at a first component may eventually trigger changes in another KPI at another network component).

FIG. 7is a diagram of exemplary components of a device700that may correspond to TUE102, one or more devices in AN104, EPC106, PDN110, E-UTRAN132, eNB134, MME122, HSS122, SGW124, PGW128, ngMLS430, CSR432, or Ethernet backhaul router562as described inFIGS. 1-6above. As shown inFIG. 7, device700may include a bus710, a processor720, a memory730, an input device740, an output device750, and a communication interface760.

Bus710may permit communication among the components of device700. Processor720may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processor720may be implemented as or include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like.

Memory730may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor720, a read only memory (ROM) or another type of static storage device that stores static information and instructions for the processor720, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.

Input device740may include a device that permits an operator to input information to device700, such as a keyboard, a keypad, a mouse, a pen, a microphone, one or more biometric mechanisms, and the like. Output device750may include a device that outputs information to the operator, such as a display, a speaker, etc.

Communication interface760may include one or more transceivers that enables device700to communicate with other devices and/or systems. For example, communication interface760may include mechanisms for communicating with other devices, such as other devices of network100.

As described herein, device700may perform certain operations in response to processor720executing software instructions contained in a computer-readable medium, such as memory730. A computer-readable medium may include a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory730from another computer-readable medium or from another device via communication interface760. The software instructions contained in memory730may cause processor720to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 7shows exemplary components of device700, in other implementations, device700may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 7. As an example, in some implementations, input device740and/or output device750may not be implemented by device700. In these situations, device700may be a “headless” device that does not explicitly include an input or an output device. Alternatively, or additionally, one or more components of device700may perform one or more other tasks described as being performed by one or more other components of device700.

FIG. 8is a flow chart of an exemplary process for file recovery and error protection of a multicast/broadcast transmission according to implementations described herein. Process800is described with respect to network100shown inFIG. 1, for illustrative purposes. In one implementation, process800may be performed PPM106. In another implementation, some or all of process800may be performed by another device or group of devices, including or PPM106.

As shown inFIG. 8, process800may begin when PPM106identifies a network topology associated with a data transmission network (block802). PPM106may identify network components in the network and interrelationships between the network components.

At block804, PPM106may determine performance patterns based on KPIs for each of the network components (i.e., KPI-based performance patterns). For example, PPM106may monitor a signal transmitted from an external test server104to TUE102(e.g., using IPERF or similar network testing tool). PPM106may identify KPIs associated with each of the different network components. PPM106may identify latency and frame loss as KPI's associated with a particular component. PPM106may receive performance patterns from KPMs108associated with the network components.

PPM106may identify data transmission issues in the network that are associated with a particular performance pattern (block806). For example, PPM106may identify a data transmission issue and identify the performance pattern of the network component at which the data transmission issue is identified.

At block808, PPM106may identify a model degraded performance pattern associated with the data transmission issue. For example, PPM106may analyze performance patterns for the network components based on model degraded network performance patterns associated with particular data transmission issues to determine network components that are likely to generate data transmission issues.

At block808, PPM106may match the model degraded performance pattern to the data transmission performance patterns to form matched performance patterns. PPM106may identify correlation between KPI-based performance patterns associated with data transmission in the network.

At block810, PPM106may match correlated KPI-based performance patterns to identify a root-cause component for a data transmission issue. For example, PPM106may identify a root-cause component for the data transmission issue based on a correlation between the performance patterns for the different KPIs for network components that transmit the data flow which reflects the data transmission issue. The correlation may be between same or different KPI's and may be direct or indirect.

PPM106may apply optimization methods to the identified root-cause component (block812). For example, PPM106may correct for latency issues on a queue size level by adjusting the buffer size. In other implementations, a load balancer (not shown) may redirect traffic in the network to reduce traffic problems associated with particular network components.

Systems and/or methods described herein may record performance patterns based on KPIs for data transmission for different network components and correlate the performance pattern to a root-cause problem and the root-cause component.

In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. For example, while series of blocks have been described with respect toFIG. 8, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

It will be apparent that different aspects of the description provided above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects is not limiting of the invention. Thus, the operation and behavior of these aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement these aspects based on the description herein.

Further, certain portions of the invention may be implemented as a “component” or “system” that performs one or more functions. These components/systems may include hardware, such as a processor, an ASIC, or a FPGA, or a combination of hardware and software.