4 Fault Management procedures

28.5163GPPFault Management (FM) for mobile networks that include virtualized network functionsProceduresRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Introduction

The overview of alarm data flow procedures in context of NFV is showed as Figure 4.1-1 3GPP view of FM data flows.

Figure 4.1-1: 3GPP view of alarm data flows for NE/VNF

The alarm data flow and the alarm mapping of VNF instance application alarm and VNF instance related virtualized resource alarm are described as below:

– Flow-1 VIM reports virtualized resources alarm data to VNFM (out of scope of the present document).

– Flow-2 VNFM sends VNF alarm data related to virtualized resources (mapped to VNF instance, correlated or not-correlated) to EM.

– Flow-3 VNF reports virtualization-specific alarm data to VNFM.

– Flow-X Via 3GPP Type 1 interface VNF instance reports VNF instance application alarm data and virtualization-specific alarm data to EM.

– Flow-Z Via 3GPP Type 1 interface non-virtualized NEs report alarm data to EM.

– Flow-Y Via 3GPP Itf-N EM sends the following: VNF instance application alarm data and virtualization-specific alarm data (received via Flow-X), VNF alarm data related to virtualized resources (received via Flow-2),non-virtualized NE alarm data (received via Flow-Z), and/or correlated VNF instance alarm data.

EM may make the alarm correlation based on information contained in Flow-X, Flow-Z and Flow-2, using the same VNF/VNFC instance identifier based on the VNF instance alarm data related to virtualized resource and VNF instance application alarm data. EM may report the correlated VNF instance alarm data to NM.

NM may make the alarm correlation based on information contained in Flow-X, Flow-Y, Flow-Z and Flow-2, using the same VNF/VNFC instance identifier based on the VNF instance alarm data related to virtualized resource and VNF instance application alarm data.

The procedures listed in clause 4, as some of all the possibilities, are not exhaustive.

4.2 NE alarm correlation in the context of NFV

4.2.1 NE alarm correlation made by EM in the context of NFV

When a new failure occurs from the virtualized resource and it impacts the corresponding NE application, EM can make the alarm correlation based on the virtualized resource failure report sent from VNFM and VNF application alarms.

The figure 4.2.1-1 illustrates the procedure of EM makes NE alarms correlation in a mobile network that includes virtualized network functions.

Figure 4.2.1-1: Procedure of NE alarm correlation made by EM in the context of NFV

1) A new failure occurs from the virtualized resource and it impacts the corresponding NE application.

2) VNFM received virtualized resource alarms as described in ETSI NFV ISG.

3) VNFM sends VNF instance alarms related to virtualized resource to EM. The VNF and/or VNFC alarms related to virtualized resource include AlarmId, affected VNF identifier, affected VNFC identifiers, and FaultDetails which provides additional information about the virtualized resource fault, for example the resource identifier which causes the fault (e.g. VM identifier, vNIC identifier or vPORT identifier). The Alarm information element see clause 9.3.4 of [3].

4) NE/VNF sends VNF application alarms to EM through proprietary interface, the corresponding VNF instance identifier and/or VNFC identifier should be included.

Note: There is no sequence restriction on EM receives VNF instance alarms related virtualized resource and EM receives VNF application alarms.

5) EM correlates the received VNF instance alarms related to virtualized resource with the received VNF application alarms.

6) EM sends the correlated alarm information to NM over Itf-N. The alarm information that carries correlated alarm information is specified in TS 32.111-2 [2].

4.2.2 NE alarm correlation made by NM in the context of NFV

When a new failure occurred from the virtualized resource and it impacts corresponding NE application, NM can make the alarm correlation based on the virtualized resource failure report sent from VNFM and VNF application alarms.

The figure 4.2.2-1 illustrates the procedure of NM makes NE alarms correlation in a mobile network that includes virtualized network functions.

Figure 4.2.2-1: Procedure of NE alarm correlation made by NM in the context of NFV

1) A new failure occurs from the virtualized resource and it impacts corresponding NE application.

2) VNFM receives virtualized resource alarms as described in [3].

4) EM sends VNF instance alarms related to virtualized resource to NM.

5) NE/VNF sends VNF application alarms to EM through proprietary interface, the corresponding VNF instance identifier and/or VNFC identifier should be included.

6) EM sends VNF application failure report of a NE to NM over Itf-N. The information in the failure report sees alarm information in TS 32.111-2 [2].

Note: There is no sequence restriction on EM receives VNF instance alarms related virtualized resource and NM receives VNF application failure report.

7) Based on the VNF instance alarms related to virtualized resource sent from VNFM and VNF application failure report, NM makes the alarm correlation.

4.3 Virtualization-specific aspect failure detection and notification

4.3.1 Virtualization-specific aspect failure detection and notification by VNFM

The figure 4.3.1-1 illustrates the procedure of notifying the EM about a virtualization-specific failure of a virtualized network function when virtualization-specific aspect failure detection and notification by VNFM.

Figure 4.3.1-1: Procedure of virtualization-specific aspect failure detection and notification by VNFM

1) EM subscribes to VNF-related virtualization fault reports.

2) A new virtualization-specific failure occurs and is detected by VNF virtualization-specific component.

3) VNF sends virtualization-specific fault notification to VNFM.

4) VNFM creates VNF virtualization-related fault report as described in ETSI NFV ISG.

5) VNFM sends VNF instance alarms generated due to changes in the state of virtualized resources used by the VNFs and their constituent VNFC instances to EM. The VNF and/or VNFC alarms related to virtualized resources include AlarmId, affected VNF identifier, affected VNFC identifiers, and FaultDetails which provides additional information about the fault, for example the resource identifier which causes the fault (e.g. VM identifier, vNIC identifier or vPORT identifier). The Alarm information element see clause 9.3.4 of [3].

4.3.2 Virtualization-specific aspect failure detection and notification by EM

The figure 4.3.2-1 illustrates the procedure of notifying the EM about a virtualization-specific failure of a virtualized network function.

Figure 4.3.2-1: Procedure of virtualization-specific aspect failure detection and notification by EM

1) A new virtualization-specific failure occurs and is detected by VNF virtualization-specific component.

2) VNF sends virtualization-specific fault notification to EM through proprietary interfaces, the corresponding VNF instance identifier and/or VNFC identifier should be included.

4.4 VNF Healing with operation request to VNFM by EM through Ve-Vnfm-em

Figure 4.4-1: Procedure of VNF Healing through operation request to VNFM by EM

1) EM determines to initiate a healing procedure to recover the faulty virtualization-specific aspects of the VNF.

2) EM sends to VNFM a HealVnfRequestwith input parameters vnfInstanceId, vnfcInstanceId, cause, additionalParam, and healScript to heal the VNF instance (see clause 7.2.10.2 of [3]).

3) VNFM sends to EM a HealVnfResponse acknowledging the request with parameter lifecycleOperationOccurrenceId providing the identifier of the VNF lifecycle operation occurrence (see clause 7.2.10.3 of [3]).

4) VNFM sends to EM a Notify (see clause 7.3.3 of [3]) carrying a VnfLifecycleChangeNotification information element with attributes vnfInstanceId, lifecycleOperationOccurrenceId, operation = "HealVnf", and status = "start" to indicate the start of the VNF healing execution (see clause 9.5.2.3 [3]).

5) VNFM executes the healing, see clause 7.2.10 of [3].

6) VNFM sends to EM a Notify (see clause 7.3.3 [3]) carrying a VnfLifecycleChangeNotification information element, with attributes vnfInstanceId, lifecycleOperationOccurrenceId, operation = "HealVnf", notificationType = "result" to indicate the end and the result of the VNF healing execution. Depending on the result, additional parameters affectedVnfc, affectedVirtualLink, and affectedVirtualStorage provide information about the VNFC, VL and virtualised storage resources affected during the lifecycle operation (see clauses 9.5.2.3 of [3]).

Annex A (informative):
Change history

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2018-06	SA#80	SP-180417	0001	1	B	Scope extension to cover RAN	15.0.0
2020-07	–	–	–	–	–	Update to Rel-16 version (MCC)	16.0.0
2022-03	–	–	–	–	–	Update to Rel-17 version (MCC)	17.0.0