ALARM CORRELATION IN NETWORK FUNCTION VIRTUALIZATION ENVIRONMENT

BACKGROUND
Field

Correlation of information related to network operations may be useful in many communication systems. For example, certain wireless communication networks may benefit from alarm correlation in network function virtualization environments.

Description of the Related Art

FIG. 1 illustrates a network function virtualization environment (NFV) architectural framework. Specifically, the figure shows a NFV management and orchestration (MANO) architectural framework with reference points, as copied from section 5.3 of ETSI GS NFV-MAN 001, draft version 0.6.3 September 2014, the entirety of which is hereby incorporated herein by reference.

As shown in FIG. 1, the architecture can include a network functions virtualization orchestrator (NFVO), an element management (EM) function, a virtualized network function (VNF), a VNF manager (VNFM), a virtualized infrastructure manager (VIM), and network functions virtualization infrastructure (NFVI).

With NFV, the EM and network management (NM) may need to perform fault management for the applications such as network functions and the VNFM and VIM may need to perform fault management for the virtual machines (VMs). The VIM could perform fault management for virtualized infrastructure as to hardware; and EM traditionally has been responsible for the fault management of the hardware or physical network function (PNF) in NFV terms.

In an NFV environment, the VIM can forward the alarms about virtualized infrastructure and VM to the VNFM. The VNFM can forward the alarms about virtualized infrastructure and VM to the EM. The application layer alarm can be directly reported to the EM by the application or by the management module/unit of the application. The EM could forward the alarms with root cause or forward all of the received alarms to NM. However, a fault from underlayer may cause alarms in both the underlayer and the higher layers. For instance, a hardware fault could cause alarms in hardware layer, VM layer and application layer, and this hardware fault cannot be resolved by restoring the VM or the application without clearing the alarm or resolving an issue at the virtualized infrastructure layer. Similarly, a VM fault may cause alarms at both VM layer and application layer, restoration of the application on the same VM cannot resolve the issue for similar reasons in such a case.

The terms “underlayer,” “lower layer,” or “layer N-1” are terms that can be used interchangeably to describe a layer below the current layer. It should be noted that in some cases the underlayer could be more than one rank below the current layer, and thus may be considered “layer N-2” or “layer N-3,” depending on the architecture employed. Other modifications are also possible.

Since the alarm (A) may be caused by a fault from an underlayer, the corresponding fault management entity may need to correlate the alarm (A) with the alarms generated at underlayer, if any, to locate the fault and resolve the issues.

So, for the application layer alarm, the EM/NM may need to know whether the alarm is caused by the fault from VM or virtualized infrastructure where the application is installed; for the VM layer alarm, the VNFM may need to know whether the fault is from hardware on which the VM is residing.

There is a fault management flow described in ETSI MANO GS. FIG. 2 illustrates a fault management flow. More particularly, FIG. 2 illustrates NFV MANO fault management flow, as copied from section B.6 of ETSI GS NFV-MAN 001, draft version 0.6.3 September 2014. However this flow is too generic and showing the correlation may be needed in various entities, but this flow lacks a detailed solution to enable the alarm correlation in these entities.

ETSI NFV MANO GS provides high level information on a possible fault management flow. This flow is better characterized as a requirement for alarm correction rather than a correlation.

FIG. 3 illustrates potential problems with alarm correlation. FIG. 3 is copied from section 3.2.3 of 3GPP SA5 T-Doc S5-144330 “Event correlation points for Virtualized 3GPP network management,” the entirety of which is hereby incorporated herein by reference. As shown in FIG. 3, a communication failure may be due to a link failure, which may be easier to identify in an older architecture (labelled “existing”) than in a virtualized architecture. In the virtualized architecture, the link failure may provide alarms to the EM, VIM, and NM.

SUMMARY

According to certain embodiments, a method can include correlating alarms within a lower layer of a network function virtualization environment. The method can also include forwarding at least one of the correlated alarms to an entity managing an upper layer of the network function virtualization environment for further correlation with upper layer alarms.

In certain embodiments, a method can include receiving alarms that have been correlated for a lower layer of a network function virtualization environment. The method can also include correlating further the correlated alarms for an upper layer of the network function virtualization environment.

A method, according to certain embodiments, can include receiving, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The method can also include correlating the alarm with at least one other alarm based on the underlayer identifier.

A method, in certain embodiments, can include including, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The method can also include reporting the alarm to an entity managing the higher layer for correlation with at least one other alarm based on the underlayer identifier.

A method, according to certain embodiments, can include receiving, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The method can also include correlating the alarm with at least one other alarm based on the upperlayer identifier.

A method, in certain embodiments, can include including, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The method can also include reporting the alarm to an entity managing the higher layer for correlation with at least one other alarm based on the upperlayer identifier.

According to certain embodiments, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to correlate alarms within a lower layer of a network function virtualization environment. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to forward at least one of the correlated alarms to an upper layer of the network function virtualization environment for further correlation at the upper layer.

In certain embodiments, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive alarms that have been correlated at a lower layer of a network function virtualization environment. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to correlate further the correlated alarms at an upper layer of the network function virtualization environment.

An apparatus, according to certain embodiments, can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to correlate the alarm with at least one other alarm based on the underlayer identifier.

An apparatus, in certain embodiments, can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to include, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to report the alarm to a higher layer for correlation with at least one other alarm based on the underlayer identifier.

An apparatus, according to certain embodiments, can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to correlate the alarm with at least one other alarm based on the upperlayer identifier.

An apparatus, in certain embodiments, can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to include, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the apparatus at least to report the alarm to a higher layer for correlation with at least one other alarm based on the upperlayer identifier.

According to certain embodiments, an apparatus can include means for correlating alarms within a lower layer of a network function virtualization environment. The apparatus can also include means for forwarding at least one of the correlated alarms to an upper layer of the network function virtualization environment for further correlation at the upper layer.

In certain embodiments, an apparatus can include means for receiving alarms that have been correlated at a lower layer of a network function virtualization environment. The apparatus can also include means for correlating further the correlated alarms at an upper layer of the network function virtualization environment.

An apparatus, according to certain embodiments, can include means for receiving, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The apparatus can also include means for correlating the alarm with at least one other alarm based on the underlayer identifier.

An apparatus, in certain embodiments, can include means for including, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The apparatus can also include means for reporting the alarm to a higher layer for correlation with at least one other alarm based on the underlayer identifier.

An apparatus, according to certain embodiments, can include means for receiving, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The apparatus can also include means for correlating the alarm with at least one other alarm based on the upperlayer identifier.

An apparatus, in certain embodiments, can include means for including, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The apparatus can also include means for reporting the alarm to a higher layer for correlation with at least one other alarm based on the upperlayer identifier.

A non-transitory computer-readable medium can, according to certain embodiments, be encoded with instructions that, when executed in hardware, perform a process. The process can include any of the above-described methods.

A computer program product can, in certain embodiments, encode instructions for performing a process. The process can include any of the above-described methods.

BRIEF DESCRIPTION OF THE DRAWINGS

For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

FIG. 1 illustrates a network function virtualization environment (NFV) architectural framework.

FIG. 2 illustrates a fault management flow.

FIG. 3 illustrates potential problems with alarm correlation.

FIG. 4 illustrates virtualized infrastructure alarm reporting, according to a first alternative, in certain embodiments.

FIG. 5 illustrates VNFC layer alarm reporting, according to a first alternative, in certain embodiments.

FIG. 6 illustrates application layer alarm reporting, according to a first alternative, in certain embodiments.

FIG. 7 illustrates application layer alarm reporting according to a second alternative, in certain embodiments.

FIG. 8 illustrates Table 1: Attributes of InventoryUnitVM IOC, according to certain embodiments.

FIG. 9 illustrates Table 2: Added attributes into the definition of VMUnits, according to certain embodiments.

FIG. 10 illustrates Table 3: Definition of VMList, according to certain embodiments.

FIG. 11 illustrates methods according to certain embodiments.

FIG. 12A illustrates other methods according to certain embodiments.

FIG. 12B illustrates further methods according to certain embodiments.

FIG. 13 illustrates a system according to certain embodiments.

DETAILED DESCRIPTION

Certain embodiments provide a method and system for alarm correlation in an NFV environment. More particularly, certain embodiments provide detailed solutions on alarm correlation to support the fault management entities to find the root cause of the alarm. There may be at least three alternatives with a variety of variations of methods and systems for providing such correlation.

According to certain embodiments in a first alternative, related lower and/or higher layer information can be carried forward in alarm reporting:

In this alternative, hardware (H/W) layer, VM layer, VNFC layer, and application layer alarms can each take into account information that may be needed for correlation performed elsewhere, such as at a higher layer.

FIG. 4 illustrates virtualized infrastructure alarm reporting, according to a first alternative, in certain embodiments. As shown in FIG. 4, for the H/W or virtualized infrastructure layer alarms, the original alarm may contain an H/W identifier. The VIM can add information about affected VM(s) and can forward this alarm to VNFM. The VNFM can add the information about affected VNF(s) and can forward this alarm to the EM. The EM can add the information about affected Managed Functions, for example, with their distinguished name (DN), and can forward this alarm to the NM.

Similarly, for the VM layer alarms, the original alarm can contain the VM identifier. The VIM can perform internal correlation of VM layer alarm(s) against any active virtualized infrastructure alarms. In case of a positive match meaning that an active virtualized infrastructure alarm is causing problem at VM layer and in case an alarm suppression mode selected, the VIM may suppress the VM layer alarm. In case of a positive match and alarm suppression mode de-selected, the VIM may add information about underlying H/W alarm(s) and virtualized infrastructure, and VM layer alarms may be grouped together. The VIM may then forward the alarm, with hardware information, to the VNFM. The VNFM may add information about affected VNF(s) and may forward this alarm to the EM. The EM can add information about affected managed functions (for example with their DN) and can forward this alarm to the NM.

FIG. 5 illustrates VNFC layer alarm reporting, according to a first alternative, in certain embodiments. As shown in FIG. 5, for the VNFC layer alarms, the original alarm can contain the VNFC, or virtualization deployment unit (VDU), identifier. The VNFM can perform internal correlation of VNFC layer alarm(s) against any active virtualized infrastructure and/or VM layer alarms the VNFM has received from VIM. In case of a positive match, meaning active virtualized infrastructure or VM layer alarm causing problem at application layer, and in case alarm suppression mode is selected, VNFM may suppress the VNFC layer alarm. In case of a positive match and alarm suppression mode de-selected, VNFM can add information about underlying H/W and VM alarm(s), with virtualized infrastructure, VM layer and VNFC layer alarms being grouped together. The VNFM can forward this alarm to the EM. The EM can add the information about affected managed functions, for example with the DN(s) of the affected managed function(s), and can forward this alarm to the NM.

FIG. 6 illustrates application layer alarm reporting, according to a first alternative, in certain embodiments. As shown in FIG. 6, for application layer alarms, the original alarm can contain the managed function, for example DN, identifier. The EM can perform internal correlation of application layer alarm(s) against any active VNFC, virtualized infrastructure and/or VM layer alarms the EM has received from VNFM. In case of a positive match, meaning active VNFC, virtualized infrastructure or VM layer alarm causing problem at application layer, and in case of alarm suppression mode selected, the EM may suppress the application layer alarm. In case of a positive match and alarm suppression mode de-selected, the EM can add information about underlying VNFC, H/W and VM alarm(s), moreover VNFC layer, virtualized infrastructure, VM layer and application layer alarms can be grouped together. The EM can forward this alarm to the NM.

In this example embodiment, the “alarm suppression” can imply that only a root cause alarm is forwarded north-bound to higher layers, therefore minimizing the overall amount of alarm information reaching the operator. The other mode, where higher layer alarms are not suppressed, but rather combined with the lower layer alarms, may not reduce the overall amount of alarm data, but may provide a more complete picture in cases where an end-to-end (E2E) network model is not available. For example, mapping of apps to VNFC, VNFC to VM, and VM to H/W may not always be known.

Storage of active lower layer alarms at the forwarding entity may help internal alarm correlation. For example, the VIM may store both active virtualized infrastructure and VM alarms. The VNFM may store active alarms the VNFM received from the VIM (including, for example, both virtualized infrastructure and VM alarms) and alarms reported directly to VNFM. Furthermore, the EM may store all active alarms the EM received from VNFM.

According to certain embodiments in a second alternative, the related lower layer information can be queried in the alarm reporting. This approach may be similar to the first alternative approach described above. One difference may be that the forwarded information about lower layer active alarms may not be stored at the forwarding entity. Instead, whenever an alarm is reported at a particular layer, the management entity for the affected layer can query a lower layer's management entity about related/impacting active alarms. Thus, the active alarms may be stored only at the layer where they “belong” or were originated.

FIG. 7 illustrates application layer alarm reporting according to a second alternative, in certain embodiments. As shown in FIG. 7, for application layer alarms, the original alarm can contain the managed function (for example DN) identifier. The EM can query the VNFM about any active alarms impacting the managed function. The VNFM can receive the query from the EM and can check for any active alarms at VNF/VNFC layer. In addition the VNFM may also query the VIM for any alarms impacting the VNF/VNFC in question. The VNFM can report the active alarms to EM. The EM can receive the lower layer alarms from the VNFM and can correlate them with the active application layer alarm.

The EM can then make a decision whether to forward an active application layer alarm to the NM based on the results of correlation step and suppression mode. In case of negative correlation result, the application layer alarm can be tagged with an application layer root cause and forwarded to the NM. In case of a positive correlation result and active suppression mode, the active application layer alarm may not be forwarded to the NM. In case of positive correlation result and inactive suppression mode, the active application alarm can be tagged with lower layer root cause (alarm information can be combined) and can be forwarded to the NM.

The procedure may be viewed as recursive query of one layer below for each new active alarm. However, with proper alarm classification (for example, an active alarm at N-1 layer impacting layer N may result in an active alarm at layer N), the recursion (query of more than level deep) may not be needed.

Certain embodiments according to a third alternative can include carrying the related lower layer information in the data model. Thus, for example, the application layer object class XYZFunction (no matter the upper or lower case, for example, MMEFunction) can indicate (by the VNF or its OAM Unit/Client) the underlayer VM (where the application XYZ is installed) by any kind of identifier that could identify the VM, for example an instance DN.

Furthermore, in certain embodiment the VM layer object class such as VMUnit/InventoryUnit (no matter what is the name of the object class) can indicate (by the VIM) the underlayer hardware (where the VM is generated on) by any kind of identifier that could identify the hardware, for example, the instance DN.

When the alarm of a certain layer is received, the fault management entity can check whether the fault management entity has also received an alarm of underlayer resource (as indicated by the instance of the data model) in a certain time window, to determine a location of the root cause of the alarm. For instance, for the alarm of a XYZFunction instance, if the alarms of the underlayer VM (indicated by the instance of the XYZ model) are also received and no alarm of the underlayer hardware (indicated by the instance of the VM object class) is received, the root cause may be determined to be at the VM.

For this alternative, another option may be to carry the related upper layer information in the data model, the principles can be similar to those described above.

These embodiments can be variously implemented. For example, according to the third alternative, the VM can be modeled into InventoryUnitVM information object class (IOC) or another name (see, for example, 3GPP TS 28.632, which is hereby incorporated herein by reference in its entirety), and include the hwList attribute in this IOC. FIG. 8 illustrates Table 1: Attributes of InventoryUnitVM IOC, according to certain embodiments.

In another example, an attribute can be added indicating VMs that the VNF is running on, into the ManagedFunction (see, for example, 3GPP TS 28.632) IOC or concrete IOC (see, for example, 3GPP TS 28.708, which is hereby incorporated herein by reference) representing VNF such as MMEFunction. FIG. 9 illustrates Table 2: Added attributes into the definition of VMUnits, according to certain embodiments. Similarly, FIG. 10 illustrates Table 3: Definition of VMList, according to certain embodiments. Tables 1 through 3 are just some illustrative examples. Other implementations are possible and are permitted.

In certain embodiments, the InventoryUnitHw IOC (described at section 4.3.3 of 3GPP TS 28.632) can be reused to model the hardware in the NFV environment.

Furthermore, in certain embodiments, the VIM can model VM and HW, for instance into IntentoryUnitHw and the InventoryUnitVM and can send these models to VNFM. The VNFM can then forward these models to the EM. The EM can forward these models and the VNF model (for example, MMEFunction) created by the EM to the NM. The VIM can report/forward the alarms for VM and HW respectively, with the instance identifiers (for example, DN) of the models, to the VNFM/NFVO. The VNFM/NFVO can correlate the alarms based on the models.

Additionally, the VNFM can forward the alarms for VM and HW, with the instance identifiers (for example, DN) of the models, to the EM. The VNF can report the alarms for VNF layer only to the EM/VNFM and the EM/VNFM can correlate the alarms by the models. Alternatively, the EM/NFVO can forward the alarms for VNF, VM/HW respectively with the instance identifiers (for example, DN) of the models to the NM. The NM can then correlate the alarms based on the models.

FIG. 11 illustrates methods according to certain embodiments. As shown in FIG. 11, a method can include, at 1110, correlating alarms within a lower layer of a network function virtualization environment. The method can also include, at 1120, forwarding at least one of the correlated alarms to an entity managing an upper layer of the network function virtualization environment for further correlation at the upper layer with upper layer alarms. In certain embodiments, only one of the correlated alarms may be forwarded.

In certain embodiments, the method can include, at 1130, including, at the lower layer, information relevant to the upper layer for correlation without the information being explicitly requested by the upper layer. Alternatively, in certain embodiments the method can include, at 1105, querying a layer below the lower layer for information used in the correlation at the lower layer. In certain cases, the information could be included without waiting for a request from the upper layer and could also be obtained by querying a layer below the lower layer.

A method can include, at 1140, receiving alarms that have been correlated for a lower layer of a network function virtualization environment. These may be the same alarms sent at 1120. The method can include, at 1150, correlating further the correlated alarms for an upper layer of the network function virtualization environment. The alarms can be received with information relevant to the upper layer for correlation without the information being explicitly requested by the upper layer.

Alternatively, the method can include, at 1145, querying the lower layer for information used in the correlation at the upper layer. The lower layer can, at 1147, provide the relevant information. This information can then be used at 1150 to further correlate the correlated alarms.

The methods illustrated in FIG. 11 may include various methods according to the first and second alternatives discussed above. Various modifications and adjustments may be made to the illustrated method based on the discussion of the various alternatives described above.

FIG. 12A illustrates other methods according to certain embodiments. As shown in FIG. 12A, a method can include, at 1210, receiving, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The method can also include, at 1220, correlating the alarm with at least one other alarm based on the underlayer identifier.

Similarly, a method can include, at 1230, including, in or separated from a report of an alarm, an identifier of underlayer resource supporting the upperlayer resource or functionality to be used for alarm correlation at a centralized entity. The method can also include, at 1240, reporting the alarm to an entity managing the higher layer for correlation with at least one other alarm based on the underlayer identifier. This can be the same report received at 1210.

FIG. 12B illustrates further methods according to certain embodiments. As shown in FIG. 12B, a method can include, at 1250, receiving, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The method can also include, at 1260, correlating the alarm with at least one other alarm based on the upperlayer identifier.

Similarly, a method can include, at 1270, including, in or separated from a report of an alarm, an identifier of upperlayer resource or functionality supported by the underlayer resource to be used for alarm correlation at a centralized entity. The method can also include, at 1280, reporting the alarm to a higher layer for correlation with at least one other alarm based on the upperlayer identifier. This can be the same report received at 1250. As with the embodiments of FIG. 12A, in the embodiments of FIG. 12B, the upperlayer identifier can indicate an upperlayer virtual machine for virtualized network function.

The underlayer identifier can indicate an underlayer hardware. Moreover, the underlayer identifier can include a hardware identifier or virtual machine identifier, or both.

FIG. 13 illustrates a system according to certain embodiments of the invention. In one embodiment, a system may include multiple devices, such as, for example, at least one lowest layer function 1310, at least one lower layer function 1320, and at least one upper layer function 1330. These various functions may be any of the functions or elements shown in the example architecture of FIG. 1 or any of the other functions or elements shown or described in any of the other figures.

Each of these devices may include at least one processor, respectively indicated as 1314, 1324, and 1334. At least one memory can be provided in each device, and indicated as 1315, 1325, and 1335, respectively. The memory may include computer program instructions or computer code contained therein. The processors 1314, 1324, and 1334 and memories 1315, 1325, and 1335, or a subset thereof, can be configured to provide means corresponding to the various blocks of FIGS. 11, 12A, and 12B.

As shown in FIG. 13, transceivers 1316, 1326, and 1336 can be provided, and each device may also include an antenna, respectively illustrated as 1317, 1327, and 1337. Other configurations of these devices, for example, may be provided. For example, upper layer function 1330 may be configured for wired communication, instead of or in addition to wireless communication, and in such a case antenna 1337 can illustrate any form of communication hardware, without requiring a conventional antenna. Indeed, it is not required that any of these devices have their own antenna. Furthermore, in certain embodiments, the various functions may be embodied in a single physical device, such as rack computing system, or a single computer.

Transceivers 1316, 1326, and 1336 can each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that is configured both for transmission and reception.

Processors 1314, 1324, and 1334 can be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors can be implemented as a single controller, or a plurality of controllers or processors.

Memories 1315, 1325, and 1335 can independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory can be used. The memories can be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

The memory and the computer program instructions can be configured, with the processor for the particular device, to cause a hardware apparatus such as lowest layer function 1310, lower layer function 1320, and upper layer function 1330, to perform any of the processes described herein (see, for example, FIGS. 11, 12A, and 12B). Therefore, in certain embodiments, a non-transitory computer-readable medium can be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain embodiments of the invention can be performed entirely in hardware.

Furthermore, although FIG. 13 illustrates a system including a lowest layer function, lower layer function, and upper layer function, embodiments of the invention may be applicable to other configurations, and configurations involving additional elements or additional layers. For example, see the various layers shown in FIGS. 4-7.

One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

List of Abbreviations

EM Element Management

FCAPS Fault, Configuration, Accounting, Performance and Security

NFV Network Functions Virtualization

NFV-MANO NFV Management and Orchestration

NFVONetwork Functions Virtualization Orchestrator

NM Network Management

OSS Operations Support System

VIM Virtualised Infrastructure Manager

VM Virtual Machine

VNF Virtualized Network Function

VNFM VNF Manager

ALARM CORRELATION IN NETWORK FUNCTION VIRTUALIZATION ENVIRONMENT

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

PCT Information