4 NGCOR Fault Management Solution Profile

28.3903GPPFixed Mobile Convergence (FMC)Interface Integration Reference Point (IRP) Solution Profiles (SPs)Release 17Telecommunication managementTS

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

4.1 Requirement statements

These requirement statements, pertaining to fault management, are extracted from [2]. The REQ-GEN (1..22) statements are from section 2 of [2]. The REQ-FM (1..8) statements are from section 5 of [2].

REQ-GEN (1..22)

REQ-GEN (1) “Plug & Play”

It must be possible to implement the interfaces between the OSS easy and efficient by lowest costs and smallest effort (ideally without any development and/or configuration). The standard specification must enable “Plug&Play” (e.g. by unambiguously defined interface capabilities). Priority: Major

REQ-GEN (2) Useful

It must deliver efficient support for the OSS business processes. The standard specification interface must deliver the needed OSS semantics to support the process. Priority: Major

REQ-GEN (3) Re-Useable/ Generic

The standard interface specification must be generic enough, to enable the re-use in different integration scenarios. Priority: Essential

REQ-GEN (4) Simple

The standard interface specification must be simple (that means: the interface should offer only really necessary capabilities), so that people which have not been involved in the specification are able to understand it (or even do not need to understand the details), so that they are able to implement, maintain and use the interface. Priority: Essential

REQ-GEN (5) Flexible/ Extendible

The interface can be extended and refined, from basic setup to more complex implementations without impact on the other communication partners. It must be possible to extend the interface capabilities (methods and attributes), without breaking the standard. The standard interface specification must enable this. Priority: Major

REQ-GEN (6) Fine grained (as far as needed)

Means: Focus on using valid Use case to motivate the interface design. In such case, the standard Interface specification will be of the correct grade of grain. Fine grained functionality ONLY where really needed and absolutely necessary to support the common basic process. Adding more and more capabilities into the standard interface specification will lead to complex and expensive implementations (which often hinders the adoption of the interface) and might lead to a dilution of the scope of the interface and overlapping functionality with other interfaces. Priority: Major

REQ-GEN (7) Standardized/ Open

The requirement means, that we need an “unambiguously standardized specification” without room for interpretation (which usually hinders Plug & Play, s.o.). This standard can be an existing specification or a new one. NGMN-NGCOR will not specify any standard. The specification and everything needed to make use of the standard (e.g. appendixes to the specification-document which are not part of the document itself, etc.) must be freely available and useable for everyone. Priority: Essential

REQ-GEN (8) Mature/ Stable

The standard interface specification must be stable and mature, to avoid expensive changes on implemented interfaces. Changes in the application or in the interface implementation at one of the communication partners may not lead to the need for changes in the application or in the interface implementation of the other communication partners. (Please consider that this requirement does not assume any specific type of implementation technology.) The standard interface specification must enable this capability. Priority: Major

REQ-GEN (9)

Changes in the application or in the interface implementation at one of the communication partners may not lead to the need for changes in the application or in the interface implementation of the other communication partners. (Please consider that this requirement does not assume any specific type of implementation technology.) Priority: Essential

REQ-GEN (10) Evolutionary

OSS standard interface specification shall re-use already existing, widely adopted and mature IT standards (e.g. transport protocols) to avoid “reinventing the wheel”. The interface standard specification must be independent from underlying infrastructure. The standard must be agnostic to the implementation-platform (e.g. the standard may not rely on capabilities of a specific Operating System). Priority: Essential

REQ-GEN (11)

The interface standard specification must be independent from underlying infrastructure. The standard must be agnostic to the implementation-platform (e.g. the standard may not rely on capabilities of a specific Operating System). Priority: Essential

REQ-GEN (12) Certifiable

The Interface must be specified in a way that makes it technically possible to validate an implementation compliancy. Beside of that, the standard should include a mechanism to certify the standard compliancy of the interface implementation. Priority: Major

REQ-GEN (13) Compatible

It must be possible to implement a new version of an interface specification at one of the communication partners while the other communication partners still use an old version of the interface specification. This “mixed versions” of interface implementations can be used without any impact on the communication partners or the interface implementations of the communication partners. The standard interface specification must enable this capability. Priority: Essential

REQ-GEN (14) Interoperable

The interface implementation shall be based on an interoperable portfolio of standard interfaces/ interface specifications to support different dynamic and configurable OSS business workflow and processes using a common architecture and a common information model. The standard must enable this by delivering the standard portfolio of interfaces and interface specifications. Priority: Major

REQ-GEN (15) Scalable

The standard interface specification must be able to be enlarged to accommodate a growth of traffic. Priority: Essential

REQ-GEN (16) Secure

The standard interface specification has to be able to ensure confidentiality, integrity and availability of the data, which is transferred by the interface. Priority: Minor

REQ-GEN (17) Reliable

The interface implementation has to ensure the reliability of the data, which is transferred by the interface. The standard interface specification must enable this capability. Priority: Essential

REQ-GEN (18) Interface Robustness

No interface dependencies on availability between NMS and EMS if one of the EMSs (Server) communication partners is not available. The standard interface specification must enable this capability. Priority: Essential

REQ-GEN (19) Simple Trace and Logging

The standard interface specification must deliver a simple “trace and logging” functionality (in readable text format). Priority: Essential

REQ-GEN (20) 1:1 Relation between Event MO Instances and Inventory MO Instances

Priority: Major

REQ-GEN (21) “MO Instance” Attribute Information Structure for EMS NMS Event Interfaces

Priority: Major

REQ-GEN (22) M : N Connectivity

Multiple EMS applications might be connected (logically) to multiple NMS applications (M : N). Priority: Major

REQ-FM (1) X.733 Event/Alarm Attributes

The event/alarm must contain structured information according to the X.733 specification. Priority: Essential

REQ-FM (2) Event/Alarm Transport

It must be possible to send (Server) [and receive/listen to (Client) event/alarms]. See also REQ-FM (9), Priority: Essential

REQ-FM (3) Clear – Event/Alarm Transport

It must be possible to send [and receive/listen to] “clear” – event/alarm events. Priority: Essential

REQ-FM (4) Unambiguous ID

It must be possible to correlate between clear–event/alarm and the original event/alarm, by using an unambiguous ID. Priority: Essential

REQ-FM (5) Event/Alarm Query

Priority: Essential

REQ-FM (6) Heartbeat

The interface has to support a heartbeat capability which allows EMS to send heartbeats (configurable) and NMS to receive/listen to heartbeats. Priority: Essential

REQ-FM (7) Supplementary Information contained within alarm

The interface has to provide all information required for correlation. Priority: Essential

REQ-FM (8) Co-operative alarm acknowledgement (OPTIONAL)

The interface shall support a co-operative alarm-acknowledgement function as described in 3GPP TS 32.111-1 (Optional feature). Priority: Minor

REQ-FM (9) Reliable Event/Alarm Communication (supported by EMS)

– EMS buffers event/alarms if they cannot be sent to the NMS

– EMS sends event/alarms immediately as soon as the connectivity to the NMS is up again

Priority: Essential

REQ-FM (10) Configurable EMS Heartbeat Message

EMS will send heartbeats in regular (configurable) intervals to NMS. Priority: Essential

REQ-FM (11) Alarm Suppression

The EMS – NMS – Fault Management interface should enable the alarm suppression. Priority: Major

REQ-FM (12) Summary Alarms

EMS interface summary should provide summary alarm functionality. Priority: Major

REQ-FM (13) Re-Synchronization

The NMS must be able to synchronize the own event/alarm list with the EMS event/alarm lists. Priority: Essential

4.2 System context

The general definition of “System Context” can be found in 3GPP TS 32.150 [1] subclause 4.7.

The set of related IRP(s) relevant to this SP is shown in the following diagram.

Figure 4.2-1: System Context

4.3 SP

This section specifies the Fault Management SP for NGCOR. Specifically, this SP identifies the necessary and sufficient subset of the IRP Interface operations that can satisfy the fault management requirements stated in [2]. The SP is presented in the Table below.

The column labels identify the fault management specific and the general requirements stated in [2], presented by column labels as REQ-FM(..) and REQ-GEN(..). The row labels identify the various IRP Interface operations. An empty cell means that the related operation does not support the related requirement. A cell marked has the following meanings.

– X: The related operation supports the related requirement;

– A: The related operation supports the related requirement. REQ-FM (1) requires the use of ITU-T X.733 defined structured information. Current IRP solution supports the use of all X.733 defined Probable Causes. Current IRP solution supports a subset of X.733 defined Event Type. Enhancement of current IRP may need to be considered.

– B: the related operation supports the related requirement. REQ-FM (5) requires a ‘query’ type of service for both alarms and events. Current IRP supports a ‘query’ type service for alarms (e.g. result of a query is carried by the response of the query request). The current IRP supports an export facility with filtering capability for events (e.g. result of an query is carried in a file and not in the response of the query request).

– C: The related operation supports the related requirement. REQ-FM (12) requires support of Toggle and Transient Rule of activateAAMRule (..) only.

– *: Some requirements are stated in a general form (e.g. “REQ-GEN (2) Useful”) and are related to the design principle of the protocol and implementation. They are not related to any particular operation(s) or notification(s); nevertheless these IRPs in general support those requirements. Their requirement column headings are marked with a ‘*’ (e.g. “REQ-FM(9)”).

Table 4.3-1: NGCOR FM SP

REQ-FM (..)

REQ-GEN (..)

1-18*

20-22*

Alarm IRP [3]

acknowledgeAlarms

getAlarmList

notifyNewAlarm

notifyAckStateChanged

notifyChangedAlarm

notifyClearedAlarm

notifyAlarmListRebuilt

AAM IRP [7]

activateAAMRule

deactivateAAMRule

getAAMRules

Notification IRP [4]

unsubscribe

CS IRP [5]

setHeartbeatPeriod

triggerHeartbeat

notifyHeartbeat

NL IRP [6]

subscribeLog

unsubscribeLog

exportLogRecords

Annex A (informative):
Change history

Change history
Date	TSG #	TSG Doc.	CR	Rev	Subject/Comment	Old	New
2013-06	SA#60	SP-130280			Presented to SA Plenary for approval	1.1.1	2.0.0
2013-06					Upgrade of approved version	2.0.0	12.0.0
2014-12	SA#66	SP-140798	001	1	Remove feature support statement	12.0.0	12.1.0
2016-01	–	–	–	–	Update to Rel-13 version (MCC)	12.1.0	13.0.0
2017-03	SA#75	–	–	–	Promotion to Release 14 without technical change	13.0.0	14.0.0
2018-06	–	–	–	–	Update to Rel-15 version (MCC)	14.0.0	15.0.0
2020-07	–	–	–	–	Update to Rel-16 version (MCC)	15.0.0	16.0.0
2022-03	–	–	–	–	Update to Rel-17 version (MCC)	16.0.0	17.0.0