duce derived information such as control of telecoms networks and services error rates etc, which is stored in logs of defined duration, and SDH based networks 42/19 NETWORK SITE C Information relayed from ELEMENTS manager to remote elements using D4 D12 bytes of SOH plus G.784 protocol stack (D4-D12) (D4-D12) PLESIOCHRONOUS INTERFACES STM-N SITE B INTERFACES (D4-D12) (D4-D12) Information transfer between SITE E element and manager using G.773 protocol stacks SITE A This network element acts as the gateway between the Element Manager TO EXISTING at site A and the remote network ELEMENT ALARM MANAGER elements at sites B, C, D and E MONITORING SCHEMES TO NETWORK LAYER CONTROLLER WORKSTATION SITE A Figure 42.24 Control channels and protocols within a SDH entwork functionality or whether an object should represent a (small) piece ment managers and yet more managers at the network and service of hardware. Although CCITT G.783 functionally decomposes levels, gives rise to the concept of a Telecommunications Manage- SDH equipment, its says almost nothing on the way such atomic ment Network (TMN). functions are split or combined in any real hardware implementa- The main recommendation concerning the TMN is CCITT M.30, tion. The current view within both CCITT and ETSI is that the set which attempts to define a series of interfaces between different of objects (collectively known as the 'Information Model') should management entities in such a network. It is not confined purely to present both a functional and a physical view of the network ele- SDH networks, but SDH networks will probably be the first to ment that they represent. ETSI, in particular, is making good pro- implement an M.30 style TMN. (See Chapter 16.) gress 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 42.6 SDH based networks one another, it is also necessary to have an agreed message set to go with it. Fortunately, this flows reasona