B.1 Rules

32.1533GPPIntegration Reference Point (IRP) technology specific templates, rules and guidelinesRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

B.1.1 Introduction

The intent of this annex is threefold.

1) The first intent is for 3GPP internal use to document how a 3GPP CORBA SS is produced and how it is structured.

2) The second intent with the annex is to give the reader or implementer of a CORBA SS a better understanding on how to interpret the CORBA SS specification.

3) The third and maybe most important intent is to put requirement on an implementer of a CORBA SS.

It is expected that this annex is to be extended in later versions of the present document.

B.1.2 Rules for specification of CORBA Solution Sets

B.1.2.1 Introduction

This subclause identifies rules for specification of CORBA SSs. This subclause is mainly for 3GPP-internal use. It is only for information for the implementer of a CORBA SS.

B.1.2.2 Pragma prefix

All IDL-code shall define the pragma prefix using the following statement:

#pragma prefix "3gppsa5.org"

See clause B.2.1.4.3 for information of this #pragma statement in relation to other IDL statements.

B.1.3 Implementation aspects of Interface IRP CORBA Solution Sets

B.1.3.1 Introduction

This subclause identifies rules for the implementation of CORBA SSs. This subclause is normative for the implementer of a CORBA SS.

B.1.3.2 IRPAgent behaviour on incoming optional method

The IRPAgent, claiming compliance to a particular SS version of a particular IRP such as the Alarm IRP, shall implement all Mandatory and all Optional methods. Each method implementation shall have a signature specifying all Mandatory and all Optional parameters.

– If the IRPAgent does not support a particular optional method, it shall throw the OperationNotSupported exception when the IRPManager invokes that method.

– If the IRPAgent have not implemented a particular method (because it is compiled with an IDL version that does not define the method), the CORBA ORB of the IRPAgent shall throw a system exception if the IRPManager invokes that method.

In all the above cases when an exception is thrown, the IRPAgent shall restore its state before the method invocation.

B.1.3.3 IRPAgent behaviour on incoming optional parameter of operation

An IRPAgent must implement all optional parameters, as well as mandatory parameters, in all methods.

If the IRPAgent supports the implemented method but does not support its (one or more) optional input parameters, upon method invocation, the IRPAgent shall check if those parameters carry "no information" or absence semantics (defined later in subclause B.1.3.5). If the check is negative, the IRPAgent shall throw the ParameterNotSupported exception with a string carrying the name of the unsupported optional parameter.

B.1.3.4 IRPAgent behaviour on outgoing attributes of notification

CORBA SS uses OMG defined structured event to carry notification. The structured event is partitioned into header and body.

The absence semantics of attribute in the header is realized by a string of zero length.

The body consists of one or more name-value pair attributes. The absence semantics of these attributes is realized by their absence.

For optional sub-attributes of an attribute carried by the name-value pair, their absence semantics is realized by the encoding rule of "absence semantics". See subclause B.1.3.5.

B.1.3.5 Encoding rule of absence semantics

The operation parameters are mapped to method parameters of CORBA SS. The absence semantics for an operation (input and output) parameter is method parameter type dependent.

– For a string type, if the parameter is specified as a string type, the absence semantics is a string of zero length. If the parameter is specified as a union structure (preferred), the absence semantics is conveyed via a FALSE Boolean value switch.

– For an integer type, if the parameter is specified as a signed, unsigned, long, etc type, the absence semantics is the highest possible positive number. If the parameter is specified as a union structure (preferred), the absence semantics is conveyed via a FALSE Boolean value switch.

– For a boxed valueType (supported by CORBA 2.3), it is the null value.

The notification parameters are mapped to attributes of the CORBA Structured Events. The absence semantics for a notification parameter is attribute position (within the Structured Event) dependent.

– For the fixed header of the Structured Event header, the absence semantics is realized by a string of zero length.

– For the filterable body fields of the Structured Event body, the absence semantics is realized by the absence of the corresponding attribute.

B.1.4 Rules for NRM IRP CORBA SS extensions

This clause discusses how the models and IDL definitions provided in a particular NRM IRP CORBA SS can be extended for a particular implementation and still remain compliant with IRP specifications.

Note: Protocol-neutral rules for NRM IRP IS-level extensions are defined in TS 32.150 [3] Annex G.

B.1.4.1 Allowed extensions

Vendor-specific MOCs may be supported. The vendor-specific MOCs may support new types of attributes.
The standardised notifications may be issued referring to the vendor-specific MOCs and vendor-specific attributes. New MOCs shall be distinguishable from standardised MOCs by name. Standardised and vendor-specific attributes may be used in vendor-specific MOCs. Vendor-specific attribute names shall be distinguishable from existing attribute names.

MOCs may be subclassed. Subclassed MOCs shall maintain the specified behaviour of the superior classes. They may add vendor-specific behaviour with vendor-specific attributes. When subclassing, naming attributes cannot be changed. The subclassed MOC shall support all attributes of its superior class. Vendor-specific attributes cannot be added to MOCs without subclassing.

When subclassing, the standardised containment rules and their specified cardinality shall still be followed.
As an example, ManagementNode (or its subclasses) shall be contained under SubNetwork (or its subclasses).

Managed Object Instances may be instantiated as CORBA objects. This requires that the MOCs be represented in IDL. MOCs are not currently specified in IDL, but may be specified in IDL for instantiation or subclassing purposes. However, management information models should not require that IRPManagers access the instantiated managed objects other than through supported methods in the present document.

Extension rules related to notifications (Notification categories, Event Types, Extended Event Types etc.) are for further study.

B.1.4.2 Extensions not allowed

The IDL specifications in the present document cannot be edited or altered. Any additional IDL specifications shall be specified in separate IDL files.

IDL interfaces (note: not MOCs) specified in the present document may not be subclassed or extended. New interfaces may be defined with vendor-specific methods.