Content for TS 32.102 Word version: 17.0.0

1… 4… 5… 7… 7.3… 7.3.3… 7.4… 8… 9… 11… 14 A… B…

13.1 Function attributes 13.2 Functional characteristics 13.3 Critical attributes 13.4 Protocol selection 13.5 Communications considerations
...

11 Implementation aspects p. 34

PLMN operators might categories and organise its operation systems in many different ways as:

A national fault and performance OS.
A national charging, billing and accounting OS.
Regional configuration OS.
Regional fault, performance and configuration OS.
etc.

This geographical dependent categorisation may change after time and the growth of the network. A physical architecture based on an open system design and re-usable application components would ease the work to adopt such structural changes. A management system build for a PLMN shall provide the possibility of layering the applications.

12 3GPP TMN Conformance p. 35

The goal of TMN conformance (see ITU-T Recommendation M.3010 [1]) is to increase the probability that different implementations within a TMN will be able to interwork, that TMNs in different service/network provider's administrations and customer's system will be able to interwork as much as agreed on.

TMN conformance are testable conditions.

It is only the requirements on the external behaviour that have to be met by the conformance statements.

To finally guarantee interoperability the purchaser/user shall be able to test and verify that any two systems, claiming any type of TMN conformance, interoperate. Interoperability testing shall include:

Testing of the interface protocols;
The shared/exposed information over those interfaces;
The interface functionality of the system.

A 3GPP TMN conformant entity shall support necessary information to support such interoperability testing namely:

Statements made by the supplier of an implementation or system claimed to conform to a given specification, stating which capabilities and options have been implemented.
Detailed information to help determine which capabilities are testable and which are un-testable.
Information needed in order to be able to run the appropriate test.
The system interface documentation shall list the documents that define the specified information models with the inclusion of the version number and date.
Necessary information about vendor supplied extensions of a standardised interface

The interface specification shall be documented, publicly available and licensable at reasonable price on a non-discriminatory basis.

Specific conformance guidelines shall be included in the different IRP solution sets. A 3GPP TMN conformant entity must support information stated in those conformance guidelines.

13 TMN planning and design considerations p. 36

A TMN should be designed such that it has the capability to interface with several types of communications paths to ensure that a framework is provided which is flexible enough to allow for the most efficient communications:

Between one NE and other elements within the TMN;
Between a WS and other elements within the TMN;
Between elements within the TMN;
Between TMNs.

The basis for choosing the appropriate interfaces, however, should be the functions performed by the elements between which appropriate communications are performed. The interface requirements are specified in terms of function attributes needed to provide the most efficient interface.

13.1 Function attributes p. 36

Reliability - The capability of the interface to ensure that data and control are transferred such that integrity and security are maintained.
Frequency - How often data is transferred across the interface boundary (Normal behaviour).
Quantity - The amount of data that is transferred across the interface during any transaction.
Priority - Indicates precedence to be given to data in case of competition for network resources with other functions.
Availability - Determines the use of redundancy in the design of the communications channels between interfacing elements.
Delay - Identifies the amount of buffering that may be tolerable between interfacing elements. This also impacts communications channel designs.

Table 13.1 suggests a possible ranges for these function attributes.

Table 13.1: Possible ranges for TMN function attributes [1]

Attributes		Requirements	Nature of attributes
Performance or grade of service (P)	Delay (speed)	Short Medium Long	Objective of design and control (acceptable/unacceptable but available/unavailable)
	Reliability (accuracy)	High Medium Low
	Availability	High Medium Low
Characteristics of TMN traffic (C)	Quantity	Large Medium Small	Condition or parameter of design
	Frequency	Often continuous Periodic Sparse
	Priority	High Medium Low

13.2 Functional characteristics p. 37

Each major type of telecommunications equipment has functional characteristic needs that can be used to describe the complexity of the interface.

There are, however, a basic group of TMN application functions that cross all major types of telecommunications equipment. There are also unique TMN application functions that are performed by specific categories of major telecommunications equipment. Alarm surveillance is an example of the former, whereas billing information collection is an example of the latter.

Functional characteristics of the elements within a TMN, e.g. OS, DCN and MD also describe the complexity of interfaces between these elements.

13.3 Critical attributes p. 37

Attribute values for a given function are generally consistent across the network elements.

When considering a single interface, it is important to identify the controlling attribute ranges for the design of the interface.

If there are conflicting attribute values for different functions in a given network element, more than one instance of an interface may be needed.

Overall TMN attribute values for the interfacing of elements within the TMN depend on the type and number of functions performed within these elements. In this case the functions are not consistent across TMN elements, but are controlled by the individual TMN design of an Administration.

13.4 Protocol selection p. 37

In many cases, more than one protocol suite will meet the requirements for the network element or TMN element under consideration. It is the approach for the 3GPP Telecom management standardisation to concentrate on protocol independent information models, allowing the mapping to several protocol suites.

The rationale behind this is:

The blurring of Information and Telecommunication technologies in a 3GPP system, it is required to work on a more open approach (acknowledging the market status and foreseen evolutions).
The lifecycle of information flows is 10 to 20 years, while the protocols is 5 to 10 years.
The developments on automatic conversion allows for a more pragmatic and open approach.

The choice of the individual protocol from the recommended family will be left open to the vendors and operators.

To provide the most efficient interface care should be taken to select the protocol suite that optimises the relationship between the total cost to implement that protocol suite, the functional attributes and the data communications channels that carry the information across the interface.

13.5 Communications considerations p. 37

DCN architectures should be planned and designed to ensure that their implementation provides appropriate degrees of availability and network delay while minimising cost.

One should consider the selection of communications architectures, e.g. star, multipoint, loop, tree, etc.

The communications channels, e.g. dedicated lines, circuit-switched networks and packet networks used in providing the communications paths, also play an important role.