42.5 Control and management
Control and management within any type of telecommunications network (not just an SDH one) can best be viewed in terms of a series of layers (See Figure 42.23). At the lowest level, there is internal control of an individual network element, which performs internal housekeeping functions and deals in alarm and control primitives. CCITT G.783 has rigorously defined a minimum set of control and alarm primitives for each of the SDH atomic functions, and these are the basis of all SDH management. However, beyond this CCITT G.784 describes how such primitive information should be processed and ordered to produce derived information such as error rates etc, which is stored in logs of defined duration, and reported at set intervals, etc. At the lowest level, some of this information may look rather different to that specified in G 783/4 etc, however, the internal network element control system takes these and from them, synthesises the information that is required by the next level in the management hierarchy i.e. the element manager.
The element manager is a piece of software which can control many individual network elements (usually in the range 10-1000), but it can only control them as individual elements and does not have any view of the traffic relationships between them. Usually it is located remote from the elements it is controlling and more often than not, it runs on some form of workstation. The interface between the element manager and the network elements is an obvious area for standardisation, as without this there is little chance of a single element manager controlling network elements from more than one manufacturer. Despite the progress that has been made in rigorously describing the network element atomic functions, it has still proved very difficult to agree on a software description of them. The approach adopted in CCITT, ANSI, and ETSI has been to describe complete network elements as collections of 'objects' in line with the rules of 'object orientated' programming.
The idea is that an object is a software entity that has both attributes and behaviour. External stimulate (i.e. information, commands, etc.) trigger an object to behave in a certain way e.g. change its attributes, transmit information, commands etc. The claim is that a standardised object could be looked upon as the software equivalent of a hardware integrated circuit. One of the biggest areas of disagreement in generating an agreed standard set of SDH objects, is the questions of whether an object should represent a piece of functionality or whether an object should represent a (small) piece of hardware. Although CCITT G.783 functionally decomposes SDH equipment, its says almost nothing on the way such atomic functions are split or combined in any real hardware implementation. The current view within both CCITT and ETSI is that the set of objects (collectively known as the 'Information Model') should present both a functional and a physical view of the network element that they represent. ETSI, in particular, is making good progress in generating a model along these lines.
Not only is it necessary to have a standardised information model, so that the network element and element manager can understand line another, it is also necessary to have an agreed message set to go with it. Fortunately, this flows reasonably easily from the definition of the objects themselves. However, the existence of such a message set, then leads to the requirement for an agreed information protocol stack with which to transport it. For information transferred between a network element direct to its element manager, CCITT G.773 details several allowed protocol stacks, which split into two groups, those which have a full 7 layer structure and those which have a 'short stack', where layers 4, 5, and 6 are absent. Most observers favour the use of the heavier, but more flexible, seven layer protocol stacks for SDH networks, while the 'short' stacks are more appropriate for PDH equipment for which it is more difficult to justify the burden of the additional layers.
Not only are there defined protocol stacks for information transfer direct from element manager to network element, but there is also a defined protocol stack for information transfer between individual network elements. In general, the majority of information transfer between network elements is actually information arising from an element manager, which is being relayed by an intermediate network element to a more remote element. (See Figure 42.24). This flow of management information amongst network elements, element managers and yet more managers at the network and service levels, gives rise to the concept of a Telecommunicatioas Management Network (TMN).
The main recommendation concerning the TMN is CCITT M.30, which attempts to define a series of interfaces between different management entities in such a network. It is not confined purely to SDH networks, but SDH networks will probably be the first to implement an M.30 style TMN. (See Chapter 16.)
