4.3 Class definitions
28.6223GPPGeneric Network Resource Model (NRM) Integration Reference Point (IRP)Information Service (IS)Release 18Telecommunication managementTS
4.3.1 Any
4.3.1.1 Definition
This class represents the classes (e.g. IOC) that are not defined in this specification but are or will be defined in other IRP specification(s).
4.3.1.2 Attributes
None
4.3.1.3 Attribute constraints
None
4.3.1.4 Notifications
This class does not support any notification.
4.3.2 IRPAgent
4.3.2.1 Definition
This IOC represents the functionality of an IRPAgent. It shall be present. For a definition of IRPAgent, see 3GPP TS 32.102 [2].
The IRPAgent will be contained under an IOC as follows (only one of the options shall be used):
1) ManagementNode, if the configuration contains a ManagementNode;
2) SubNetwork, if the configuration contains a SubNetwork and no ManagementNode;
3) ManagedElement, if the configuration contains no ManagementNode or SubNetwork.
The IRPAgent shall be used only in deployments using the IRP framework as defined in TS 32.102 [2]. The MnsAgent shall not be used in these deployments.
4.3.2.2 Attributes
The IRPAgent IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
systemDN |
M |
T |
F |
F |
T |
4.3.2.3 Attribute constraints
None
4.3.2.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.2a MnsAgent
4.3.2a.1 Definition
The MnsAgent represents the MnS producers, incl. the supporting hardware and software, available for a certain management scope that is related to the object name-containing the MnS Agent.
The MnSAgent can be name-contained under an IOC as follows:
1) ManagementNode;
2) SubNetwork, if the SubNetwork does not contain a ManagementNode;
3) ManagedElement, if it is the root element.
In case the MnsAgent is name-contained under a ManagementNode, the management scope is the complete management scope of the ManagementNode or a subset thereof.
In case the MnsAgent is name-contained under a SubNetwork, the management scope is the complete SubNetwork or a subset thereof.
In case the MnsAgent is name-contained under a ManagedElement, the management scope is the complete ManagedElement or a subset thereof.
The MnsAgent shall be used only in deployments using the Service Based Management Architecture (SBMA) as defined in TS 28.533 [32]. The IRPAgent shall not be used in these deployments.
4.3.2a.2 Attributes
The MnSAgent IOC includes the attributes inherited from Top_ IOC (defined in TS 28.620 [9]), attributes inherited from Top IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
systemDN |
M |
T |
F |
F |
T |
4.3.2a.3 Attribute constraints
None.
4.3.2a.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.3 ManagedElement
4.3.3.1 Definition
This IOC represents telecommunications equipment or TMN entities within the telecommunications network providing support and/or service to the subscriber.
A ManagedElement IOC is used to represent a Network Element defined in TS 32.101[1] including virtualization or non-virtualization scenario. ManagementElement instance is used for communicating with a manager (directly or indirectly) over one or more management interfaces for the purpose of being monitored and/or controlled. ManagedElement may or may not additionally perform element management functionality. A ManagedElement contains equipment that may or may not be geographically distributed.
A telecommunication equipment has software and hardware components. The ManagedElement IOC described above represents the following two cases:
– In the case when the software component is designed to run on dedicated hardware component, the ManagedElement IOC description includes both software and hardware component.
– In the case when the software is designed to run on ETSI NFV defined NFVI [15], the ManagedElement IOC description would exclude the NFVI component supporting the above mentioned subject software.
A ManagedElement may be contained in either a SubNetwork or in a MeContext instance. A ManagedElement may also exist stand-alone with no parent at all.
The relation of ManagedElement IOC and ManagedFunction IOC can be described as following:
– A ManagedElement instance may have 1..1 containment relationship to a ManagedFunction instance. In this case, the ManagedElement IOC may be used to represent a NE with single ManagedFunction functionality. For example, a ManagedElement is used to represent the 3GPP defined RNC node.
– A ManagedElement instances may have 1..N containment relationship to multiple ManagedFunction IOC instances. In this case, the ManagedElement IOC may be used to represent a NE with combined ManagedFunction functionality (as indicated by the managedElementType attribute and the contained instances of different ManagedFunction IOCs). For example, a ManagedElement is used to represent the combined functionality of 3GPP defined gNBCUCPFunction, gNBCUUPFunction and gNBDUFunction.
NOTE: For some specific functional IOCs a 1..N containment relationship is permitted. The specific functional entities are identified in the NRMs that define subclasses of ManagedFunction.
4.3.3.2 Attributes
The ManagedElement IOC includes the attributes inherited from ManagedElement_ IOC (defined in TS 28.620 [9]), attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
vendorName |
M |
T |
F |
F |
T |
|
userDefinedState |
M |
T |
T |
F |
T |
|
swVersion |
M |
T |
F |
F |
T |
|
priorityLabel |
O |
T |
T |
F |
T |
|
supportedPerfMetricGroups |
O |
T |
F |
F |
T |
|
supportedTraceMetrics |
O |
T |
F |
F |
T |
4.3.3.3 Attribute constraints
Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of ManagedElement is the local root instance of the MIB. Otherwise the attribute shall be absent or carry no information.
4.3.3.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyFileReady |
M |
— |
|
notifyFilePreparationError |
M |
— |
|
notifyDownloadNESwStatusChanged |
M |
— |
|
notifyInstallNESwStatusChanged |
O |
— |
|
notifyActivateNESwStatusChanged |
M |
— |
4.3.4 ManagedFunction
4.3.4.1 Definition
This IOC is provided for sub-classing only. It provides attribute(s) that are common to functional IOCs. Note that a ManagedElement may contain several managed functions, a managed function may contain other managed functions as specified for the specific subclass.. The ManagedFunction may be extended in the future if more common characteristics to functional objects are identified.
This IOC can represent a telecommunication function either realized by software running on dedicated hardware or realized by software running on NFVI. Each ManagedFunction instance communicates with a manager (directly or indirectly) over one or more management interfaces exposed via its containing ME instance.
4.3.4.2 Attributes
The ManagedFunction IOC includes the attributes inherited from Function_ IOC (defined in TS 28.620 [9]), attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
vnfParametersList |
CM |
T |
T |
F |
T |
|
peeParametersList |
CM |
T |
T |
F |
T |
|
priorityLabel |
O |
T |
T |
F |
T |
|
supportedPerfMetricGroups |
O |
T |
F |
F |
T |
|
supportedTraceMetrics |
O |
T |
F |
F |
T |
4.3.4.3 Attribute constraints
|
Name |
Definition |
|
vnfParametersList Support Qualifier |
Condition: The ManagedFunction instance is realized by one or more VNF instance(s). Otherwise this attribute shall be absent. |
|
peeParametersList Support Qualifier |
Condition: The control and monitoring of PEE parameters is supported by the ManagedFunction or sub-class instance. |
4.3.4.4 Notifications
There is no notification defined.
4.3.5 ManagementNode
4.3.5.1 Definition
This IOC represents a telecommunications management system (EM) within the TMN that contains functionality for managing a number of ManagedElements (MEs). The management system communicates with the MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these MEs.
This class has similar characteristics as the ManagedElement. The main difference between these two classes is that the ManagementNode has a special association to the managed elements that it is responsible for managing.
4.3.5.2 Attributes
The ManagementNode IOC includes the attributes inherited from ManagementSystem_ IOC (defined in TS 28.620 [9]), attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
vendorName |
M |
T |
F |
F |
T |
|
userDefinedState |
M |
T |
T |
F |
T |
|
locationName |
M |
T |
F |
F |
T |
|
swVersion |
M |
T |
F |
F |
T |
4.3.5.3 Attribute constraints
None
4.3.5.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyFileReady |
M |
— |
|
notifyFilePreparationError |
M |
— |
4.3.6 MeContext
4.3.6.1 Definition
This IOC is introduced for naming purposes. It may support creation of unique DNs in scenarios when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured.
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same SubNetwork instance, some measure shall be taken in order to assure the global uniqueness of DNs for all IOC instances under those MEs. One way could be to set different dnPrefix for those NEs, but that would require either that:
a) all LDNs or DNs are locally modified using the new dnPrefix for the upper portion of the DNs, or
b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm notifications.
As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using MeContext as part of the naming tree (and thus the DN) means that the dnPrefix, including a unique MeContext for each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to new values.
MeContext have 0..N instances. It may exist even if no SubNetwork exists. Every instance of MeContext contains exactly one ManagedElement during steady-state operations.
4.3.6.2 Attributes
The MeContext IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
dnPrefix |
CM |
T |
F |
F |
T |
4.3.6.3 Attribute constraints
|
Name |
Definition |
|
dnPrefix Support Qualifier |
Condition: The instance of MeContext is the local root instance of the MIB. Otherwise the attribute shall be absent or carry no information. |
4.3.6.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.7 SubNetwork
4.3.7.1 Definition
This IOC represents a set of managed entities. There may be zero or more instances of a SubNetwork. It shall be present if either a ManagementNode or multiple ManagedElements are present (i.e. ManagementNode and multiple ManagedElement instances shall have SubNetwork as parent).
The SubNetwork instance not contained in any other instance of SubNetwork is referred to as the "root" SubNetwork instance.
4.3.7.2 Attributes
The SubNetwork IOC includes the attributes inherited from Domain_ IOC (defined in TS 28.620 [9]), attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
setOfMcc |
CM |
T |
F |
F |
T |
|
priorityLabel |
O |
T |
T |
F |
T |
|
supportedPerfMetricGroups |
O |
T |
F |
F |
T |
|
supportedTraceMetrics |
O |
T |
F |
F |
T |
4.3.7.3 Attribute constraints
|
Name |
Definition |
|
dnPrefix (inherited from Domain_) Support Qualifier |
Condition: The instance of SubNetwork is the local root instance of the MIB. Otherwise the attribute shall be absent or carry no information. |
|
setOfMcc Support Qualifier |
Condition: There is more than one value in setOfMcc of the SubNetwork ; otherwise the support is optional. |
4.3.7.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions
4.3.8 TopX
4.3.8.1 Definition
This IOC is provided for sub-classing only. All information object classes defined in all TS that claim to be conformant to 32.102 [2] shall inherit from TopX.
4.3.8.2 Attributes
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
objectClass |
M |
T |
T |
T |
T |
|
objectInstance |
M |
T |
T |
T |
T |
4.3.8.3 Attribute constraints
None
4.3.8.4 Notifications
There is no notification defined.
4.3.9 VsDataContainer
4.3.9.1 Definition
The VsDataContainer is a container for vendor specific data. The VsDataContainer is contained by Top and hence optionally name-contained by ech IOC.
4.3.9.2 Attributes
The VsDataContainer IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
vsDataType |
M |
T |
F |
F |
O |
|
vsData |
M |
T |
O |
F |
O |
|
vsDataFormatVersion |
M |
T |
F |
F |
O |
4.3.9.3 Attribute constraints
None
4.3.9.4 Notifications
Support for notification on the change of attribute value is vendor-specific.
4.3.10 Link
4.3.10.1 Definition
This IOC is provided for sub-classing only. This IOC represents a communication link or reference point between two network entities. The Link IOC does not indicate whether the represented communication link or reference point is a physical or logical entity.
For the subclasses of Link, the following rules apply:
1) The subclass names shall have the form “Link_<X>_<Y>”, where <X> is a string that represents the IOC at one end of the association related to the particular Link subclass, and <Y> is a string that represents the IOC at the other end of the association. For the order of the two strings, <X> shall come alphabetically before <Y>.
2) In case <X> and <Y> are YyyFunction IOCs (inheriting from ManagedFunction and on first level below ManagedElement), the <X> and <Y> strings shall have the same form as the legal values of the managedElementType attribute (see clause 4.5.1), e.g. “Auc”. Otherwise <X> and <Y> shall be the full IOC names.
Thus, two valid examples of Link subclass names would be: Link_As_Cscf and Link_Mrfc_Mrfp.
4.3.10.2 Attributes
The Link IOC includes the attributes inherited from TopologicalLink_ (defined in TS 28.620 [9]), attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
userLabel |
M |
T |
T |
F |
T |
|
linkType |
O |
T |
F |
F |
T |
|
protocolVersion |
O |
T |
F |
F |
T |
4.3.10.3 Attribute constraints
|
Name |
Definition |
|
aEnd and zEnd (inherited from TopologicalLink_) Support Qualifier |
Condition: The property multiplicity is 1. |
4.3.10.4 Notifications
The common notifications defined in subclause 4.5 are valid for this IOC, without exceptions or additions
4.3.11 EP_RP
4.3.11.1 Definition
This IOC is provided for sub-classing only. This IOC represents an end point of a link used across a reference point between two network entities.
For naming the subclasses of EP_RP, the following rules shall apply:
– The name of the subclassed IOC shall have the form “EP_<rp>”, where <rp> is a string that represents the name of the reference point.
Thus, two valid examples of EP_RP subclassed IOC names would be: EP_S1 and EP_X2.
4.3.11.2 Attributes
The EP_RP IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
farEndEntity |
O |
T |
F |
F |
T |
|
userLabel |
O |
T |
T |
F |
T |
|
supportedPerfMetricGroups |
O |
T |
F |
F |
T |
4.3.11.3 Attribute constraints
None
4.3.11.4 Notifications
This class does not support any notification.
4.3.12 Void
4.3.13 Void
4.3.14 Void
4.3.15 Void
4.3.16 ThresholdMonitor
4.3.16.1 Definition
This IOC represents a threshold monitor for performance metrics. It can be name-contained by SubNetwork, ManagedElement, or ManagedFunction. A threshold monitor checks for threshold crossings of performance metric values and generates a notification when that happens.
To activate threshold monitoring, a MnS consumer needs to create a ThresholdMonitor instance on the MnS producer. For ultimate deactivation of threshold monitoring, the MnS consumer should delete the monitor to free up resources on the MnS producer.
For temporary suspension of threshold monitoring, the MnS consumer can manipulate the value of the administrative state attribute. The MnS producer may disable threshold monitoring as well, for example in overload situations. This situation is indicated by the MnS producer with setting the operational state attribute to disabled. When monitoring is resumed the operational state is set again to enabled.
All object instances below and including the instance name-containing the ThresholdMonitor (base object instance) are scoped for performance metric production. Performance metrics are monitored only on those object instances whose object class matches the object class associated to the performance metrics to be monitored.
The optional attributes objectInstances and rootObjectInstances allow to restrict the scope. When the attribute objectInstances is present, only the object instances identified by this attribute are scoped. When the attribute rootObjectInstances is present, then the subtrees whose root objects are identified by this attribute are scoped. Both attributes may be present at the same time meaning the total scope is equal to the sum of both scopes. Object instances may be scoped by both the objectInstances and rootObjectInstances attributes. This shall not be considered as an error by the MnS producer.
Multiple thresholds can be defined for multiple performance metric sets in a single monitor using thresholdInfoList. The attribute monitorGranularityPeriod defines the granularity period to be applied.
A threshold is defined using the attributes thresholdValue , thresholdDirection and hysteresis.
When hysteresis is absent or carries no information, a threshold is triggered when the thresholdValue is reached or crossed. When hysteresis is present, two threshold values are specified for the threshold as follows: A high treshold value equal to the threshold value plus the hysteresis value, and a low threshold value equal to the threshold value minus the hysteresis value. When the monitored performance metric increases, the theshold is triggered when the high threshold value is reached or crossed. When the monitored performance metric decreases, the theshold is triggered when the low threshold value is reached or crossed. The hsyteresis ensures that the performance metric value can oscillate around a comparison value without triggering each time the threshold when the threshold value is crossed.
Using the thresholdDirection attribute a threshold can be configured in such a manner that it is triggered only when the monitored performance metric is going up or down upon reaching or crossing the threshold.
A ThresholdMonitor creation request shall be rejected, if the performance metrics requested to be monitored, the requested granularity period, or the requested combination thereof is not supported by the MnS producer. A creation request may fail, when the performance metrics requested to be monitored are not produced by a PerfMetricJob.
Creation and deletion of ThresholdMonitor instances by MnS consumers is optional; when not supported, ThresholdMonitor instances may be created and deleted by the system or be pre-installed.
4.3.16.2 Attributes
The ThresholdMonitor IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
administrativeState |
M |
T |
T |
F |
T |
|
operationalState |
M |
T |
F |
F |
T |
|
thresholdInfoList |
M |
T |
T |
F |
T |
|
monitorGranularityPeriod |
M |
T |
T |
F |
T |
|
objectInstances |
O |
T |
T |
F |
F |
|
rootObjectInstances |
O |
T |
T |
F |
F |
4.3.16.3 Attribute constraints
None.
4.3.16.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC.
4.3.17 ManagedNFService
4.3.17.1 Definition
A ManagedNFService represents a Network Function (NF) service as defined in clause 7 of 3GPP TS 23.501[22].
4.3.17.2 Attributes
The ManagedNFService IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
administrativeState |
M |
T |
T |
F |
T |
|
operationalState |
M |
T |
F |
T |
T |
|
userLabel |
O |
T |
T |
F |
T |
|
nFServiceType |
M |
T |
F |
T |
F |
|
sAP |
M |
T |
T |
F |
T |
|
operations |
M |
T |
T |
F |
T |
|
usageState |
M |
T |
F |
T |
T |
|
registrationState |
CM |
T |
F |
F |
T |
4.3.17.3 Attribute constraints
Attribute constraint for registrationState: The attribute registrationState should be supported by instance of a ManagedNFService if the service is designed for being publicshed and discovered by other NFs, and need to be registered to a repository function. E.g. Authentication service provided by AUSF should include this attribute. NF management services provided by NRF don’t include this attribute.
4.3.17.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions
4.3.18 Operation <<dataType>>
4.3.18.1 Definition
This data type represents an Operation. An Operation is comprised of a name, an allowedNFType and an operationSemantics (See TS 23.502 [23]).
4.3.18.2 Attributes
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
name |
M |
T |
F |
T |
F |
|
allowedNFTypes |
M |
T |
T |
F |
T |
|
operationSemantics |
M |
T |
F |
T |
T |
4.3.18.3 Attribute constraints
None
4.3.18.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.19 SAP <<dataType>>
4.3.19.1 Definition
This data type represents the access point of a managed NF service which is comprised of a host and a port.
4.3.19.2 Attributes
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
host |
M |
T |
T |
F |
T |
|
port |
M |
T |
T |
F |
T |
4.3.19.3 Attribute constraints
None
4.3.19.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.20 ManagedEntity <<ProxyClass>>
4.3.20.1 Definition
This <<ProxyClass>> represents one or multiple IOCs. The IOCs the <<ProxyClass>> represents are defined where the <<ProxyClass>> is used.
4.3.20.2 Attributes
See respective IOCs.
4.3.20.3 Attribute constraints
See respective IOCs.
4.3.20.4 Notifications
See respective IOCs.
4.3.21 HeartbeatControl
4.3.21.1 Definition
MnS consumers (i.e. notification recipients) use heartbeat notifications to monitor the communication channels between them and data report MnS producers emitting notifications such as notifyNewAlarm and notifyFileReady.
A HeartbeatControl instance allows controlling the emission of heartbeat notifications by MnS producers. The recipients of heartbeat notifications are specified by the notificationRecipientAddress attribute of the NtfSubscriptionControl instance name containing the HeartbeatControl instance.
Note that the MnS consumer managing the HeartbeatControl instance and the MnS consumer receiving the heartbeat notifications may not be the same.
As a pre-condition for the emission of heartbeat notifications, a HeartbeatControl instance needs to be created. Creation of an instance with an initial non-zero value of the heartbeatNtfPeriod attribute triggers an immediate heartbeat notification emission. Creation of an instance with an initial zero value of the heartbeatPeriod attribute does not trigger an emission of a heartbeat notification. Deletion of an instance does not trigger an emission of a heartbeat notification.
Once the instance is created, heartbeat notifications are emitted with a periodicity defined by the value of the heartbeatNtfPeriod attribute. No heartbeat notifications are emitted if the value is equal to zero. Setting a zero value to a non zero value, or a non zero value to a different non zero value, triggers an immediate heartbeat notification, that is the base for the new heartbeat period. Setting a non zero value to a zero value stops emitting heartbeats immediately; no final heartbeat notification is sent.
The attribute triggerHeartbeatNtf allows MnS consumers to trigger the emission of an immediate additional heartbeat notification. The emission of heartbeat notifications according to the heartbeat period is not impacted by this additional notification.
Creation and deletion of HeartbeatControl instances by MnS Consumers is optional; when not supported, the HeartbeatControl instances may be created and deleted by the system or be pre-installed.
The emission of heartbeat notifications is fully controlled by HeartbeatControl instances. Subscription for heartbeat notifications is not supported by NtfSubscriptionControl.
4.3.21.2 Attributes
The HeartbeatControl IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
heartbeatNtfPeriod |
M |
T |
T |
F |
T |
|
triggerHeartbeatNtf |
M |
F |
T |
F |
F |
4.3.21.3 Attribute constraints
None.
4.3.21.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyHeartbeat |
M |
— |
4.3.22 NtfSubscriptionControl
4.3.22.1 Definition
NtfSubscriptionControl represents a notification subscription of a notification recipient. It can be name-contained by SubNetwork or ManagedElement.
The scope attribute is used to select managed object instances included in the subscription. The base object instance of the scope (see clause 4.3.23) is the object instance name-containing the NtfSubscriptionControl instance. When the scope attribute is absent, all objects below and including the base object are scoped. The notifications related to the selected managed object instances are candidates to be sent to the address specified by the notificationRecipientAddress attribute.
The notificationType attribute and notificationFilter attribute allow MnS consumers to control which candidate notifications are sent to the notificationRecipientAddress.
If the notificationType attribute is present, its value identifies the notification types that are candidates to be sent to the notificationRecipientAddress. If the notificationType attribute is absent, notifications of all types are candidates to be sent to notificationRecipientAddress.
If supported, the notificationFilter attribute defines a filter that is applied to the set of candidate notifications. The filter is applicable to all parameters of a notification. Only candidate notifications that pass the filter criteria are sent to the notificationRecipientAddress. If the notificationFilter attribute is absent, all candidate notificatios are sent to the notificationRecipientAddress.
To receive notifications, a MnS consumer has to create a NtfSubscriptionControl instance on the MnS producer. A MnS consumer can create a subscription for another MnS consumer since it is not required the notificationRecipientAddress be his own address.
When a MnS consumer does not wish to receive notifications any more the MnS consumer shall delete the corresponding NtfSubscriptionControl instance.
When a subscription is created and the notification scope inludes the created subscription object and the subscribed notification types include notifications reporting object creation (notifyMOICreation or notifyMOIChanges), the first notification sent related to the new subscription shall report the creation of the NtfSubscriptionControl instance. Likewise, when a subscription is deleted and the notification scope inludes the deleted subscription object and the subscribed notification types include notifications reporting object deletion (notifyMOIDeletion or notifyMOIChanges), the last notification sent related to the subscription shall report the deletion of the NtfSubscriptionControl instance.
Creation and deletion of NtfSubscriptionControl instances by MnS consumers is optional; when not supported, the NtfSubscriptionControl instances may be created and deleted by the system or be pre-installed.
4.3.22.2 Attributes
The NtfSubscriptionControl IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
notificationRecipientAddress |
M |
T |
T |
F |
T |
|
notificationTypes |
O |
T |
T |
F |
T |
|
scope |
O |
T |
T |
F |
T |
|
notificationFilter |
O |
T |
T |
F |
T |
4.3.22.3 Attribute constraints
None.
4.3.22.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.23 Scope <<dataType>>
4.3.23.1 Definition
This <<dataType>> defines a scope for selecting managed object instances below and including a base managed object instance. The scope is specified with the scope type and a scope level attributes. The specification of the base object instance is not part of this <<dataType>> and needs to be specified by other means.
4.3.23.2 Attributes
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
scopeType |
M |
T |
T |
F |
T |
|
scopeLevel |
O |
T |
T |
F |
T |
4.3.23.3 Attribute constraints
None.
4.3.23.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.24 Void
4.3.25 Void
4.3.26 AlarmList
4.3.26.1 Definition
The AlarmList represents the capability to store and manage alarm records. It can be name-contained by SubNetwork and ManagedElement. The management scope of an AlarmList is defined by all descendant objects of the base managed object, which is the object name-containing the AlarmList, and the base object itself.
AlarmList instances are created by the system or are pre-installed. They cannot be created nor deleted by MnS consumers.
An instance of SubNetwork or ManagedElement has at most one name-contained instance of AlarmList.
When the alarm list is locked or disabled, the existing alarm records are not updated or deleted, and new alarm records are not added to the alarm list.
4.3.26.2 Attributes
The AlarmList IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
administrativeState |
O |
T |
T |
F |
T |
|
operationalState |
M |
T |
F |
F |
T |
|
numOfAlarmRecords |
M |
T |
F |
F |
F |
|
lastModification |
M |
T |
F |
F |
F |
|
alarmRecords |
M |
T |
T |
F |
F |
4.3.26.3 Attribute constraints
None
4.3.26.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.27 AlarmRecord <<dataType>>
4.3.27.1 Definition
An AlarmRecord contains alarm information of an alarmed object instance. A new record is created in the alarm list when an alarmed object instance generates an alarm and no alarm record exists with the same values for objectInstance, alarmType, probableCause and specificProblem. When a new record is created the MnS producer creates an alarmId, that unambiguously identifies an alarm record in the AlarmList.
Alarm records are maintained only for active alarms. Inactive alarms are automatically deleted by the MnS producer from the AlarmList. Active alarms are alarms whose
a) perceivedSeverity is not "CLEARED", or whose
b) perceivedSeverity is "CLEARED" and its ackState is not "ACKNOWLEDED".
4.3.27.2 Attributes
The attributes are defined in clause 11.2.2.1.5.1 of TS 28.532 [27]. Many of them are based on definitions in ITU-T X.733 [31].
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
alarmId |
M |
T |
F |
T |
F |
|
objectInstance |
M |
T |
F |
T |
F |
|
notificationId |
M |
T |
F |
T |
F |
|
alarmRaisedTime |
M |
T |
F |
F |
F (note 5) |
|
alarmChangedTime |
O |
T |
F |
F |
F (note 6) |
|
alarmClearedTime |
M |
T |
F |
F |
F (note 7) |
|
alarmType |
M |
T |
F |
T |
F |
|
probableCause |
M |
T |
F |
T |
F |
|
specificProblem |
O |
T |
F |
T |
F |
|
perceivedSeverity |
M |
T |
T (note 4) |
F |
F(note 6) |
|
backedUpStatus |
O |
T |
F |
F |
F |
|
backUpObject |
O |
T |
F |
F |
F |
|
trendIndication |
O |
T |
F |
F |
F |
|
thresholdInfo |
O |
T |
F |
F |
F |
|
stateChangeDefinition |
O |
T |
F |
F |
F |
|
monitoredAttributes |
O |
T |
F |
F |
F |
|
proposedRepairActions |
O |
T |
F |
F |
F |
|
additionalText |
O |
T |
F |
F |
F |
|
additionalInformation |
O (see note 3) |
T |
F |
F |
F |
|
rootCauseIndicator |
O |
T |
F |
F |
F |
|
ackTime |
M |
T |
F |
F |
F |
|
ackUserId |
M |
T |
T (see note 8) |
F |
F |
|
ackSystemId |
O |
T |
T (see note 8) |
F |
F |
|
ackState |
M |
T |
T (see note 8) |
F |
F |
|
clearUserId |
O (see note 1) |
T |
T |
F |
F |
|
clearSystemId |
O (see note 1) |
T |
T |
F |
F |
|
serviceUser |
O (see note 2) |
T |
F |
F |
F |
|
serviceProvider |
O (see note 2) |
T |
F |
F |
F |
|
securityAlarmDetector |
O (see note 2) |
T |
F |
F |
F |
|
NOTE 1: These attributes and qualifiers are applicable only if producer supports consumer to set perceivedSeverity to CLEARED. NOTE 2: These attributes are supported if the producer emits notifyNewAlarm that carries security alarm information. NOTE 3: This attribute is supported to carry vendor specific information. NOTE 4: This isWritable property is True only if producer supports consumer to set perceivedSeverity to CLEARED NOTE 5: Emit notifyNewAlarm. NOTE 6: Emit notifyChangedAlarm NOTE 7: Emit notifyClearedAlarm NOTE 8: This isWritable property is True only if producer supports the consumer to acknowledge alarms. |
|||||
4.3.27.3 Attribute constraints
None.
4.3.27.4 Notifications
See subclause 4.5.1.
4.3.28 Void
4.3.29 Top
4.3.29.1 Definition
This IOC is provided for sub-classing only. All information object classes defined in all TS that claim to be conformant to 32.102 [2] and support the Federated Network Information Model (FNIM) concept shall inherit from Top.
4.3.29.2 Attributes
This IOC includes attributes inherited from TopX IOC (defined in clause 4.3.8) and the attributes inherited from Top_ IOC (defined in TS 28.620 [9]).
4.3.29.3 Attribute constraints
None
4.3.29.4 Notifications
There is no notification defined.
4.3.30 TraceJob
4.3.30.1 Definition
A TraceJob instance represents the Trace Control and Configuration parameters of a particular Trace Job (see TS 32.421 [29] and TS 32.422 [30] for details). It can be name-contained by SubNetwork, ManagedElement, ManagedFunction.
To activate Trace Jobs, a MnS consumer has to create TraceJob object instances on the MnS producer. A MnS consumer can activate a Trace Job for another MnS consumer since it is not required the value of traceCollectionEntityIPAddress or traceReportingConsumerUri to be his own.
For the details of Trace Job activation see clauses 4.1.1.1.2 and 4.1.2.1.2 of TS 32.422 [30].
When a MnS consumer wishes to deactivate a Trace Job, the MnS consumer shall delete the corresponding TraceJob instance. For details of management Trace Job deactivation see clauses 4.1.3.8 to 4.1.3.11 and 4.1.4.10 to 4.1.4.13 of TS 32.422 [30].
The attribute traceReference specifies a globally unique ID and identifies a Trace session. One Trace Session may be activated to multiple Network Elements.
The attribute traceRecordingSessionReference identifies a Trace Recording Session within a Trace Session. Two different trace sessions could e.g. be caused by two different trigger events.
The jobId attribute presents the job identifier of a TraceJob instance. The jobId can be used to associate multiple TraceJob instances. For example, it is possible to configure the same jobId value for multiple TraceJob instances required to produce the data (e.g. RSRP values of M1 and RLF reports) for a specific network analysis.
The attribute traceReportingFormat defines the method for reporting the produced measurements. The selectable options are file-based or stream-based reporting. In case of file-based reporting the attribute traceCollectionEntityIPAddress is used to specify the IP address to which the trace records shall be transferred, while in case of stream-based reporting the attribute traceReportingConsumerUri specifies the streaming target.
The mandatory attribute traceTarget determines the target object of the TraceJob. Dependent on the network element to which the Trace Session is activated different types of the target object are possible. The attribute pLMNTarget defines the PLMN for which sessions shall be selected in the Trace Session in case of management based activation when several PLMNs are supported in the RAN.
The attribute jobType specifies the kind of data to collect. Dependent on the selected type various parameters shall be available. The attributes jobType, traceReference, traceRecordingSessionReference, traceCollectionEntityIPAddress, traceTarget and traceReportingFormat are mandatory for all job types. If streaming reporting is selected for traceReportingFormat, traceReportingConsumerUri shall be present additionally. The attribute pLMNTarget shall be present if trace activation method is management based.
For the different job types the attributes are differentiated as follows:
– In case of TRACE_ONLY additionally the following attributes shall be available: listOfNETypes, traceDepth, and triggeringEvents.
For this case the optional attribute listOfInterfaces allows to specify the interfaces to be recorded.
– In case of IMMEDIATE_MDT_ONLY additionally the following attributes shall be available:
– anonymizationOfMDTData,
– listOfMeasurements,
– collectionPeriodRRMUMTS (conditional for M4 and M5 in UMTS),
– measurementPeriodUMTS (conditional for M6 and M7 in UMTS),
– collectionPeriodRRMLTE (conditional for M3 in LTE),
– measurementPeriodLTE (conditional for M4 and M5 in LTE),
– collectionPeriodM6LTE (conditional for M6 in LTE),
– collectionPeriodM7LTE (conditional for M7 in LTE),
– collectionPeriodRRMNR (conditional for M4 and M5 in NR),
– collectionPeriodM6NR (conditional for M6 in NR),
– collectionPeriodM7NR (conditional for M7 in NR),
– beamLevelMeasurement (conditional for M1 in NR),
– reportInterval (conditional for M1 in LTE or NR and M1/M2 in UMTS),
– reportAmount (conditional for M1 in LTE or NR and M1/M2 in UMTS),
– reportingTrigger (conditional for M1 in LTE or NR and M1/M2 in UMTS),
– eventThreshold (conditional for A2 event reporting or A2 event triggered periodic reporting),
– measurementQuantity (conditional for 1F event reporting).
– excessPacketDelayThresholds (conditional for M6 UL measurement in NR).
For this case the optional attribute areaScope allows to specify the area in terms of cells or Tracking Area/Routing Area/Location area where the MDT data collection shall take place and the optional attributes positioningMethod, sensorInformation allow to specify the positioning methods to use or the sensor information to include.
– In case of IMMEDIATE_MDT_AND_TRACE both additional attributes of TRACE_ONLY and IMMEDIATE_MDT_ONLY shall apply.
– In case of LOGGED_MDT_ONLY additionally the following attributes shall be available: anonymizationOfMDTData, traceCollectionEntityId, loggingInterval, loggingDuration, reportType, eventListForEventTriggeredMeasurements.
For this case the optional attribute areaScope allows to specify the area in terms of cells or Tracking Area/Routing Area/Location area where the MDT data collection shall take place, the optional attribute pLMNList allows to specify the PLMNs where measurement collection, status indication and log reporting is allowed, the optional attribute areaConfigurationForNeighCell allows to specify the area for which UE is requested to perform measurements logging for neighbour cells which have list of frequencies and the optional attribute sensorInformation allows to specify the sensor information to include.
– In case of RLF_REPORT_ONLY and RCEF_REPORT_ONLY the optional attribute areaScope allows to specify the eNB or list of eNBs or gNB or list of gNBs where the reports should be collected.
– In case of LOGGED_MBSFN_MDT additionally the following attributes shall be available: anonymizationOfMDTData, loggingInterval, loggingDuration, mBSFNAreaList.
Reporting of measurements and messages can be periodical, event triggered or event triggered periodic depending on the selected job type.
– For trace the reporting is event based, where the triggering event is configured with attribute triggeringEvents. For each triggering event the first and last message (start/stop triggering event) to record are specified.
– For immediate MDT, the reporting is dependent on the configured measurements:
– For measurement M1 in LTE or NR, it is possible to select between periodical, event triggered, event triggered periodic reporting or reporting according to all configured RRM event triggers. For M1 and M2 measurement in UMTS, it is possible to select between periodical, event triggered reporting or reporting according to all configured RRM event triggers. Parameter reportingTrigger determines which of the reporting methods is selected and in case of event triggered or event-triggered periodic, which is the decisive event type. For periodical reporting, parameters reportInterval and reportAmount determine the interval between two successive reports and the number of reports. This means the periodical reporting terminates after reportAmount reports have been sent as long as reportAmount is configured with a value different from infinity. For event-triggered periodic reporting, these two parameters apply in addition to parameter eventThreshold which determines the threshold of the event. In this case up to reportAmount reports are sent with a periodicity of reportInterval after the entering condition is fulfilled. The reporting is stopped, if the leaving condition is fulfulled and is restarted if the configured event reoccurs. For event based reporting, there is only one report sent after the event occurs. The parameters to configure are reportingTrigger and eventThreshold. In case of UMTS and 1f event reporting, additionally parameter measurementQuantity is necessary in order to determine for which measurement(s) the event threshold is applicable.
Parameter beamLevelMeasurement determines whether beam level measurements shall be included in case of NR.
– For measurement M2 in LTE or NR, reporting is according to RRM configuration, see TS 38.321 [36], TS 36.321 [37] and TS 38.331 [38], TS 36.331 [39]. For measurement M4 in UMTS, reporting is either according to RRM configuration, see TS 25.321 [40] and TS 25.331 [41] or periodic or event triggered periodic using parameter collectionPeriodRRMUMTS and eventThresholdUphUMTS.
– For measurement M3 in UMTS, the reporting is done upon availability, see TS 37.320 [43].
– For measurements M4, M5, M6 and M7 in NR, for measurements M3, M4, M5, M6 and M7 in LTE and for measurements M5, M6 and M7 in UMTS periodical reporting is applied. The configurable parameter is the interval between two measurements (collectionPeriodRRMNR, collectionPeriodM6NR, collectionPeriodM7NR, collectionPeriodRRMLTE, measurementPeriodLTE, collectionPeriodM6LTE, collectionPeriodM7LTE, collectionPeriodRRMUMTS, measurementPeriodUMTS). If no collection period is configured for M5 in UMTS, all available measurements are logged according to RRM configuration.
– For logged MDT in UMTS and LTE, the reporting is periodical. Parameter loggingInterval determines the interval between the reports and parameter loggingDuration determines how long the configuration is valid meaning after this duration has passed no further reports are sent. In NR, the reporting can be periodical or event based, determined by parameter reportType. For periodical reporting the same parameters as in LTE and UMTS apply. For event based reporting, parameter eventListForEventTriggeredMeasurement configures the event type, namely ‘out of coverage’ or ‘L1 event’. In case ‘L1 event’ is selected as event type, the logging is performed according to parameter loggingInterval at regular intervals only when the conditions indicated by eventThresholdL1, hysteresisL1, timeToTriggerL1 (defining the thresholds, hysteresis and time to trigger) are met and if UE is ‘camped normally’ state (TS 38.331 [38], TS 38.304 [42]). In case ‘out of coverage’ is selected as event type, the logging is performed according to parameter loggingInterval at regular intervals only when the UE is in ‘any cell selection’ state. Furthermore, logging is performed immediately upon transition from the ‘any cell selection’ state to the ‘camped normally’ state ( TS 38.331 [38], TS 38.304 [42]).
Creation and deletion of TraceJob instances by MnS consumers is optional; when not supported, the TraceJob instances may be created and deleted by the system or be pre-installed.
4.3.30.2 Attributes
The TraceJob IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
jobType |
M |
T |
T |
F |
T |
|
listOfInterfaces |
CO |
T |
T |
F |
T |
|
listOfNETypes |
CM |
T |
T |
F |
T |
|
pLMNTarget |
CM |
T |
T |
F |
T |
|
traceReportingConsumerUri |
CM |
T |
T |
F |
T |
|
traceCollectionEntityIPAddress |
CM |
T |
T |
F |
T |
|
traceDepth |
CM |
T |
T |
F |
T |
|
traceReference |
M |
T |
T |
F |
T |
|
traceRecordingSessionReference |
M |
T |
T |
F |
T |
|
jobId |
O |
T |
T |
T |
T |
|
traceReportingFormat |
M |
T |
T |
F |
T |
|
traceTarget |
M |
T |
T |
F |
T |
|
triggeringEvents |
CM |
T |
T |
F |
T |
|
anonymizationOfMDTData |
CM |
T |
T |
F |
T |
|
areaConfigurationForNeighCell |
CO |
T |
T |
F |
T |
|
areaScope |
CO |
T |
T |
F |
T |
|
collectionPeriodRRMLTE |
CM |
T |
T |
F |
T |
|
collectionPeriodM6LTE |
CM |
T |
T |
F |
T |
|
collectionPeriodM7LTE |
CM |
T |
T |
F |
T |
|
collectionPeriodRRMUMTS |
CM |
T |
T |
F |
T |
|
collectionPeriodRRMNR |
CM |
T |
T |
F |
T |
|
collectionPeriodM6NR |
CM |
T |
T |
F |
T |
|
collectionPeriodM7NR |
CM |
T |
T |
F |
T |
|
beamLevelMeasurement |
CM |
T |
T |
F |
T |
|
eventListForEventTriggeredMeasurement |
CM |
T |
T |
F |
T |
|
eventThreshold |
CM |
T |
T |
F |
T |
|
listOfMeasurements |
CM |
T |
T |
F |
T |
|
loggingDuration |
CM |
T |
T |
F |
T |
|
loggingInterval |
CM |
T |
T |
F |
T |
|
eventThresholdL1 |
CM |
T |
T |
F |
T |
|
hysteresisL1 |
CM |
T |
T |
F |
T |
|
timeToTriggerL1 |
CM |
T |
T |
F |
T |
|
mBSFNAreaList |
CM |
T |
T |
F |
T |
|
measurementPeriodLTE |
CM |
T |
T |
F |
T |
|
measurementPeriodUMTS |
CM |
T |
T |
F |
T |
|
measurementQuantity |
CM |
T |
T |
F |
T |
|
eventThresholdUphUMTS |
CO |
T |
T |
F |
T |
|
pLMNList |
CO |
T |
T |
F |
T |
|
positioningMethod |
CO |
T |
T |
F |
T |
|
reportAmount |
CM |
T |
T |
F |
T |
|
reportingTrigger |
CM |
T |
T |
F |
T |
|
reportInterval |
CM |
T |
T |
F |
T |
|
reportType |
CM |
T |
T |
F |
T |
|
sensorInformation |
CO |
T |
T |
F |
T |
|
traceCollectionEntityId |
CM |
T |
T |
F |
T |
|
excessPacketDelayThresholds |
CO |
T |
T |
F |
T |
4.3.30.3 Attribute constraints
|
Name |
Definition |
|
listOfInterfaces (support qualifier) |
This attribute shall be present when jobType includes Trace. |
|
listOfNETypes (support qualifier) |
This attribute shall be present only for Trace with Signalling Based Activation |
|
pLMNTarget (support qualifier) |
This attribute shall be present for management based activation when several PLMNs are supported in the RAN. |
|
traceReportingConsumerUri (support qualifier) |
This attribute shall be present if streaming trace data reporting is supported and traceReportingFormat set to "streaming". |
|
traceCollectionEntityIPAddress (support qualifier) |
This attribute shall be present if file based trace data reporting is supported and traceReportingFormat set to "file based" or when jobType is set to Logged MDT or Logged MBSFN MDT. |
|
traceDepth (support qualifier) |
This attribute shall be present when jobType includes Trace. |
|
triggeringEvents (support qualifier) |
This attribute shall be present when jobType includes Trace. |
|
anonymizationOfMDTData (support qualifier) |
This attribute shall be present only if MDT is supported and the areaScope attribute is present. This attribute is only applicable for management based activation. |
|
areaConfigurationForNeighCell (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
areaScope (support qualifier) |
This attribute shall be present if MDT is supported. |
|
collectionPeriodRRMLTE (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has any of M2, M3 measurement set in case of LTE. |
|
collectionPeriodRRMUMTS (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has any of M3, M4, M5 measurement set in case of UMTS. |
|
eventListForEventTriggeredMeasurement (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
eventThreshold (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT and the reportingTrigger attribute is configured for A2EventReporting in LTE and NR or 1f/1IEventReporting in UMTS. |
|
listOfMeasurements (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT. |
|
loggingDuration (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Logged MDT or Logged MBSFN MDT. |
|
loggingInterval (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Logged MDT or Logged MBSFN MDT. |
|
eventThresholdL1 (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
hysteresisL1 (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
timeToTriggerL1 (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
mBSFNAreaList (support qualifier) |
This attribute shall be present only if Logged MBSFN MDT is supported and the jobType attribute is set to Logged MBSFN MDT. This is applicable only for eUTRAN. |
|
measurementPeriodLTE (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute for LTE has either M4 or M5 measurement set. |
|
collectionPeriodM6LTE (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute for LTE has M6 measurement set. |
|
collectionPeriodM7LTE (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute for LTE has M7 measurement set. |
|
measurementPeriodUMTS (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute for UMTS has M6 or M7 measurements set. |
|
collectionPeriodRRMNR (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has any of M4, M5 measurement set in case of NR. |
|
collectionPeriodM6NR (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has M6 measurement set in case of NR. |
|
collectionPeriodM7NR (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has any of M7 measurement set in case of NR. |
|
beamLevelMeasurement (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT and the listOfMeasurements attribute has M1 measurement set in case of NR. |
|
measurementQuantity (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combined Trace and Immediate MDT and the reportingTrigger parameter is set to event 1F. |
|
eventThresholdUphUMTS (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combined Trace and Immediate MDT and the listOfMeasurements attribute has M4 measurement set in case of UMTS. |
|
pLMNList (support qualifier) |
This attribute shall be present only if MDT is supported, several PLMNs are supported in the RAN and the jobType attribute is set to Logged MDT. |
|
positioningMethod (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT or combine Trace and Immediate MDT. |
|
reportAmount (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT and the reportingTrigger attribute is configured for periodic measurements or event triggered periodic measurements. |
|
reportingTrigger (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT and the listOfMeasurements attribute is configured for M1 (for UMTS, LTE and NR) or M2 (only for UMTS). |
|
reportInterval (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Immediate MDT, the listOfMeasurements attribute is configured for M1 (for UMTS, LTE and NR) or M2 (only for UMTS) and the reportingTrigger is configured for periodic measurements or event triggered periodic measurements. |
|
reportType (support qualifier) |
This attribute shall be present only if NR MDT is supported and the jobType attribute is set to Logged MDT. |
|
sensorInformation (support qualifier) |
This attribute shall be present only if NR MDT is supported. |
|
traceCollectionEntityId (support qualifier) |
This attribute shall be present only if MDT is supported and the jobType attribute is set to Logged MDT. |
4.3.30.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions.
4.3.31 PerfMetricJob
4.3.31.1 Definition
This IOC represents a performance metric production job. It can be name-contained by SubNetwork, ManagedElement, or ManagedFunction.
To activate the production of the specified performance metrics, a MnS consumer needs to create a PerfMetricJob instance on the MnS producer. For ultimate deactivation of metric production, the MnS consumer should delete the job to free up resources on the MnS producer.
For temporary suspension of metric production, the MnS consumer can manipulate the value of the administrative state attribute. The MnS producer may disable metric production as well, for example in overload situations. This situation is indicated by the MnS producer with setting the operational state attribute to disabled. When production is resumed the operational state is set back to enabled.
The jobId attribute can be used to associate metrics from multiple PerfMetricJob instances. The jobId can be included when reporting performance metrics to allow a MnS consumer to associate received metrics for the same purpose. For example, it is possible to configure the same jobId value for multiple PerfMetricJob instances required to produce the measurements for a specific KPI.
The attribute performanceMetrics defines the performance metrics to be produced and the attribute granularityPeriod defines the granularity period to be applied.
All object instances below and including the instance name-containing the PerfMetricJob (base object instance) are scoped for performance metric production. Performance metrics are produced only on those object instances whose object class matches the object class associated to the performance metrics to be produced.
The optional attributes objectInstances and rootObjectInstances allow to restrict the scope. When the attribute objectInstances is present, only the object instances identified by this attribute are scoped. When the attribute rootObjectInstances is present, then the subtrees whose root objects are identified by this attribute are scoped. Both attributes may be present at the same time meaning the total scope is equal to the sum of both scopes. Object instances may be scoped by both the objectInstances and rootObjectInstances attributes. This shall not be considered as an error by the MnS producer.
When the performance metric requires performance metric production on multiple managed objects, which is for example the case for KPIs, the MnS consumer needs to ensure all required objects are scoped. Otherwise a PerfMetricJob creation request shall fail.
The attribute reportingCtrl specifies the method and associated control parameters for reporting the produced measurements to MnS consumers. Three methods are available: file-based reporting with selection of the file location by the MnS producer, file-based reporting with selection of the file location by the MnS consumer and stream-based reporting.
For file-based reporting, all performance metrics that are produced related to a "PerfMetricJob" instance for a reporting period shall be stored in a single reporting file.
When the administrative state is set to "UNLOCKED" after the creation of a "PerfMetricJob" the first granularity period shall start. When the administrative state is set to "LOCKED" or the operational state to "DISABLED", the ongoing reporting period shall be aborted, for streaming the ongoing granularity period. When the administrative state is set back to "UNLOCKED" or the operational state to "ENABLED" a new reporting period period shall start, in case of streaming a new granularity period.
Changes of all other configurable attributes shall take effect only at the beginning of the next reporting period, for streaming at the beginning of the next granularity period.
When the "PerfMetricJob" is deleted, the ongoing reporting period shall be aborted, for streaming the ongoing granularity period.
A PerfMetricJob creation request shall be rejected, if the requested performance metrics, the requested granularity period, the requested repoting method, or the requested combination thereof is not supported by the MnS producer.
Creation and deletion of PerfMetricJob instances by MnS consumers is optional; when not supported, PerfMetricJob instances may be created and deleted by the system or be pre-installed.
When the file retrieval NRM fragment is supported by the MnS producer, the "_linkToFiles" attribute shall be supported, for details on the usage of this attribute see the definition of the file retrieval NRM fragment.
4.3.31.2 Attributes
The PerfMetricJob IOC includes attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
administrativeState |
M |
T |
T |
F |
T |
|
operationalState |
M |
T |
F |
F |
T |
|
jobId |
M |
T |
T |
T |
T |
|
performanceMetrics |
M |
T |
T |
F |
T |
|
granularityPeriod |
M |
T |
T |
F |
T |
|
objectInstances |
O |
T |
T |
F |
T |
|
rootObjectInstances |
O |
T |
T |
F |
T |
|
reportingCtrl |
M |
T |
T |
F |
T |
|
_linkToFiles |
CO |
T |
F |
T |
F |
4.3.31.3 Attribute constraints
|
Name |
Definition |
|
_linkToFiles |
This attribute should be supported, when the MnS producer supports the file retrieval NRM fragment. |
4.3.31.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyFileReady |
M |
— |
|
notifyFilePreparationError |
M |
— |
4.3.32 SupportedPerfMetricGroup <<dataType>>
4.3.32.1 Definition
This <<dataType>> captures a group of supported performance metrics, and associated (production and monitoring) granularity periods and reporting methods that are supported for the specified performance metric group.
4.3.32.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
performanceMetrics |
M |
T |
F |
F |
T |
|
granularityPeriods |
M |
T |
F |
F |
T |
|
reportingMethods |
M |
T |
F |
F |
T |
|
monitorGranularityPeriods |
M |
T |
F |
F |
T |
4.3.32.3 Attribute constraints
None
4.3.32.4 Notifications
Not applicable.
4.3.33 ReportingCtrl <<choice>>
4.3.33.1 Definition
This <<choice>> defines the method for reporting collected performance metrics to MnS consumers as well as the parameters for configuring the reporting function. It is a choice between the control parameter required for the reporting methods, whose presence selects the reporting method as follows:
When only the fileReportingPeriod attribute is present (CHOICE_1), the MnS producer shall store files on the MnS producer at a location selected by the MnS producer and, on condition that an appropriate subscription is in place, inform the MnS consumer about the availability of new files and the file location using the notifyFileReady notification. In case the preparation of a file fails, "notifyFilePreparationError" shall be sent instead.
When the "fileReportingPeriod" and "notificationRecipientAddress" attributes are present (CHOICE_2), then the MnS producer shall behave like described for the case that only the "fileReportingPeriod" is present. In addition, the MnS producer shall create on behalf of the MnS consumer a subscription, using "NtfSubscriptionControl", for the notification types "notifyMOICreation" and "notifyMOIDeletion" related to the "File" instances that will be produced later.In case an existing subscription does already include the "File" instances to be produced, no new subscription shall be created. The "notificationRecipientAddress" attribute in the created "NtfSubscriptionControl" instance shall be set to the value of the "notificationRecipientAddress" in the related "PerfMetricJob". This feature is called implicit notification subscription, as opposed to the case where the MnS consumer creates the subscription (explicit notification subscription). When the related "PerfMetricJob" is deleted, the "NtfSubscriptionControl" instance created due to the request for implicit subscription shall be deleted as well.
When only the fileReportingPeriod and fileLocation attributes are present (CHOICE_3), the MnS producer shall store the files on a MnS consumer, that can be any entity such as a file server, at the location specified by fileLocation. No notification is emitted by the MnS producer.
When only the streamTarget attribute is present (CHOICE_4), the MnS producer shall stream the data to the location specified by streamTarget.
For the file-based reporting methods the fileReportingPeriod attribute specifies the time window during which collected measurements are stored into the same file before the file is closed and a new file is opened.
4.3.33.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
CHOICE_1.1 fileReportingPeriod |
CM |
T |
T |
F |
T |
|
CHOICE_2.1 fileReportingPeriod |
CM |
T |
T |
F |
T |
|
CHOICE_2.2 notificationRecipientAddress |
CM |
T |
T |
F |
T |
|
CHOICE_3.1 fileReportingPeriod |
CM |
T |
T |
F |
T |
|
CHOICE_3.2 fileLocation |
CM |
T |
T |
F |
T |
|
CHOICE_4.1 streamTarget |
CM |
T |
T |
F |
T |
4.3.33.3 Attribute constraints
|
Name |
Definition |
|
CHOICE_1.1 fileReportingPeriod |
This attribute shall be supported, when the MnS producer supports file based reporting and storing files on the MnS producer. |
|
CHOICE_2.1 fileReportingPeriod CHOICE_2.2 notificationRecipientAddress |
These attributes shall be supported, when the MnS producer supports file based reporting, storing files on the MnS producer and implicit notification subscription. |
|
CHOICE_3.1 fileReportingPeriod CHOICE_3.2 fileLocation |
These attributes shall be supported, when MnS producer supports file based reporting and storing files on a MnS consumer. |
|
CHOICE_4.1 streamTarget |
This attribute shall be supported, when the MnS producer supports stream-based reporting. |
4.3.33.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.34 ThresholdInfo <<dataType>>
4.3.34.1 Definition
This data type defines a single threshold level.
4.3.34.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
performanceMetrics |
M |
T |
T |
F |
T |
|
thresholdDirection |
M |
T |
T |
F |
T |
|
thresholdValue |
M |
T |
T |
F |
T |
|
hysteresis |
O |
T |
T |
F |
T |
4.3.34.3 Attribute constraints
None
4.3.34.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.35 TraceReference <<dataType>>
4.3.35.1 Definition
This <<dataType>> defines a globally unique identifier, which uniquely identifies the Trace Session that is created by the TraceJob. It is composed of the MCC, MNC (resulting in PLMN identifier) and the trace identifier.
4.3.35.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
mcc |
M |
T |
T |
T |
N/A |
|
mnc |
M |
T |
T |
T |
N/A |
|
traceId |
M |
T |
T |
T |
N/A |
4.3.36 AreaConfig <<dataType>>
4.3.36.1 Definition
This <<dataType>> defines the area for which measurement logging should be performed. It is described by a list of cells and a list of frequencies.
4.3.36.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
freqInfo |
M |
T |
T |
F |
T |
|
pciList |
M |
T |
T |
F |
T |
4.3.37 FreqInfo <<dataType>>
4.3.37.1 Definition
This <<dataType>> defines the RF reference frequency and the frequency operating bands used in a cell for a given direction (UL or DL) in FDD or for both UL and DL directions in TDD.
4.3.37.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
arfcn |
M |
T |
T |
F |
T |
|
freqBands |
M |
T |
T |
F |
T |
4.3.38 AreaScope <<dataType>>
4.3.38.1 Definition
This <<dataType>> defines the area scope of MDT.
The Area Scope parameter in LTE and NR is either:
– list of Cells, identified by E-UTRAN-CGI or NG-RAN CGI. Maximum 32 CGI can be defined.
– list of Tracking Area, identified by TAC. Maximum of 8 TAC can be defined.
– list of Tracking Area Identity, identified by TAC with associated plmn-Identity perTAC-List containing the PLMN identity for each TAC. Maximum of 8 TAI can be defined.
4.3.38.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
choice |
|||||
|
> eutraCellIdList |
O |
T |
T |
F |
T |
|
> nrCellIdList |
O |
T |
T |
F |
T |
|
> tacList |
O |
T |
T |
F |
T |
|
> taiList |
O |
T |
T |
F |
T |
4.3.39 Tai <<dataType>>
4.3.39.1 Definition
This <<dataType>> defines a Tracking Area Identity (TAI) as specified in clause 28.6 of TS 23.003 [5], clause 8.2 of TS 38.300 [33] and clause 9.3.3.11 of TS 38.413 [34]. It is composed of the PLMN identifier (PLMN-Id, which is composed of the MCC and MNC) and the Tracking Area Code (TAC).
4.3.39.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
mcc |
M |
T |
T |
T |
N/A |
|
mnc |
M |
T |
T |
T |
N/A |
|
tac |
M |
T |
T |
T |
N/A |
4.3.40 MbsfnArea <<dataType>>
4.3.40.1 Definition
This <<dataType>> defines a MBSFN area. It is composed of the MBSFN Area identifier and the carrier frequency (EARFCN).
4.3.40.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
mbsfnAreaId |
M |
T |
T |
F |
T |
|
earfcn |
M |
T |
T |
F |
T |
4.3.41 MnsRegistry
4.3.41.1 Definition
This IOC is a container for MnsInfo IOC-s. It can be contained only by SubNetwork IOC. A SubNetwork IOC can contain only one instance of MnsRegistry.
The IOC is instantiated by the system.
4.3.41.2 Attributes
The MnsRegistry IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29).
4.3.41.3 Attribute constraints
None.
4.3.41.4 Notifications
None.
4.3.42 MnsInfo
4.3.42.1 Definition
This IOC represents an available Management Service (MnS) and provides the data required to support its discovery. It is name-contained by MnsRegistry.
This information is used by the consumer to discover the producers of specific Management Services and to derive the addresses of the Management Service.
Attributes mnsLabel, mnsType, and mnsVersion are used to describe the Management Service.
Attribute mnsAddress is used to provide addressing information for the Management Service operations.
Attribute mnsScope is used to provide information about the management scope of the Management Service. The management scope is defined as the set of managed object instances that can be accessed using the Management Service.
4.3.42.2 Attributes
The MnsInfo IOC includes the attributes inherited from Top IOC (defined in clause 4.3.29) and the following attributes:
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
mnsLabel |
M |
T |
F |
F |
T |
|
mnsType |
M |
T |
F |
F |
T |
|
mnsVersion |
M |
T |
F |
F |
T |
|
mnsAddress |
M |
T |
F |
F |
T |
|
mnsScope |
M |
T |
F |
F |
T |
4.3.43 ProcessMonitor <<DataType>>
4.3.43.1 Definition
This data type provides attributes to monitor the progress of processes with specific purpose and limited lifetime running on MnS producers. It may be used as data type for dedicated progress monitor attributes when specifying the management representation of these processes. The attributes in this clause are defined in a generic way. For some attributes specialisations may be provided when specifying a concrete process representation.
If a management operation on some IOCs triggers an associated asynchronous process (whose progress shall be monitored), this should also result in creating an attribute named "processMonitor" (of type "ProcessMonitor") in these IOC(s). The processMonitor attribute may be accompanied by use-case specific additional data items.
The progress of the process is described by the "status" and "progressPercentage" attributes. Additional textual qualifications for the "status" attribute may be provided by the "progessStateInfo" and "resultStateInfo" attributes.
When the process is instantiated, the "status" is set to "NOT_RUNNING" and the "progressPercentage" to "0". The MnS producer decides when to start executing the process and to transition into the "RUNNING" state. This time is captured in the "startTime" attribute. Alternatively, the process may start to execute directly upon its instantiation. One alternative must be selected when using this data type.
During the "RUNNING" state the "progressPercentage" attribute may be repeatedly updated. The exact semantic of this attribute is subject to further specialisation. The "progessInfo" attribute may be used to provide additional textual information in the "NOT_RUNNING", “CANCELLING” and "RUNNING" states. Further specialisation of "progressStateInfo" may be provided where this data type is used.
Upon successful completion of the process, the "status" attribute is set to "FINISHED", the "progressPercentage" to 100%. The time is captured in the "endTime" attribute. Additional textual information may be provided in the "resultStateInfo" attribute. The type of "resultStateInfo" in this data type definition is "String". Further specialisation of "resultStateInfo" may be provided where this data type is used.
In case the process fails to complete successfully, the "status" attribute is set to "FAILED" or "PARTIALLY_FAILED", the current value of "progressPercentage" is frozen, and the time captured in "endTime". The "resultStateInfo" specifies the reason for the failure. Specific failure reasons may be specified where the data type defined in this clause is used. The exact semantic of failure may be subject for further specialisation as well.
In case the process is cancelled, the "status" attribute is first set to "CANCELLING" and when the process is really cancelled then to "CANCELLED". The transition to "CANCELLED" is captured in the "endTime" attribute. The value of "progressPercentage" is frozen. Additional textual information may be provided in the "resultStateInfo" attribute.
The "resultStateInfo" attribute is provided only for additional textual qualification of the states "FINISHED", "FAILED", "PARTIALLY_FAILED" or "CANCELLED". It shall not be used for making the outcome, that the process may produce in case of success, available.
The process may have to be completed within a certain time after its creation, for example because required data may not be available any more after a certain time, or the process outcome is needed until a certain time and when not provided by this time is not needed any more. The time until the MnS producer automatically cancels the process is indicated by the "timer" attribute.
4.3.43.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
id |
M |
T |
F |
F |
T |
|
status |
M |
T |
F |
F |
T |
|
progressPercentage |
O |
T |
F |
F |
T |
|
progressStateInfo |
O |
T |
F |
F |
T |
|
resultStateInfo |
O |
T |
F |
F |
T |
|
startTime |
O |
T |
F |
F |
T |
|
endTime |
O |
T |
F |
F |
T |
|
timer |
O |
T |
T |
F |
F |
4.3.44 Files
4.3.44.1 Definition
This IOC represents a collection of files. It can be name-contained by "SubNetwork", "ManagedElement", "PerfMetricJob" or "TraceJob". The "Files" object name-contains "File" objects, that represent the files of the collection. File collections allow to structure related files under a common root.
Instances of "Files" are created by MnS producers. They shall be created at latest when the first file of the collection becomes available for retrieval by MnS consumers.
The attributes of "Files" represent properties of the file collection and not properties of individual files.
When the file retrieval NRM fragment is used together with a data collection job ("PerfMetricJob" or "TraceJob") the following provisions shall apply:
– The "Files" object shall be created at the same time as the object representing the data collection job.
– The attributes "jobRef" and "jobId" shall be supported and present in a "Files" instance. They shall identify the job that the files in the file collection relate to.
– A "Files" instance shall contain files related to one and only one job.
– The files produced by one job shall be contained in one and only one "Files" instance.
– The job object shall support an attribute with a link to the created "Files" instance ("_linkToFiles").
– The attribute "_linkToFiles" shall be returned in the job creation response, if the stage 3 protocol supports returning attributes in an object creation response.
– The MnS producer decides where to name-contain the "Files" instance related to a job.
The attribute "_linkToFiles" allows a MnS consumer to create simple and targeted subscriptions for "notifyFileReady", "notifyFilePreparationError" and file related notifications "notifyFileDeletion", or "notifyMOICreation","notifyMOIChanges", and "notifyMOIDeletion" related to "File" instances created or deleted under the "Files" instance of a specific job. The subscription needs to scope simply objects one level below the "Files" object.
In addition, the attribute "_linkToFiles" allows for simple deployments not relying on notifications for reporting the availability of new files, where the MnS consumer polls regularly for new files under "Files".
4.3.44.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
numberOfFiles |
M |
T |
F |
F |
F |
|
Attributes related to roles |
|||||
|
jobRef |
CM |
T |
F |
T |
F |
|
jobId |
CM |
T |
F |
T |
F |
4.3.44.3 Attribute constraints
|
Name |
Definition |
|
jobRef Support Qualifier |
Condition: This attribute shall be supported when "PerfMetricJob" or "TraceJob" are supported. |
|
jobId Support Qualifier |
Condition: This attribute shall be supported when "PerfMetricJob" or "TraceJob" are supported. |
4.3.44.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.45 File
4.3.45.1 Definition
This IOC represents a file. It is name-contained by "Files".
When a file becomes available on a MnS producer for retrieval by a MnS consumer, the MnS producer shall create a "File" instance representing that file.
The time of creation shall be captured by the MnS producer in the "fileReadyTime" attribute. The MnS producer shall keep the file at least until the time specified by "fileExpirationTime". After that time the MnS producer may delete the "File" instance. The "fileExpirationTime" is determined by the MnS producer based on considerations such as available storage space or file retention policies.
The attributes "fileSize", "fileCompression", "fileDataType" and "fileFormat" describe the file properties.
The "fileLocation" attribute indicates the address where the file can be retrieved. The address includes the file transfer protocol (schema). Allowed file transfer protocols are "sftp", "ftpes" and "https".
The value of "fileLocation" can be identical to or different from the address of the "File" instance. The attribute "fileContent" is provided for retrieving the actual file content. When identifying in the Read request a "File" instance and specifying only the "fileContent" attribute be returned, then only the file content shall be returned in the response. Note, as usual, multiple attributes can be specified to be returned, so that the file content together with some or all file meta data attributes can be returned in response to a single request.
In case the "fileLocation" specifies a location different than the "File" object location, then the attribute "fileContent" cannot be used for retrieving the file content. For example, the "File" object location may be given by
"https://companyA.com/ManagedElement=1/Files=1/File=1
and the value of the "fileLocation" attribute by
"sftp://companyA.com/datastore/fileName.xml"
In this case the file needs to be retrieved using "sftp" from "sftp://companyA.com/datastore/fileName.xml". Attempts to read the "fileContent" attribute shall return an error.
When the file retrieval NRM fragment is used together with a data collection job ("PerfMetricJob" or "TraceJob") the following provisions shall apply:
– The attributes "jobRef" and "jobId" shall be supported and present. They shall identify the job that the file is related to.
The attributes "jobRef" and "jobId" allow to set notification filters in the subscription in such a way that only "notifyMOICreation", "notifyMOIDeletion" and "notifyMOIChanges" notifications are sent to subscribed MnS consumers if the created or deleted "File" instance represents data related to jobs the subscribed MnS consumer created or is interested in.
Upon creation of a "File" instance, a notification of type "notifyMOICreation" or"notifyMOIChanges" shall be emitted to subscribed MnS consumers as usual. For the case that the file contains performance metric data ("fileDataType" is "PERFORMANCE") the MnS producer shall emit either a notification of type "notifyMOICreation" or"notifyMOIChanges" or of type "notifyFileReady". The MnS consumer selects the notification type he wishes to receive with the subscription created on the MnS producer.
The "objectClass" and "objectInstance" parameters in the notification header of "notifyFileReady" shall identify the new "File" instance, instead of the related "PerfMetricJob", "TraceJob", "ManagedElement" or "ManagementNode"as described in TS 28.532 [27], clause 11.6.1.1.1 for the case that "notifyFileReady" is used as part of the file data reporting MnS.
The notification "notifyFilePreparationError" shall be supported as well by the "File" object. It shall be sent when an error occurs during the preparation of the file. No "notifyFileReady" or "notifyMOICreation" or "notifyMOIChanges" shall be sent in that case. The "objectClass" and "objectInstance" parameters of the notification header shall identify the new "File" instance representing the corrupted file, instead of the related "PerfMetricJob", "TraceJob", "ManagedElement" or "ManagementNode"as described in 3GPP TS 28.532 [27], clause 11.6.1.1.1 for the case that "notifyFilePreparationError" is used as part of the file data reporting MnS. When the file is not created at all or deleted, the "objectClass" and "objectInstance" parameters of the notification header are populated as described in 3GPP TS 28.532 [27], clause 11.6.1.1.1. Note that to receive "notifyFilePreparationError" in that case the notification subscription needs to include these objects in its scope.
4.3.45.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
fileLocation |
M |
T |
F |
T |
F |
|
fileCompression |
M |
T |
F |
T |
F |
|
fileSize |
O |
T |
F |
T |
F |
|
fileDataType |
O |
T |
F |
T |
F |
|
fileFormat |
O |
T |
F |
T |
F |
|
fileReadyTime |
O |
T |
F |
T |
F |
|
fileExpirationTime |
O |
T |
F |
T |
F |
|
fileContent |
M |
T |
F |
T |
F |
|
Attributes related to roles |
|||||
|
jobRef |
CM |
T |
F |
T |
F |
|
jobId |
CM |
T |
F |
T |
F |
4.3.45.3 Attribute constraints
|
Name |
Definition |
|
jobRef Support Qualifier |
Condition: This attribute shall be supported when "PerfMetricJob" or "TraceJob" are supported. |
|
jobId Support Qualifier |
Condition: This attribute shall be supported when "PerfMetricJob" or "TraceJob" are supported. |
4.3.45.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyFileReady |
M |
|
|
notifyFilePreparationError |
M |
4.3.46 FileDownloadJob
4.3.46.1 Definition
The "FileDownloadJob" represents a job on a MnS producer that downloads a file to the MnS producer. It can be name-contained by "ManagedElement" or "SubNetwork".
A "FileDownloadJob" is created by a MnS consumer to request that the MnS producer download a file from a specified location. The creation request contains the information required by the MnS producer to download the file, namely the attribute "fileLocation".
The creation request may contain as well a "notificationRecipientAddress". If present, this attribute instructs the MnS producer to create, on behalf of the MnS consumer, a subscription for attribute value change notifications of the new "FileDownloadJob" (implicit notification subscription). In case the MnS producer supports the notification type "notifyMOIChanges", the created subscription shall be for this type, otherwise for "notifyMOIAttributeValueChanges". The MnS consumer needs to be prepared to receive either of them. The "notificationRecipientAddress" attribute of the created "NtfSubscriptionControl" object shall be set to the value of the "notificationRecipientAddress" in the "FileDownloadJob" creation request.
The "jobMonitor" attribute represents the status of a file download job and includes information the MnS consumer can use to monitor the progress and result of the file download job. The data type of this attribute is "ProcessMonitor". The following specialisations are provided for this data type for the file download job:
– The "status" attribute values are "NOT_STARTED", "RUNNING", "CANCELLING", "FINISHED, "FAILED" and "CANCELLED". The values "SUSPENDED" and "PARTIALLY_FAILED" are not used.
– The MnS consumer can set the value of the "timer" attribute to specify the time by which the file download is expected to complete, i.e. to indicate how long the file is available for download. If the timer expires before the MnS producer has finished the job the "status" is set to "FAILED" and "resultStateInfo" is set to "TIMER_EXPIRED".
– The "progessPercentage" attribute indicates how much percent of the file is already downloaded as measured by downloaded bytes from total file size in bytes.
– No specialisations are provided for the "progressStateInfo" attribute. Vendor specific information may be provided though.
– For the case that the "status" is equal to "FAILED" the "resultStateInfo" attribute shall indicate one of the following failure reasons: "UNKNOWN", "NO_STORAGE", "LOW_MEMROY", "NO_CONNECTION_TO_REMOTE_SERVER", "FILE_NOT_AVAILABLE", "DNS_CANNOT_BE_RESOLVED", "TIMER_EXPIRED", "OTHER".
– For the case that the "status" is equal to "FINISHED" or "CANCELLED" no specialisations are provided for the "resultStateInfo" attribute. Vendor specific information may be provided though.
Once the job is complete with "jobStatus" equal to "FINISHED", "CANCELLED", or "FAILED" the MnS consumer shall delete the "FileDownloadJob". The MnS producer may also delete the "FileDownloadJob".
4.3.46.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
fileLocation |
M |
T |
T |
T |
F |
|
notificationRecipientAddress |
O |
T |
T |
T |
F |
|
cancelJob |
M |
T |
T |
F |
T |
|
jobMonitor |
M |
T |
T |
F |
T |
4.3.46.3 Attribute constraints
None.
4.3.46.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC, without exceptions or additions.
4.3.42.3 Attribute constraints
None.
4.3.42.4 Notifications
The configuration notifications defined in clause 4.5.2 are valid for this IOC.
4.3.47 ManagementDataCollection
4.3.47.1 Definition
This IOC represents a management data collection request job. The requested data could be of kind Trace, MDT (Minimization of Drive Test), RLF (Radio Link Failure) report, RCEF (RRC Connection Establishment Failure) report, PM (performance measurements), KPI (end-to-end key performance indicators) or a combination of these.
The attribute "managementData" defines the management data which shall be reported. This may either include a list of data categories or a list of management data identified with their name. For further details see clause 4.3.50. The "targetNodeFilter" attribute can be used to target object instance(s) producing the required management data. It is assumed that the consumer may not have detailed knowledge of the network and hence may not identify the exact object instance producing the required management data. In this case consumer can request management data, specified by 3GPP, produced by certain object instance (s) based on a particular location, the domain (CN or RAN) of theobject instances, and the handled traffic (CP or UP) of the object instances.
To activate the production of the requested data, a MnS consumer has to create a "ManagementDataCollection" object instance on the MnS producer.
The MnS producer may derive multiple jobs ("PerfMetricJob", "TraceJob") from a single "ManagementDataCollection" job for collecting the required management data. If the MnS producer receives the collected data from multiple sources, it consolidate the data into a set of management data for reporting.
The attribute "collectionTimeWindow" specifies the time window for which the management data should be reported.
The attribute "reportingCtrl" specifies the method and associated control parameters for reporting the produced management data to MnS consumers. Three methods are available: file-based reporting with selection of the file location by the MnS producer, file-based reporting with selection of the file location by the MnS consumer and stream-based reporting.
The attribute "dataScope" configures, whether the management data should be reported per S-NSSAI or per 5QI, if applicable.
4.3.47.2 Attributes
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
managementData |
M |
T |
T |
T |
N/A |
|
targetNodeFilter |
M |
T |
T |
T |
N/A |
|
collectionTimeWindow |
M |
T |
T |
T |
N/A |
|
reportingCtrl |
M |
T |
T |
T |
N/A |
|
dataScope |
O |
T |
T |
T |
N/A |
4.3.47.3 Attribute constraints
None.
4.3.47.4 Notifications
The common notifications defined in clause 4.5 are valid for this IOC. In addition, the following set of notifications is also valid.
|
Name |
S |
Notes |
|---|---|---|
|
notifyFileReady |
M |
— |
|
notifyFilePreparationError |
M |
— |
4.3.48 TimeWindow <<dataType>>
4.3.48.1 Definition
This data type defines the start time and end time for which the management data should be reported.
4.3.48.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
startTime |
M |
T |
T |
T |
T |
|
endTime |
M |
T |
T |
T |
T |
4.3.48.3 Attribute constraints
None.
4.3.48.4 Notifications
The clause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.49 NodeFilter <<dataType>>
4.3.49.1 Definition
This data type defines several selection criteria for the target node(s) i.e., the node(s) producing the requested management data.
The attribute "areaOfInterest" determines the location for which the management data is collected. The system translates the area into the target managed objects. The location is either configured by a list of TAI, a list of cells (identified either by NG-RAN CGI, E-UTRAN CGI or UTRAN CGI) or by a geographical area. The geographical area will be mapped to the cells providing coverage for this area. The cell coverage status at the time of the request is used for the mapping. Managed objects providing service to these cells are considered as target managed objects. Furthermore, an object which name contains or is associated to a managed object providing service to the considered cell, is considered as target managed object as well.
The attribute "networkDomain" is used to select a particular domain (e.g. RAN, CN) for which the management data is collected. The system translates this information into the target managed objects. Managed objects from this selected particular domain (e.g RAN, CN) are considered as target managed objects. Furthermore, an object which name contains or is associated to a managed object of that domain, is considered as target managed object as well.
The attribute "cpUpType" is used to select the traffic type (CP, UP) for which the management data is collected. The system translates this information into the target managed objects. Managed objects catering particular traffic type (CP, UP) are considered as target managed objects. Furthermore, an object which name contains or is associated to a managed object of that traffic type, shall be considered as target managed object as well.
The attribute "sst" is used to select the SST (Slice/Service Type)[22] for which the management data is collected. The system translates this information into the target managed objects. Managed objects related to particular SST will be considered as target managed objects.
If it is not possible to select the target node(s) (based on a particular selection criteria) deterministically, the selection criteria should not be used.
4.3.49.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
areaOfInterest |
O |
T |
T |
T |
N/A |
|
networkDomain |
O |
T |
T |
T |
N/A |
|
cpUpType |
O |
T |
T |
T |
N/A |
|
sst |
O |
T |
T |
T |
N/A |
4.3.49.3 Attribute constraints
None.
4.3.49.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.
4.3.50 ManagementData <<choice>>
4.3.50.1 Definition
This <<choice>> defines the management data which is requested. It is a choice between
– a list of data categories (attribute mgtDataCategory) This may include "COVERAGE", "CAPACITY", "MOBILITY", "ENERGY_EFFICIENCY", "ACCESSIBILITY" etc. The mapping of exact measurement with the requested category will be done at the producer and is implementation specific.
– a list of management data identified with their name (attribute "mgtDataName"). The management data name presents a specific single measurement (e.g. by selecting "RRU.PrbTotDl", see TS 28.552 [20] or "immediateMdt.nr.m1", see TS 32.422 [30]) or a set of measurements (e.g. measurement families such as RRU (radio resource utilization) or MM (mobility management) in case of PM, see TS 28.552 [20], or group of measurements such as "immediateMdt.nr" in case of MDT, see TS 32.422 [30]).
4.3.50.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
CHOICE_1.1 mgtDataCategory |
M |
T |
T |
T |
N/A |
|
CHOICE_2.1 mgtDataName |
M |
T |
T |
T |
N/A |
4.3.51 AreaOfInterest <<choice>>
4.3.51.1 Definition
This <<choice>> defines the area which shall be considered for the service.
4.3.51.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
CHOICE_1.1 geoAreaToCellMapping |
M |
T |
T |
T |
N/A |
|
CHOICE_2.1 taiList |
M |
T |
T |
T |
N/A |
|
CHOICE_3.1 nrCellIdList |
M |
T |
T |
T |
N/A |
|
CHOICE_4.1 eutraCellIdList |
M |
T |
T |
T |
N/A |
|
CHOICE_5.1 utraCellIdList |
M |
T |
T |
T |
N/A |
4.3.51.3 Attribute constraints
|
Name |
Definition |
|
CHOICE_1.1 geoAreaToCellMapping |
This attribute shall be supported, when a service is requested for a geographical area. |
|
CHOICE_2.1 taiList |
This attribute shall be supported, when a service is requested for TAI. |
|
CHOICE_3.1 nrCellIdList |
This attribute shall be supported, in case of NR cells. |
|
CHOICE_4.1 eutraCellIdList |
This attribute shall be supported, in case of E-UTRAN cells. |
|
CHOICE_5.1 utraCellIdList |
This attribute shall be supported, in case of UTRA cells. |
4.3.52 GeoAreaToCellMapping <<dataType>>
4.3.52.1 Definition
This data type contains a geographical area and an association threshold. The geo-area is defined as a convex polygon using the attribute "geoArea".
The MnS producer shall map the geographical area to cells. There are two evaluation criteria whether a cell belongs to a geographical area or not. If attribute "associationThreshold" is absent, the location of the base station antenna determines the belonging. If attribute "associationThreshold" is configured, the coverage area is considered. The attribute "associationThreshold" determines the lower boundary of the coverage ratio. For example, if the "associationThreshold" is configured to 60%, a cell shall be considered as included in the geographical area if at least 60% of the coverage area of that cell overlaps with the specified geographical area.
The mapping of the geographical area to cells is performed at instantiation of the IOC.
4.3.52.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
geoArea |
M |
T |
T |
F |
N/A |
|
associationThreshold |
O |
T |
T |
T |
N/A |
4.3.53 GeoCoordinate <<dataType>>
4.3.53.1 Definition
This data type defines a geographical location on earth.
4.3.53.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
latitude |
M |
T |
T |
F |
T |
|
longitude |
M |
T |
T |
F |
T |
4.3.54 QMCJob
4.3.54.1 Definition
The QoE Measurement Collection provides capability for collecting QoE information from:
– UEs which are in the specified area in case of Management Based Activation or
– an individual UE in case of Signalling Based Activation.
The QoE Measurement Collection enables collection of application layer measurements from the UE for specified end user service type. The supported service types are:
– Streaming services, see TS 26.247 [51].
– MTSI services, see TS 26.114 [52].
– VR services, see TS 26.118 [53].
A QMCJob instance represents the job for collecting QoE measurements according to the job parameters. For details of the QoE measurement collection configuration parameters see clause 5 of TS 28.405 [50]. A QMCJob instance can be name-contained by SubNetwork or ManagedElement.
A QMC Job is activated by creating a QMCJob object instance in the MnS producer. For details of Management Based Activation of QoE Measurement Collection see clause 4.5 and for details of Signalling Based Activation of QoE Measurement Collection see clause 4.6 of TS 28.405 [50]. The attributes areaScope and pLMNTarget are only relevant when Management Based Activation is used and the attribute qoETarget is only relevant when Signalling Based Activation is used. All other attributes are common for both Management Based Activation and Signalling Based Activation.
When a MnS consumer wishes to deactivate a QMC Job, the MnS consumer shall delete the corresponding QMCJob instance.
NOTE: If the reporting is ongoing, when a request to delete a QMCJob instance is received, the reporting does not end. The QMCJob instance is deleted, when the last reporting for the QMC Job expires.
The jobId attribute presents the job identifier of a QMCJob instance. The jobId can be used to associate multiple QMCJob instances. For example, it is possible to configure the same jobId value for multiple QMCJob instances required to produce the data (e.g. Streaming services and MTSI reports) for a specific network analysis.
4.3.54.2 Attributes
The QMCJob IOC includes attributes inherited from TopX IOC (defined in clause 4.3.8) and the following attributes:
|
Attribute Name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
serviceType |
M |
T |
T |
F |
T |
|
areaScope |
CM |
T |
T |
F |
T |
|
qoECollectionEntityAddress |
M |
T |
T |
F |
T |
|
pLMNTarget |
CM |
T |
T |
F |
T |
|
qoETarget |
CM |
T |
T |
F |
T |
|
qoEReference |
M |
T |
T |
F |
T |
|
jobId |
O |
T |
T |
T |
T |
|
sliceScope |
CM |
T |
T |
F |
T |
|
qMCConfigFile |
M |
T |
T |
F |
T |
|
mDTAlignmentInformation |
O |
T |
T |
F |
T |
|
availableRANqoEMetrics |
O |
T |
T |
F |
T |
4.3.54.3 Attribute constraints
|
Name |
Definition |
|
areaScope (support qualifier) |
This attribute shall be present when Management Based Activation is used. |
|
pLMNTarget (support qualifier) |
This attribute shall be present when Management Based Activation is used and if network sharing is deployed. |
|
qoETarget (support qualifier) |
This attribute shall be present when Signalling Based Activation is used. |
|
sliceScope (support qualifier) |
This attribute shall be present when the QMC is targeting specific slice(s). |
4.3.54.4 Notifications
The common notifications defined in clauses 4.5.1 and 4.5.2 are valid for this IOC, without exceptions.
4.3.55 GeoArea <<datatype>>
4.3.55.1 Definition
This data type defines a geographical area. The geo-area is defined using a convex polygon in the attribute "convexGeoPolygon".
4.3.55.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
convexGeoPolygon |
M |
T |
T |
F |
N/A |
4.3.56 ExcessPacketDelayThresholds <<dataType>>
4.3.56.1 Definition
This <<dataType>> defines a excess packet delay threshold information to enable the calculation of the PDCP Excess Packet Delay in the uplink in case of M6 uplink measurements are requested. The excess packet delay threshold information is specified with the 5QI value and excess packet delay threshold value.
4.3.56.2 Attributes
|
Attribute name |
S |
isReadable |
isWritable |
isInvariant |
isNotifyable |
|
fiveQIValue |
M |
T |
T |
F |
T |
|
excessPacketDelayThresholdValue |
M |
T |
T |
F |
T |
4.3.56.3 Attribute constraints
None
4.3.56.4 Notifications
The subclause 4.5 of the <<IOC>> using this <<dataType>> as one of its attributes, shall be applicable.