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):
- ManagementNode, if the configuration contains a ManagementNode;
- SubNetwork, if the configuration contains a SubNetwork and no ManagementNode;
- 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:
- all LDNs or DNs are locally modified using the new dnPrefix for the upper portion of the DNs, or
- 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:
- 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>.
- 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). | 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:
|
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). | 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 |