The Itf-N partitions two groups of interacting entities called IRPManager(s) and IRPAgent(s).
The interactions between an IRPManager and IRPAgent are specified by the set of IRP specifications the IRPAgent supports, and which the IRPManager uses.
Each YyyIRP (where "Yyy" stands for Alarm, BasicCM, etc.) permits a manager to, via getIRPVersion, inspect it's supported IRPVersion(s). Each such IRPVersion uniquely identifies one supported Interface IRP SS.
Each YyyIRP may also permit an IRPManager to, via getNRMIRPVersions, inspect it's supported NRM IRPVersion(s). Each such IRPVersion uniquely identifies one supported NRM IRP SS.
The 3GPP IRP specifications are expected to evolve. For example, 3GPP Release 6 specifications include more or modified features compared to the corresponding set in Release 5.
An IRPManager and IRPAgent, with implementations conformant to the same IRP specification (at the same IRPVersion(s)) will be able to communicate.
However, an upgrade of the IRPVersion, if not performed by both IRPAgent and IRPManager, can result in inter-working failure if Backward Compatibility (BC) issues are not addressed.
The present document is applicable/relevant to a system context of a group of interacting IRPManagers and IRPAgents where some members are using one IRPVersion while others are using an upgraded IRPVersion.
The present document gives recommendations to develop future IRP specifications in a Backward Compatible (BC) way so that the group of IRPManager(s) and IRPAgent(s) are not forced to be upgraded in lock step.
The business case for supporting such group, as described above, is complex. It may not relate to the functions of the supported IRPs alone. Rather, it can relate to the cost of coordination of IRPVersion upgrades, the cost of maintaining an old IRPVersion and the cost of using single-vendor or multi-vendor IRPAgents. These considerations are operator deployment scenarios specific.
Clause 4 specifies the Recommendations and clause 5 describes the system context where the Recommendations are applicable.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication and/or edition number or version number) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
The words old and new, when qualifying an IRPVersion, refer to a single Interface IRPVersion of the same kind, e.g. Alarm IRP. They also refer to NRM IRPVersion of the same kind, e.g. Core NRM. The 'new' refers to a later release compared to the 'old'.
The words old and new, when qualifying an IRPManager, refer to an entity that is using the old or the new (Interface or NRM) IRPVersion.
The words old and new, when qualifying an IRPAgent, refer to an entity that contains an IRP that is supporting the old or the new (Interface or NRM) IRPVersion.
In majority cases, an IRPAgent instance contains multiple IRPs, each of which is using a particular Interface IRPVersion. In these cases, each Recommendation statement should be repeated to cover all IRPs involved.
The Recommendations do not imply that equipment vendors shall always supply their new IRPAgents in compliance to the solutions satisfying the Recommendations. The Recommendations simply identify the expected behaviours of a new system when it, claiming BC, interacts with an old system. Whether or not an IRPAgent should satisfy the Recommendations is a decision of the equipment vendor/supplier.
The Recommendations do not imply that the next release of 3GPP Interface IRP or NRM IRP specification must be BC (to the older one). Whether or not a new release of an Interface IRP or NRM IRP should be BC to its older version is a decision of the 3GPP specification author, on a case-by-case basis.
An old IRPManager inter-operates with an old IRPAgent-A and a new IRPAgent-B.
The interaction shall be successful in that the IRPManager can obtain the network management services (capabilities and features) defined by the old IRPVersion from both IRPAgents.
The IRPManager needs not have knowledge of new network management services defined by the new IRPVersion.
[REC-2]
A new IRPManager inter-operates with a new IRPAgent A and an old IRPAgent B.
The interaction shall be successful in that the IRPManager can obtain the network management services defined by (a) the new IRPVersion from IRPAgent A and (b) the old IRPVersion from IRPAgent B.