An Introduction to the Ericsson Transport Network Architecture ...

More documents

Recommendations

Info

68 BOX 3 The SDH NE MANAGEMENT ORGANISATION AL MODEL Management of SDH NEs is based on the management organisational model as outlined in Ret 5. The model consists of the following TMN function blocks and components, Fig. A: The Network Element Function (NEF) including the Management Information Base (MIB), the Message Communication Function (MCF), and the Management Application Function (MAF) including the agent. In addition, an MAF functional component containing a manager for local control of the NE has been defined. The local manager is housed in the local operator's terminal. Agent Part of the MAF which is capable of responding to network management operations issued by a manager, and of issuing notifications, e.g. event reports, on behalf of the managed objects Manager Part of the MAF which is capable of issuing requests for network management operations, e.g. request performance data, set thresholds, receive event reports, etc. Local Manager A managerwhich is housed in a local operator's terminal and is capable of managing a single network element Management Application Function (MAF) An application process providing TMN services. The MAF includes an agent, or a manager, or both. The MAF is the origin and termination of all TMN messages Managed Object (MO) The manager's view of a resource within the telecommunications environment that may be managed via the agent. Examples of MOs residing in an SDH NE are equipment, software, trail termination point, SDH switch fabric, alarm log, etc. Message Communication Function (MCF) Provides facilities for the transport of TMN messages to and from the MAF, as well as network layer routing functions Network Element Function (NEF) The entity within an NE that supports transport network based services, e.g. multiplexing, cross-connection, regeneration, etc. The NEF is represented to the manager as a set of managed objects. ECC subnetwork, or between any of the ECC subnetworks, Boxes 2 and 3. Graphical User Interface General One of the most important aspects of SDH NE management is the ease with which it can be operated. It is true that a prime driving force behind the deployment of the Transport Network is to facilitate the management of network resources by way of centralised management - that is, with Q-interfaces and FMAS - but NEs will nevertheless be operated and maintained from the local site. Some of the reasons for local operation are: - Backup when the OS, or the communication link to OS, is down - The network operator may wish to adopt a more decentralised management philosophy - Certain management functions are more easily performed on site because they require physical manipulation of the equipment. For this purpose a local operator's terminal with a Graphical User Interface (GUI) can be connected to the NE. The GUI is a window-based and mouse-operated interface through which the operator has access to all the management functions. In order for an operator to gain access to the functionality, he has to prove his legitimacy by supplying an identification code and a password. This falls under Security Management, which also includes the possibility of a Super-user assigning operators to particular user categories with extensive or more limited privileges. Configuration Management covers both physical configuration in an SDH NE-typically Printed Board Assemblies such as Fig. A SDH NE Management Organisational Model ERICSSON REVIEW No. 3, 1992
69 the Termination Access Unit - and a logical configuration of the capacities for switching and multiplexing. These different types of Configuration Management are supported by different graphical views, e.g. a physical view and a logical view. When there is a fault of some kind, e.g. a Transport Network related alarm such as Loss of Frame Alignment or excessive Bit Error Ratio, or a fault related to HW or SW in the actual NE, the details and possible consequences are reported to the GUI. Fault Management, which deals with these functions, also covers testing and diagnostics. Performance is continuously monitored, and the GUI presents the statistics graphically and/or in tabular form. These functions fall under Performance Management. The local GUIs conform to design standards developed for user interfaces by TMOS User Interface Design Standards (TUIDS), which means that the OPEN LOOK user interface style is currently used for the SDXCs, but Motif will also be included. For the SMUXs, Microsoft Windows is used. ETNA Harmonisation The current SDX Control System contains a GUI implemented on an IPX type Sun Workstation, but a portable terminal will also be provided. The GUI for SMUX is implemented on a PC 386/486. The fact that two different types of graphical terminal are used will not prevent 'look and feel' similarity between the systems, however. The Graphical User Interfaces for SDH NEs will be harmonised with each other and with the GUI for FMAS. Fig. 3 shows a typical detail of the DXC user interface. Control System Architecture Introduction The control system has to control Network Elements which vary in size from only a few connected cables to over 8,000. The functionality associated with each connected cable makes heavy demands on the control system processing capacity. Another important factor to consider is cost, which has to be kept very low for small systems. A distributed computer architecture has been chosen to meet these requirements. Fig. 3 SDXC User Interface A window from the Configuration Management functional area ERICSSON REVIEW No. 3, 1992
Page 1: ERICSSON REVIEW 3 1992 An Introduct
Page 4 and 5: An Introduction to the Ericsson Tra
Page 6 and 7: 60 Fig. 3 AXD 155 system integratio
Page 8 and 9: Control and Operation of SDH Networ
Page 10 and 11: 64 These functions and a number of
Page 12 and 13: 66 to the OS upon detection of a se
Page 16 and 17: Fig. 4 Control System Architecture
Page 18 and 19: 72 Fig. 6 Software Architecture CSA
Page 20 and 21: 74 Functional requirements Certain
Page 22 and 23: 76 Fig 10 SMUX Control System Hardw
Page 24 and 25: AXD 4/1, a Digital Cross-Connect Sy
Page 26 and 27: 80 Fig. 2 AXD 4/1, System Architect
Page 28 and 29: 82 Fig. 3 Time Space Switch structu
Page 30 and 31: 84 Fig. 4 AXD 4/1 Devices Devices o
Page 32 and 33: 86 The control signals, which come
Page 34: 88 Fig. 8 Protection Switch Unit st

An Introduction to the Ericsson Transport Network Architecture ...

Create successful ePaper yourself

Delete template?

Save as template?