An Introduction to the Ericsson Transport Network Architecture ...

75
en real-time functionality, lengthy executions
must be divided into Transactions.
Data related to the Information Model can
be stored by using one of several possible
techniques:
- Object DataBase Management System,
ODBMS
This solution is very attractive in the
sense that it provides persistent objects,
which is exactly what the Information
Model specification suggests. The difference
between the implementation of the
system and the way it is described in an
Information Model is less than in the
other solutions. Also, the amount of design
and implementation work is considerably
less
- Relational Data-Base Management System,
RDBMS
This solution also limits the amount of
design and implementation work because
it provides mechanisms - such as
an ODBMS - for data storage, transaction
handling, roll-back, etc. However, a
translation (design) must be made from
the object-oriented specification to the
world of tables in a relational database
- Ordinary files
This solution is 'the hacker's choice'. It
is straightforward in that it uses only what
the Operating System and the programming
language provide
- Class library
This represents something of a compromise.
It provides basic data persistence
functionality for objects.
Implementation Structure
The network resource represented by a
Managed Object is partly implemented in
hardware, and the software is divided
between the Central Processor and Unit
Processors. To utilise the distributed processor
structure, which in a DXC of normal
size means one CP and some 100 UPs
or more, as much as possible of the functionality
is delegated to the UPs. The Internal
Communication Network, ICN, allows
UPs to communicate directly without involving
the CP, which means that real-time
functions such as protection switching and
network synchronisation can be handled
in the UPs.
The DXC Control System developed for
the German PTT by Ericsson together
with the German companies FUBA and
DeTeWe - its partners in the FLEXNODE
consortium, which will install AXD 4/1 and
AXD 1/0 in 6 sites - is regarded as a prototype
system and does not show all the
characteristics mentioned as requirements
above.
SMUX CONTROL SYSTEM
ARCHITECTURE
General
The SMUX Control System is implemented
mainly by programs executed on a
Central Processor (the Support Unit) as
well as Unit Processors (UPs) distributed
on each transmission printed board assembly
within the NE. The SU is a oneboard
processor common to the whole
range of Ericsson SDH multiplexers and
optimised for small NEs. The SU may be
common to a number - normally two - of
SDH multiplexers.
The SU has an overall responsibility for
management of the NE and receives and
evaluates management operations issued
from an OS or a local operator. As a response
to events detected in the network,
the SU issues notifications, e.g. alarm
messages, to the OS. The Q3 and ECC
protocol suites, and the F-interface, are
also controlled by the SU.
Functions of a simple nature but with a high
repetition rate, e.g. scanning of binary indications,
alarms, calculation of PM parameters
and operations in close connection
with transmission hardware, are
performed by UPs.
The implementation of the SMUX Control
System mapped onto CCITT Recs. G.782-
G.783, is shown in Fig. 9.
The SEMF is a function block which sends
and receives data on low-level management
functions to and from transmissionoriented
function blocks.
The MCF is implemented as a protocol machine
on the SU, and the SEMF is implemented
as software both on the SU and
on UPs. The Management Information
Base (MIB) is located on the SU, while the
S-interfaces, as specified in CCITT Recs.
G.782-G.783, are implemented as an
internal processor bus between the UP
and hardware registers on the transmission
printed board assemblies.
Commercially available products supplied
by Retix are used to implement the Q3 and
ECC protocol suites.