5 Management service template (stage 2)

32.1603GPPManagement and orchestrationManagement service templateRelease 17TS

5.1 General

5.1.1 General

The present document contains the templates to be used, for the production of all Management Service (MnS) specifications.

Clause 5.2 is applicable for specification of MnS component type B (NRM).

Clause 5.3 is applicable for specification of MnS component type A (operations and notifications) and type C (alarm and performance information).

The MnS template uses qualifiers M, O, CM, CO and C. The semantics of these qualifiers are defined in [3].

The MnS template uses type definition as one characteristic to describe class attributes and operation/notification parameters. The valid type definitions that can be used and their semantics are defined in [3].

Usage of fonts for the specific cases of class/attribute names etc., in addition to the general font requirements in the 3GPP drafting rules in 3GPP TR 21.801 [5], shall be according to the following table.

Table 5.1.1-1

Item	Font
Class names	Courier New
Attribute names	Courier New
Operation names	Courier New
Parameter names	Courier New
Assertion names	Courier New
Notification names	Courier New
Exception names	Courier New
State names	Arial
Matching Information	Courier New
Information Type	Courier New
Legal Values	Courier New
NOTE: These font requirements do not apply to UML diagrams.

5.1.2 Management service components

A management service combines elements of management service components type A, B and C [1].

The template for NRM, see clause 5.2, applies to the specification of management service component type B.

The template for the Management service operations and notifications, see clause 5.3, applies to the specification of type A and type C.

5.2 Template for NRM

W4 Model

W4.1 Imported and associated information entities

W4.1.1 Imported information entities and local labels

This clause identifies a list of information entities (e.g. information object class, datatype, interface, attribute) that have been defined in other specifications and that are imported in the present (target) specification. All imported entities shall be treated as if they are defined locally in the target specification. One usage of import is for inheritance purpose.

Each element of this list is a pair (label reference, local label). The label reference contains the name of the original specification where the information entity is defined, the information entity type and its name. The local label contains the name of the information entity that appears in the target specification, and the entity name in the local label shall be kept identical to the name defined in the original specification. The local label may then be used throughout the target specification instead of that which appears in the label reference.

This information is provided in a table. An example of such a table is given here below:

Label reference	Local label
TS 28.622 [6], information object class, Top	Top
TS 28.541 [7] information object class NSI	NSI

W4.1.2 Associated information entities and local labels

This clause identifies a list of information entities (e.g. information object class, interface, attribute) that have been defined in other specifications and that are associated with the information entities defined in the present (target) specification. For the associated information entity, only its properties (e.g., DN (see TS 32.156 [3]), attribute (see TS 32.156 [3]) of an instance of the associated information entity) used as associated information needs to be supported locally in the target specification.

Each element of this list is a pair (label reference, local label). The label reference contains the name of the original specification where the information entity is defined, the information entity type and its name. The local label contains the name of the information entity that appears in the target specification. The local label may then be used throughout the target specification instead of that which appears in the label reference.

This information is provided in a table. An example of such a table is given here below:

Label reference	Local label
TS 28.541 [7], IOC, GNBDUFunction	GNBDUFunction

W4.2 Class diagram

W4.2.1 Relationships

This first set of diagrams represents all classes and datatypes defined in this MnS with all their relationships, including relationships with imported information entities (if any). These diagrams shall contain class cardinalities (for associations as well as containment relationships) and may also contain role names. These shall be UML compliant class diagrams (see also TS 32.156 [3]).

Characteristics (attributes, relationships) of imported information entities need not to be repeated in the diagrams. Allowable classes are specified in TS 32.156 [3].

Use this as the first paragraph: "This clause depicts the set of classes (e.g. IOCs) that encapsulates the information relevant for this MnS. This clause provides an overview of the relationships between relevant classes in UML. Subsequent clauses provide more detailed specification of various aspects of these classes."

W4.2.2 Inheritance

This second set of diagrams represents the inheritance hierarchy of all classes defined in this specification. These diagrams do not need to contain the complete inheritance hierarchy but shall at least contain the parent classes of all classes defined in the present document. By default, a class inherits from the class "top".

Characteristics (attributes, relationships) of imported classes need not to be repeated in the diagrams.

NOTE: some inheritance relationships presented in clause W4.2.2 may be repeated in clause W4.2.1 to enhance readability.

Use "This subclause depicts the inheritance relationships." as the first paragraph.

W4.3 Class definitions

Each class, with its stereotype name, is defined using the following structure.

Inherited items (attributes etc.) shall not be shown, as they are defined in the parent class(es) and thus valid for the subclass.

W4.3.a ClassName <<StereotypeName>>

StereotypeName is mandatory to be included in the clause header, except for the stereotype Information Object Class, for which it shall not be included in the clause header.

An example of a Class is Subnetwork of stereotype Information Object Class. The heading of sub-clause W4.3.a for SubNetwork would look as follows:

W4.3.a SubNetwork

An example of a Class is SliceProfile of stereotype data type. The heading of W4.3.a for SliceProfile would look as follows:

W4.3.a SliceProfile <<dataType>>

The various stereotypes can be found in TS 32.156 [3].

The "a" represents a number, starting at 1 and increasing by 1 with each new definition of a class.

W4.3.a.1 Definition

This clause is written in natural language. The <definition> clause refers to the class itself.

Optionally, information on traceability back to one or more requirements supported by this class may be defined here, in the following form:

Referenced TS	Requirement label	Comment
TS 28.xyz [xy]	REQ-SM-CON-23	Optional clarification
TS 28.xyz [xy]	REQ-SM-FUN-11	Optional clarification

W4.3.a.2 Attributes

This clause presents the list of attributes, which are the manageable properties of the class. Each attribute is characterised by some of the attribute properties (see TS 32.156 [3]), i.e. supportQualifier (abbreviated by S), isReadable, isWritable, isInvariant and isNotifyable.

The legal values and their semantics for attribute properties are defined in TS 32.156 [3].

This information is provided in a table.

An example below indicates

Attribute name	S	isReadable	isWritable	isInvariant	isNotifyable
eNodeBId	M	T	F	T	T

Another example below indicates that the attribute password1 is not readable, is writable, is not an invariant and no notifyAttributeValueChange will be emitted when the attribute value is changed.

Attribute name	S	isReadable	isWritable	isInvariant	isNotifyable
password1	O	F	T	F	F

Another example below indicates that the attribute password2 and password1 (in example above) have the same qualifiers for the shown properties except that of isReadable. In the case of password1, the standard specification determines the qualifier to be M, i.e. it is readable. In the case of password2, the standard specification does not make a determination. The vendor would make the determination if the attribute is readable or not readable.

Attribute name	S	isReadable	isWritable	isInvariant	isNotifyable
password2	O	O	T	F	F

In case there is one or more attributes related to role (see clause 5.2.9 of TS 32.156 [3]), the attributes related to role shall be specified at the bottom of the table with a divider "Attribute related to role", as shown in the following example:

Attribute name	S	isReadable	isWritable	isInvariant	isNotifyable
aTMChannelTerminationPointid	M	T	F	T	T
…
…
Attribute related to role
theATMPathTerminationPoint	M	T	F	F	T
theIubLink	M	T	F	F	T

This clause shall state "None." when there is no attribute to define.

W4.3.a.3 Attribute constraints

This clause presents constraints for the attributes, and one use is to present the predicates for conditional qualifiers (CM/CO).

This information is provided in a table. An example of such a table is given here below:

Name	Definition
configuredMaxTxPower CM support qualifier	Condition: The sector-carrier has a downlink [4].
sNSSAIList CM support qualifier	Condition: Network slicing feature is supported [4].

This clause shall state "None." when there is no attribute constraint to define.

W4.3.a.4 Notifications

This clause, for this class, presents one of the following options:

a) The class defines (and independent from those inherited) the support of a set of notifications that is identical to that defined in clause W4.5. In such case, use "The common notifications defined in clause W4.5 are valid for this class, without exceptions or additions." as the lone sentence of this clause.

b) The class defines (and independent from those inherited) the support of a set of notifications that is a superset of that defined in clause W4.5. In such case, use "The common notifications defined in clause W4.5 are valid for this IOC. In addition, the following set of notification is also valid." as the lone paragraph of this clause. Then, define the ‘additional’ notifications in a table. See clause W4.5 for the notification table format.

c) The class defines (and independent from those inherited) the support of a set of notifications that is not identical to, nor a superset of, that defined in clause W4.5. In such case, use "The common notifications defined in clause W4.5 are not valid for this IOC. The set of notifications defined in the following table is valid." as the lone paragraph of this clause. Specify the set of notifications in a table. See clause W4.5 for the notification table format.

d) The class does not define (and independent from those inherited) the support of any notification. In such case, use "There is no notification defined." as the lone sentence of this clause.

The notifications identified (i.e. option-a, option-b and option-c above) in this clause are notifications that may be emitted by the MnS producer, where the "object class" and "object instance" parameters of the notification header (see note 2) of these notifications identifies an instance of the class (or its direct or indirect derived class) defined by the encapsulating clause (i.e. clause W4.3.a).

The notifications identified (i.e. option-a and option-b above) in this clause, may originate from implementation object(s) whose identifier may or may not be the same as that carried in the notification parameters "object class" and "object instance". Hence the identification of notifications in this clause does not imply nor identify those notifications as being originated from an instance of the class (or its direct or indirect derived class) defined by the encapsulating clause (i.e. clause W4.3.a).

This clause shall state "This class does not support any notification." (see option-c) when there is no notification defined for this class. (Note that if its parent class has defined some notifications, the implementation of this class is capable of emitting those inherited defined notifications.)

The notification header is defined in TS 32.302 [8].

The qualifier of a notification, specified in Notification Table, indicates if an implementation may generate a notification carrying the DN of the subject class. The qualifier of a notification, specified in an MnS producer interface, indicates if an implementation of the MnS may generate such notification in general.

An MnS consumer may receive notification-XYZ that carries DN (the "object class" and "object instance") of class-ABC instance if and only if:

a) The class-ABC Notification Table defines the notification-XYZ and

b) The class-ABC instance implementation supports this notification-XYZ and

c) An MnS defines the notification-XYZ and

d) The MnS implementation supports this notification-XYZ.

W4.3.a.5 State diagram

This subclause contains state diagrams. A state diagram of an information object class defines permitted states of this information object class and the transitions between those states. A state is expressed in terms of individual attribute values or a combination of attribute values or involvement in relationships of the information object class being defined. This shall be a UML compliant state diagram.

This subclause shall state "None." when there is no State diagram defined.

W4.5 Attribute definitions

W4.5.1 Attribute properties

It has a lone paragraph "The following table defines the properties of attributes that are specified in the present document. ".

Each information attribute is defined using the following structure.

Inherited attributes shall not be shown, as they are defined in the parent class(es) and thus valid for this class.

An attribute has properties (see TS 32.156 [3]). Some properties of an attribute are defined in W4.3.a.2 (e.g. Support Qualifier). The remaining properties of an attribute (e.g. documentation, default value) are defined here.

The information is provided in a table. In case a) attributes of the same name are specified in more than one class and b) the attributes have different properties, then the attribute names (first column) should be prefixed with the class name followed by a period.

An example is given below:

Attribute Name	Documentation and Allowed Values	Properties
xyzId	It identifies … allowedValues: …	type: Integer multiplicity: … isOrdered: … isUnique: … defaultValue: … isNullable: False
Abc.state	It indicates … allowedValues: "ON": the state is on; "OFF": the state is off.	type: <<enumeration>> multiplicity: 1 isOrdered: N/A isUnique: N/A defaultValue: False isNullable: False
Zyz.state	It indicates … allowedValues: "HIGH": the state is high; "MEDIUM": the state is medium; "LOW": the state is low.	type: <<enumeration>> multiplicity: 1 isOrdered: N/A isUnique: N/A defaultValue: False isNullable: False
abc	It defines… allowedValues: …	type: … multiplicity: … isOrdered: … isUnique: … defaultValue: … isNullable: …

In case there is one or more attributes related to role (see clause 5.2.9 of TS 32.156 [3]), the attributes related to role shall be specified at the bottom of the table with a divider "Attribute related to role". See example below.

Attribute Name	Documentation and Allowed Values	Properties
abc	It defines… allowedValues: …	type: PlmnId multiplicity: … isOrdered: … isUnique: … defaultValue: … isNullable: …
Attribute related to role
aEnd	It defines… allowedValues: Values to be conformant to TS 32.300 [9] …	type: DN multiplicity: … isOrdered: … isUnique: … defaultValue: … isNullable: False

This clause shall state "None." if there is no attribute to define.

W4.5.2 Constraints

This clause indicates whether there are any constraints affecting attributes. Each constraint is defined by a triplet (propertyName, affectedAttributes, propertyDefinition). PropertyDefinitions are expressed in natural language.

An example is given here below:

Name	Affected attribute(s)	Definition
inv_TimerConstraints	ntfTimeTickTimer	The ntfTimeTickTimer is lower than or equal to ntfTimeTick.

This clause shall state "None." if there is no constraint.

W4.6 Common notifications

This clause presents notifications that may be referred to by any class defined in the specification. This information is provided in tables.

W4.6.1 Alarm notifications

The following quoted text shall be copied as the only paragraph of this clause.

"This clause presents a list of notifications, defined in TS 28.532 [12], that an MnS consumer may receive. The notification header attribute objectClass/objectInstance, defined in TS 28.541 [7], shall capture the DN of an instance of a class defined in the present document."

The information is provided in a table. The following is an example.

Name	S	Notes
notifyNewAlarm	M	—

W4.6.2 Configuration notifications

The following quoted text shall be copied as the only paragraph of this clause.

"This clause presents a list of notifications, defined in TS 28.532 [12], that an MnS consumer may receive. The notification header attribute objectClass/objectInstance, defined in TS 32.302 [8], shall capture the DN of an instance of a class defined in the present document."

The information is provided in a table. The following is an example.

Name	S	Notes
notifyMOIAttributeValueChange	O	—
notifyMOICreation	O	—
notifyMOIDeletion	O	—

W4.6.3 Threshold Crossing notifications

The following quoted text shall be copied as the only paragraph of this clause.

"This clause presents a list of notifications, defined in TS 28.532 [12], that an MnS consumer may receive. The notification header attribute objectClass/objectInstance, defined in TS 28.541 [7], shall capture the DN of an instance of a class defined in the present document."

The information is provided in a table. The following is an example.

Name	S	Notes
notifyThresholdCrossing	O

5.3 Template for Management service operations and notifications

Y4 Overview

Yb Management service name

Management service name should be replaced with the name of the Management Service (MnS).

"b" represents a number, starting at 1 and increasing by 1 with each new definition of a Management Service.

Yb.1 Operations and notifications

Yb.1.a Operation OperationName

OperationName is the name of the operation followed by a qualifier indicating whether the operation is Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C).

"a" represents a number, starting at 1 and increasing by 1 with each new definition of an operation.

Yb.1.a.1 Definition

Yb.1.a.1.1 Description

This subclause shall be written in natural language.

Information on traceability back to one or more requirements supported by this operation should also be defined here, in the following form:

Referenced TS	Requirement label	Comment
3GPP TS 32.xyz [xy]	REQ-SM-CON-23	Optional clarification
3GPP TS 32.xyz [xy]	REQ-SM-FUN-11	Optional clarification

Yb.1.a.1.2 Pre-condition

A pre-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The pre-condition shall be true before the operation is invoked. An example is given here below:

notificationCategoriesNotAllSubscribed OR notificationCategoriesParameterAbsentAndNotAllSubscribed

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the pre-condition are provided in a table. An example of such a table is given here below:

Assertion Name	Definition
notificationCategoriesNotAllSubscribed	At least one notificationCategory identified in the notificationCategories input parameter is supported by an MnS producer and is not a member of the ntfNotificationCategorySet attribute of an NtfSubscription which is involved in a subscription relationship with the NtfSubscriber identified by the managerReference input parameter.
notificationCategoriesParameterAbsentAndNotAllSubscribed	The notificationCategories input parameter is absent and at least one notificationCategory supported by MnS producer is not a member of the ntfNotificationCategorySet attribute of an ntfSsubscription which is involved in a subscription relationship with the NtfSubscriber identified by the managerReference input parameter.

Yb.1.a.1.3 Post-condition

A post-condition is a collection of assertions joined by AND, OR, and NOT logical operators. The post-condition shall be true after the completion of the operation. When nothing is said in a post-condition regarding an information entity, the assumption is that this information entity has not changed compared to what is stated in the
pre-condition. An example is given here below:

subscriptionDeleted OR allSubscriptionDeleted

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the post-condition shall be provided in a table. An example of such a table is given here below:

Assertion Name	Definition
subscriptionDeleted	The ntfSubscription identified by subscriptionId input parameter is no more involved in a subscription relationship with the ntfSubscriber identified by the managerReference input parameter and has been deleted. If this ntfSubscriber has no more ntfSubscription, it is deleted as well.
allSubscriptionDeleted	In the case subscriptionId input parameter was absent, the ntfSubscriber identified by the managerReference input parameter is no more involved in any subscription relationship and is deleted, the corresponding ntfSubscription have been deleted as well.

Yb.1.a.1.4 Exceptions

List of exceptions that can be raised by the operation. Each element shall be a tuple (exceptionName, condition, ReturnedInformation, exitState).

Yb.1.a.1.4.c exceptionName

ExceptionName is the name of an exception.

"c" represents a number, starting at 1 and increasing by 1 with each new definition of an exception.

This information shall be provided in a table. An example of such a table is given here below:

Exception Name	Definition
ope_failed_existing_subscription	Condition: (notificationCategoriesNotAllSubscribed OR notificationCategoriesParameterAbsentAndNotAllSubscribed) not verified. Returned information: output parameter status is set to OperationFailedExistingSubscription. Exit state: Entry State.

NOTE: An example of an exception can be a situation where an operation is raised and the required information between a consumer and producer cannot be conveyed via the input and output parameters.

Yb.1.a.2 Input parameters

List of input parameters of the operation. Each element shall be a tuple (Parameter Name, Support Qualifier, Information Type (see [10] and note 1) and an optional list of Legal Values supported by the parameter, Comment). Legal Values for the Support Qualifier are: Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C).

This information shall be provided in a table. An example of such a table is given here below:

Parameter Name	S	Information Type / Legal Values	Comment
eventIdList	M	SET OF INTEGER / —	One or more event identifiers

NOTE: Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics applies to several values in which case the definition can be provided only once. When the Legal Values cannot be enumerated, the list of Legal Values is defined by a single definition.

Yb.1.a.3 Output parameters

List of output parameters of the operation. Each element tuple (Parameter Name, Support Qualifier, Matching Information / Information Type (see [10]) (Note 1) and an optional list of Legal Values supported by the parameter, Comment). Legal Values for the Support Qualifier are: Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C).

This information shall be provided in a table. An example of such a table is given here below:

Parameter Name	S	Matching Information / Information Type / Legal Values	Comment
eventTime	M	AlarmInformation.alarmRaisedTime / GeneralizedTime / —	The parameter carries the alarmRaisedTime in case notificationType carries notifyNewAlarm, alarmChangedTime in case notificationType carries notifyChangedAlarm, alarmClearedTime in case notificationType carries notifyClearedAlarm.

NOTE: Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics applies to several values in which case the definition can be provided only once. When the Legal Values cannot be enumerated, the list of Legal Values is defined by a single definition.

This table shall also include a special parameter ’status’ to indicate the completion status of the operation (success, partial success, failure reason etc.).

Yb.1.a.4 Result

Yb.1.a.4,1 Error messages

This subclause presents error messages in case the operation is not successful.

This subclause does not need to be present when there are no error messages to define.

Yb.1.a.4,2 Constraints

This subclause presents constraints for the operation or its parameters.

This subclause does not need to be present when there are no constraints to define.

Yb.1.a Notification NotificationName

NotificationName shall be the name of the notification followed by a qualifier indicating whether the notification is Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO) or SS-Conditional (C).

"a" represents a number, starting at 1 and increasing by 1 with each new definition of a notification.

Yb.1.a.1 Definition

This subclause shall be written in natural language.

Information on traceability back to one or more requirements supported by this notification should also be defined here, in the following form:

Referenced TS	Requirement label	Comment
3GPP TS 32.xyz [xy]	REQ-SM-CON-23	Optional clarification
3GPP TS 32.xyz [xy]	REQ-SM-FUN-11	Optional clarification

Yb.1.a.2 Input parameters

List of input parameters of the notification. Each element is a tuple (Parameter Name, Qualifiers, Matching Information / Information Type (see [10]) (Note 1) and an optional list of Legal Values supported by the parameter, Comment).

The column "Qualifiers" contains the two qualifiers, Support Qualifier and Filtering Qualifier, separated by a comma. The Support Qualifier indicates whether the attribute is Mandatory (M), Optional (O), Conditional-Mandatory (CM), Conditional-Optional (CO), or SS-Conditional (C).

This information shall be provided in a table. An example of such a table is given here below:

Parameter Name	S	Matching Information / Information Type / Legal Values	Comment
managerReference	M	ntfSubscriber.ntfManagerReference / STRING / —	It specifies the reference of the consumer to which notifications shall be sent.
alarmType	M	AlarmInformation.eventType / ENUMERATED / "Communications Alarm": a communication error alarm. "Processing Error Alarm": a processing error alarm. "Environmental Alarm": an environmental violation alarm. "Quality Of Service Alarm": a quality of service violation alarm. "Equipment Alarm": an alarm related to equipment malfunction.

NOTE: Information Type qualifies the parameter of Parameter Name. In the case where the Legal Values can be enumerated, each element is a pair (Legal Value Name, Legal Value Semantics), unless a Legal Value Semantics applies to several values in which case the definition can be provided only once. When the Legal Values cannot be enumerated, the list of Legal Values is defined by a single definition.

Yb.1.a.3 Triggering event

The triggering event for the notification to be sent is the transition from the information state defined by the "from state" subclause to the information state defined by the "to state" subclause.

Yb.1.a.3.1 From state

This subclause is a collection of assertions joined by AND, OR, and NOT logical operators. An example is given here below:

alarmMatched AND alarmInformationNotCleared

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the state "from state" are provided in a table. An example of such a table is given here below:

Assertion Name	Definition
alarmMatched	The matching-criteria-attributes of the newly generated network alarm has values that are identical (matches) with ones in one AlarmInformation in AlarmList.
alarmInformationNotCleared	The perceivedSeverity of the newly generated network alarm is not Cleared.

Yb.1.a.3.2 To state

This subclause contains a collection of assertions joined by AND, OR and NOT logical operators. When nothing is said in a to-state regarding an information entity, the assumption is that this information entity has not changed compared to what is stated in the from-state. An example is given here below:

resetAcknowledgementInformation AND perceivedSeverityUpdated

Each assertion is defined by a pair (propertyName, propertyDefinition). All assertions constituting the state "to state" are provided in a table. An example of such a table is given here below:

Assertion Name	Definition
resetAcknowledgementInformation	The matched AlarmInformation identified in inv_alarmMatched in pre-condition has been updated according to the following rule: ackTime, ackUserId and ackSystemId are updated to contain no information; ackState is updated to "unacknowledged".
perceivedSeverityUpdated	The perceivedSeverity attribute of matched AlarmInformation identified in inv_alarmMatched in pre-condition has been updated.

Yb.2 Managed information