6 Information Object Class (IOC) definitions

32.6223GPPConfiguration Management (CM)Generic network resources Integration Reference Point (IRP)Network Resource Model (NRM)Release 11Telecommunication managementTS

6.1 Information Object Classes

6.1.1 Imported Information entities and local labels

Label reference

Local label

3GPP TS 32.111-2 [11], notification, notifyAckStateChanged

notifyAckStateChanged

3GPP TS 32.662 [17], notification, notifyAttributeValueChanged

notifyAttributeValueChanged

3GPP TS 32.111-2 [11], notification, notifyChangedAlarm

notifyChangedAlarm

3GPP TS 32.111-2 [11], notification, notifyClearedAlarm

notifyClearedAlarm

3GPP TS 32.111-2 [11], notification, notifyComments

notifyComments

3GPP TS 32.111-2 [11], notification, notifyNewAlarm

notifyNewAlarm

3GPP TS 32.662 [17], notification, notifyObjectCreation

notifyObjectCreation

3GPP TS 32.662 [17], notification, notifyObjectDeletion

notifyObjectDeletion

3GPP TS 32.111-2 [11], notification, notifyAlarmListRebuilt

notifyAlarmListRebuilt

3GPP TS 32.111-2 [11], notification, notifyPotentialFaultyAlarmList

notifyPotentialFaultyAlarmList

3GPP TS 32.532 [19], notification, notifyDownloadNESwStatusChanged

notifyDownloadNESwStatusChanged

3GPP TS 32.532 [19], notification, notifyInstallNESwStatusChanged

notifyInstallNESwStatusChanged

3GPP TS 32.532 [19], notification, notifyActivateNESwStatusChanged

notifyActivateNESwStatusChanged

3GPP TS 32.312 [5], Support IOC, ManagedGenericIRP

ManagedGenericIRP

6.1.2 Class diagram

6.1.2.1 Attributes and relationships

This clause depicts the set of classes (e.g. IOCs) that encapsulates the information relevant for this IRP. This clause provides an overview of the relationships between relevant classes in UML. Subsequent clauses provide more detailed specification of various aspects of these classes. Figure 6.1 shows the containment/naming hierarchy and the associations of the classes defined in the present document.

NOTE 1: ManagedElement may be contained in either a SubNetwork or a MeContext instance, or have no parent instance at all.

NOTE 2: MeContext may either be contained in a SubNetwork instance or have no parent instance at all.

NOTE 3: Each instance of the VsDataContainer shall only be contained under one IOC instance. The VsDataContainer can be contained under IOCs defined in other NRM IRPs.

NOTE 4: If the configuration contains several instances of SubNetwork, exactly one SubNetwork instance shall directly or indirectly contain all the other SubNetwork instances.

NOTE 5: The SubNetwork instance not contained in any other instance of SubNetwork is referred to as "the root SubNetwork instance".

NOTE 6: ManagementNode shall be contained in the root SubNetwork instance.

NOTE 7: If contained in a SubNetwork instance, IRPAgent shall be contained in the root SubNetwork instance.

NOTE 8: For a clarification on the choice of containment of the IRPAgent (since it has three possible parents), see the def. of IRPAgent.

Figure 6.1: Generic NRM Containment/Naming and Association diagram

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses its containment hierarchy. As an example, the DN of a ManagedElement instance could have a format like:

SubNetwork=Sweden,MeContext=MEC-Gbg-1,ManagedElement=RNC-Gbg-1.

NOTE 1: Void

NOTE 2: Each instance of the VsDataContainer shall only be contained under one IOC. The VsDataContainer can be contained under IOCs defined in other NRMs by virtue of inheritance from the GENERIC NRM.

Figure 6.2: VsDataContainer Containment/Naming and Association in GENERIC NRM diagram

The VsDataContainer is only used for the Bulk CM IRP.

6.1.2.2 Inheritance

This clause depicts the inheritance relationships that exist between information object classes.

Figure 6.3 shows the inheritance diagram.

Figure 6.3: Generic Network Resource Model IRP Inheritance Hierarchy

6.1.3 Information object class definitions

6.1.3.1 Any

6.1.3.1.1 Definition

This class represents the classes (e.g. IOC or SupportIOC) that are not defined in this specification but are or will be defined in other IRP specification(s).

6.1.3.2 IRPAgent

6.1.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.
6.1.3.2.2 Attributes

Attributes of IRPAgent

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

iRPAgentId

M

M

systemDN

C

M

6.1.3.2.3 Void
6.1.3.2.4 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

6.1.3.3 ManagedElement

6.1.3.3.1 Definition

This IOC represents telecommunications equipment or TMN entities within the telecommunications network that performs Managed Element (ME) functions, i.e. provides support and/or service to the subscriber.
An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being monitored and/or controlled. MEs may or may not additionally perform element management functionality.
An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a "Network Element".

A ManagedElement may be contained in either a SubNetwork or in a MeContext instance. A single ManagedElement seen over the Itf-N may also exist stand-alone with no parent at all.

The ManagedElement IOC may be used to represent combined ME functionality (as indicated by the managedElementType attribute and the contained instances of different functional IOCs).

Single function ManagedElement IOC instances will have a 1..1 containment relationship to a function IOC instance (in this context a function IOC instance is an instance of an IOC derived from the ManagedFunction IOC). Multiple function ManagedElement instances will have a 1..N containment relationship to function IOC instances.

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.

6.1.3.3.2 Attributes

Attributes of ManagedElement

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

managedElementId

M

M

dnPrefix

M

M

managedElementType

M

M

userLabel

M

M

M

vendorName

M

M

userDefinedState

M

M

M

locationName

M

M

swVersion

M

M

managedBy

M

M

6.1.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.

6.1.3.3.4 Void
6.1.3.3.5 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

In addition, the following notifications are specific to only ManagedElement IOC.

Name

Qualifier

Notes

notifyDownloadNESwStatusChanged

See Software Management IRP (3GPP TS 32.532 [19])

notifyInstallNESwStatusChanged

See Software Management IRP (3GPP TS 32.532 [19])

notifyActivateNESwStatusChanged

See Software Management IRP (3GPP TS 32.532 [19])

6.1.3.4 ManagedFunction

6.1.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. The ManagedFunction may be extended in the future if more common characteristics to functional objects are identified.

6.1.3.4.2 Attributes

Attributes of ManagedFunction

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

userLabel

M

M

M

6.1.3.5 ManagementNode

6.1.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.

6.1.3.5.2 Attributes

Attributes of ManagementNode

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

managementNodeId

M

M

userLabel

M

M

M

vendorName

M

M

userDefinedState

M

M

M

locationName

M

M

swVersion

M

M

managedElements

M

M

6.1.3.5.3 Void
6.1.3.5.4 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

6.1.3.6 MeContext

6.1.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:

  1. all LDNs or DNs are locally modified using the new dnPrefix for the upper portion of the DNs, or
  2. 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.

6.1.3.6.2 Attributes

Attributes of MeContext

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

meContextId

M

M

dnPrefix

M

M

6.1.3.6.3 Attribute constraints

Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of MeContext is the local root instance of the MIB. Otherwise the attribute shall be absent or carry no information.

6.1.3.6.4 Void
6.1.3.6.5 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

6.1.3.7 SubNetwork

6.1.3.7.1 Definition

This IOC represents a set of managed entities as seen over the Itf-N.

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".

6.1.3.7.2 Attributes

Attributes of SubNetwork

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

subNetworkId

M

M

dnPrefix

M

M

userLabel

M

M

M

userDefinedNetworkType

M

M

setOfMcc

M

M

6.1.3.7.3 Attribute constraints

Attribute constrains for dnPrefix: The attribute dnPrefix shall be supported if an instance of SubNetwork is the local root instance of the MIB. Otherwise the attribute shall be absent or carry no information.

Attribute constrains for setOfMcc: If there may be more than one MCC value in the SubNetwork instance, the attribute setOfMcc is mandatory. Otherwise it is optional.

6.1.3.7.4 Void
6.1.3.7.5 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

6.1.3.8 Top

6.1.3.8.1 Definition

This IOC is introduced for generalisation purposes. All information object classes defined in all TS that claim to be conformant to 32.102 [2] shall inherit from Top.

6.1.3.8.2 Attributes

Attributes of Top

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

objectClass

M

M

objectInstance

M

M

6.1.3.9 VsDataContainer

6.1.3.9.1 Definition

The VsDataContainer managed object is a container for vendor specific data. The number of instances of the VsDataContainer can differ from vendor to vendor. This IOC shall only be used by the Bulk CM IRP for all the NRMs.

6.1.3.9.2 Attributes

Attributes of VsDataContainer

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

vsDataContainerId

M

M

vsDataType

M

M

vsData

M

M

O

vsDataFormatVersion

M

M

6.1.3.10 Link

6.1.3.10.1 Definition

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.

This IOC cannot be instantiated. It is defined for sub-classing purposes.

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 6.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.

6.1.3.10.2 Attributes

Attributes of Link

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

linkId

M

M

userLabel

M

M

M

aEnd

M

M

zEnd

M

M

linkType

O

M

protocolName

O

M

protocolVersion

O

M

6.1.3.10.3 Void
6.1.3.10.4 Notifications

The common notifications defined in subclause 6.1.6 are valid for this IOC, without exceptions or additions.

6.1.3.11 EP_RP

6.1.3.11.1 Definition

This IOC represents an end point of a link used across a reference point between two network entities.

This IOC cannot be instantiated. It is defined for sub-classing purposes. The detailed subclassed IOC, e.g. EP_X2, will be defined in E-UTRAN NRM IRP, by inheriting from this EP_RP.

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.

6.1.3.11.2 Attributes

Attributes of EP_RP

Attribute Name

Support Qualifier

Read Qualifier

Write Qualifier

id

M

M

farEndEntity

O

M

userLabel

O

M

M

6.1.4 Information relationship definitions

6.1.4.1 ManagementScope (M)

6.1.4.1.1 Definition

This association is used to represent relationships between one or more MEs and the ManagementNode that is responsible for managing the MEs. It has two roles, named Manager and Subordinate. The role Manager models the fact that a ManagementNode is responsible for managing zero or more MEs, and the role Subordinate models the fact that an ME is managed by zero or one ManagementNode. Each role is in the IOC definition mapped to a reference attribute with the same name.

6.1.4.1.2 Roles

The roles involved in the relation ManagementScope are listed in the following table.

Roles of the relation ManagementScope

Name

Definition

Manager

This role represents the ManagementNode’s capability to identify the set of related ManagedElements. This role is modelled by a reference attribute named managedElements. ManagementNode.managedElements shall carry the set of ManagedElement DN(s).

Subordinate

This role represents the ManagedElement’s capability to identify the set of related managementNode(s). This role is modelled by a reference attribute named managedBy. ManagedElement.managedBy shall carry the set of ManagementNode DN(s).

6.1.4.1.3 Constraints

Name

Definition

6.1.5 Information attribute definitions

6.1.5.1 Definitions and legal values

The following table defines the attributes that are present in several information object classes of the present document.

Attributes

Attribute Name

Definition

Legal Values

aEnd

The value of this attribute shall be the Distinguished Name of the alphabetically first instance in the Link subclass name to which this link/relation is associated (i.e., pointing to the instance of <X> as described in the definition of Link IOC in the present document).
As an example, with Link_As_Slf, aEnd would contain the Distinguished Name of the AsFunction instance, and the zEnd would contain the Distinguished Name of SlfFunction instance.
Note that if the <X> and <Y> substrings as part of the Link subclass name are the same (e.g., Link_Bgcf_Bgcf), no ordering can be implied.

Single DN string as defined in TS 32.300 [13]

dnPrefix

It carries the DN Prefix information as defined in Annex C of 32.300 [13] or no information.

farEndEntity

The value of this attribute shall be the Distinguished Name of the far end network entity to which the reference point is related.

As an example, with EP_Iucs, if the instance of EP_Iucs is contained by one RncFunction instance, the farEndEntity is the Distinguished Name of the MscServerFunction instance to which this Iucs reference point is related.

id

An attribute whose "name+value" can be used as an RDN when naming an instance of the object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

linkId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of the link object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

Values to be conformant with TS 32.300 [13]

managedElementId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of the ManagedElement object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

managedElementType

The type of managed element. It is a multi-valued attribute with one or more unique elements. Thus, it may represent one ME functionality or a combination of more than one functionality.

The actual syntax and encoding of this attribute is Solution Set specific.

The legal values of this attribute are the names of the IOC(s) that are (a) derived/subclassed from ManagedFunction and (b) directly name-contained by ManagedElement IOC (on the first level below ManagedElement), but with the string “Function” excluded.

If a ManagedElement contains multiple instances of a ManagedFunction this attribute will not contain repeated values.

The capitalisation (usage of upper/lower case) of characters in this attribute is insignificant. Thus, the IRPManager should be case insensitive when reading these values.

Two examples of legal values are:

  • NodeB;
  • HLR,VLR.

irpAgentId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of this object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

iRPId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of this object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

linkType

This attribute defines the type of the link.

Signalling, Bearer, OAM&P, Other or multiple combinations of the above types.

locationName

The physical location of this entity (e.g. an address).

managedElements

Models the role Manager – see clause 6.1.4.1.2. This attribute contains a list of the DN(s) of the related ManagedElement instance(s).

managementNodeId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of this object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

managedBy

Models the role Subordinate – see clause 6.1.4.1.2. This attribute contains a list of the DN(s) of the related ManagementNode instance(s).

meContextId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of this object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

objectClass

An attribute which captures the name of the class from which the object instance is an occurrence of.

objectInstance

An information which captures the Distinguished Name of any object.

protocolName

Name(s) and additional descriptive information for the protocol(s) used for the associated communication link. Syntax and semantic is not specified.

protocolVersion

Versions(s) and additional descriptive information for the protocol(s) used for the associated communication link. Syntax and semantic is not specified.

setOfMcc

Set of Mobile Country Code (MCC). The MCC uniquely identifies the country of domicile of the mobile subscriber. MCC is part of the IMSI (Ref. 3GPP TS 23.003).

This list contains all the MCC values in subordinate object instances to this SubNetwork instance.

Every unique value of MCC shall only appear once in the list.

subNetworkId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of the SubNetwork object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

swVersion

The software version of the ManagementNode or ManagedElement (this is used for determining which version of the vendor specific information is valid for the ManagementNode or ManagedElement).

systemDN

The Distinguished Name (DN) of IRPAgent. Defined in 3GPP TS 32.300.

userDefinedNetworkType

Textual information regarding the type of network, e.g. UTRAN.

userDefinedState

An operator defined state for operator specific usage. (See also Note below)

userLabel

A user-friendly (and user assignable) name of this object.

vendorName

The name of the vendor.

vsData

Vendor specific attributes of the type vsDataType. The attribute definitions including constraints (value ranges, data types, etc.) are specified in a vendor specific data format file.

vsDataContainerId

An attribute whose ‘name+value’ can be used as an RDN when naming an instance of this object class. This RDN uniquely identifies the object instance within the scope of its containing (parent) object instance.

vsDataFormatVersion

Name of the data format file, including version.

vsDataType

Type of vendor specific data contained by this instance, e.g. relation specific algorithm parameters, cell specific parameters for power control or re-selection or a timer. The type itself is also vendor specific.

zEnd

The value of this attribute shall be the Distinguished Name of the alphabetically second instance in the Link subclass name to which this link/relation is associated (i.e., pointing to the instance of <Y> as described in the definition of Link IOC in the present document).
As an example, with Link_As_Slf, aEnd would contain the Distinguished Name of the AsFunction instance, and the zEnd would contain the Distinguished Name of SlfFunction instance.
Note that if the <X> and <Y> substrings as part of the Link subclass name are the same (e.g., Link_Bgcf_Bgcf), no ordering can be implied.

Single DN string as defined in TS 32.300 [13]

6.1.5.2 Constraints

Name

Definition

6.1.6 Common Notifications

This subclause presents a list of notifications that can be referred to by any IOC defined by this IRP specification.
These notifications are only applicable to IOCs referring to this subclause.

Notifications

Name

Qualifier

Notes

notifyAckStateChanged

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyAttributeValueChange

O

notifyChangedAlarm

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyClearedAlarm

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyNewAlarm

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyObjectCreation

O

notifyObjectDeletion

O

notifyComments

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyAlarmListRebuilt

See Alarm IRP (3GPP TS 32.111-2 [11])

notifyPotentialFaultyAlarmList

See Alarm IRP (3GPP TS 32.111-2 [11])

6.1.7 Particular information configurations

Not applicable.

Annex A (informative):
Void

Annex B (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Cat

Old

New

Jun 2001

SA_12

SP-010283

Approved at TSG SA #12 and placed under Change Control

2.0.0

4.0.0

Sep 2001

SA_13

SP-010479

0001

Add the notification notifyComments in all MOCs that support alarms and correct the list of allowed members of the attribute managedElementType of the MOC managedElement

F

4.0.0

4.1.0

Sep 2001

SA_13

SP-010479

0002

Correction of Generic NRM Containment/Naming and Association diagram

F

4.0.0

4.1.0

Sep 2001

SA_13

SP-010479

0003

Correct description of swVersion attribute

F

4.0.0

4.1.0

Mar 2002

SA_15

SP-020020

0004

Addition of managedElementType value for GSM Radio Access Network support

F

4.1.0

4.2.0

Jun 2002

SA_16

SP-020299

0005

Remove R99-inherited restriction of self-containment for MOC SubNetwork

F

4.2.0

4.3.0

Sep 2002

SA_17

SP-020488

0006

Upgrade to Rel-5 (Add new IS method, MOC name convention)

C

4.3.0

5.0.0

Jun 2003

SA_20

SP-030280

0008

Correction of Notifications for IOCs

A

5.0.0

5.1.0

Dec 2003

SA_22

SP-030643

0010

Add Missing VsDataContainer for ManagedFunction & ManagedElement and Other IOCs (Version 2)

F

5.1.0

5.2.0

Dec 2003

SA_22

SP-030644

0011

Correction of UML diagram and other corrections

F

5.1.0

5.2.0

Dec 2003

SA_22

SP-030648

0012

Add SetofMcc attribute in Generic NRM IOCs for NRM alignment

B

5.2.0

6.0.0

Mar 2004

SA_23

SP-040128

0014

Addition of missing attributes for the managementScope association

A

6.0.0

6.1.0

Jun 2004

SA_24

SP-040249

0016

Add missing attribute constraints for dnPrefix

A

6.1.0

6.2.0

Jun 2004

SA_24

SP-040251

0018

Correction of legal values for managedElementType attribute

A

6.1.0

6.2.0

Dec 2004

SA_26

SP-040808

0020

Correct the write qualification for VsDataContainer.vsData

F

6.2.0

6.3.0

Dec 2004

SA_26

SP-040808

0021

Correction of modelling of Media GateWay (MGW)

F

6.2.0

6.3.0

Mar 2005

SA_27

SP-050046

0022

Add Link class to generic NRM Information Service

B

6.3.0

6.4.0

Mar 2005

MCC removed reference [16] TS 32.642 as NOT used in body text

6.3.0

6.4.0

Dec 2005

SA_30

SP-050712

0023

Correct Compliance rules

F

6.4.0

6.5.0

Dec 2005

SA_30

SP-050716

0024

Delete Annex A (moved to 32.300)

F

6.4.0

6.5.0

Dec 2005

SA_30

SP-050724

0025

Apply IS Template – Align with 32.151 and 32.152

F

6.4.0

6.5.0

Sep 2006

SA_33

SP-060535

0027

Extend the usage of VsDataContainer by BulkCMIRP to all 3GPP NRMs

F

6.5.0

6.6.0

Dec 2006

SA_34

SP-060711

0028

Clarify and correct errors in Link IOC related definitions

F

6.6.0

6.7.0

Jan 2007

Editorial: added missing right-hand parenthesis/bracket, in the zEnd attribute definition, last row of table 6.5.1.

6.7.0

6.7.1

Jun 2007

SA_36

Automatic upgrade to Rel-7 (no CR) at freeze of Rel-7. Deleted reference to CMIP SS, discontinued from R7 onwards.

6.7.1

7.0.0

Sep 2007

SA_37

SP-070610

0029

Correct description of common notifications – Align with Rel-8 32.151 IRP IS Template

F

7.0.0

8.0.0

Sep 2007

SA_37

SP-070614

0030

Update cardinality numbers regarding transient states – Align with 32.152

C

7.0.0

8.0.0

Mar 2008

SP-39

SP-080069

0031

Add the end point modelling for management of links related to reference point

B

8.0.0

8.1.0

Jun 2009

SP-44

SP-090289

0032

Correction of multiplicities

F

8.1.0

8.2.0

Dec 2009

SP-46

SP-090719

0033

Correct the ext in scope clause

F

8.2.0

9.0.0

Dec 2009

SP-46

SP-090719

0034

Replace GenericIRP by ManagedGenericIRP as Support IOC

C

8.2.0

9.0.0

Dec 2009

SP-46

SP-090719

0039

To update Generic NRM to add NASWM notification for ManagedElement

B

8.2.0

9.0.0

Mar 2009

SP-47

SP-100035

0036

Add ProxyClass Any to support IOC property relation

F

9.0.0

9.1.0

2011-03

Update to Rel-10 version (MCC)

9.1.0

10.0.0

2012-09

Update to Rel-11 version (MCC)

10.0.0

11.0.0

2013-06

SP-60

SP-130304

0037

1

Align specification of multiplicity for (names) composition with the model repertoire

F

11.0.0

11.1.0