A Simulation Environment for SDH

Synchronization Network Planning

Jean-Thierry Calvet † and Claude Girault ‡

†
Alcatel, Route de Nozay, 91461 Marcoussis Cedex, France,
‡
University Paris 6, 8 rue capitaine Scott, 75015 Paris,
e-mail: Jean-Thierry.Calvet@ms.alcatel.fr, Claude.Girault@lip6.fr

ABSTRACT—SDH networks are much used by telecommunication operators and they have to be well-synchronized in
order to ensure reliable and high-quality transmissions. The main difficulties in correctly configuring a synchronization
network with respect to the various construction constraints reside in the multiple configuration options and in the
automatic reactions of equipments in case of failure. By selecting their synchronization source according to the
priorities assigned to their input ports and the signal quality messages, equipments modify the synchronization network
plan. The size of the network and the configuration complexity hardly let a network designer predict the way a network
would react to a failure. The need to have a network as fault tolerant as possible, requires validating the correctness of
a given configuration before deploying it on the operator's network. This paper presents a platform that helps in the
design and the configuration of SDH synchronization networks. To determine the automatic reconfiguration of a
network after failures, we have developed a model of the synchronization mechanisms of SDH equipments. After
simulation, we make use of pruning and search algorithms to check the correctness of the resulting synchronization
network. These tools are gathered in the platform.

1. INTRODUCTION

The Synchronous Digital Hierarchy (SDH) is a transport technology taking advantage of optical transmission
(reliability and high throughput) that has been standardized by International Telecommunication Union (ITU) since
1988. SDH is based on the Synchronous Optical NETwork (SONET), used in the United States of America and
developed by BELL laboratories. SONET standardization started in 1985 [SS96]. To refer to the Open Systems
Interconnection (OSI) model, we could say that SDH takes care of layers 1 and 2 (physical and data-link). SDH is used
since early 90's by European telecommunication operators and takes over from older equipments of the Plesiochronous
Digital Hierarchy (PDH). The flaws of PDH are the lack of a standardized high throughput interface and the lack of
network management facilities. The high throughput supported by SDH (from a minimum of 155,520Mbit/s up to
several Gbit/s) and the type of the connections (point to point) make SDH especially suitable for a use within WAN
(Wide Area Network) for network backbones.
However these high throughputs need that the clock controlling transmission ports of each equipment is extremely
accurate to avoid bits or even frames losses during transmission. Even if potential synchronization problems are taken
into account by a mechanism of pointer within the SDH frame, it is necessary to ensure the best synchronization possible
to guarantee a constant quality of service. As an example, synchronization problems lead to audible clicks in phone calls
or losses of lines when transmitting faxes or a reduced throughput during data transmission [WOL97].
In Section 2 we describe the possibilities and constraints of synchronization network planning and discuss about
automatic reconfiguration on an example. Section 3 is dedicated to simulation and modeling of synchronization
networks. Last, Section 4 presents the checking algorithms, their performances and the platform.

2. SDH SYNCHRONIZATION NETWORK PLANNING

Synchronization problems arise from the jitter and the wander of "low-quality" oscillators (clocks). A type of clock
called Primary Reference Clock (PRC, defined in [ITU811]) is accurate enough to ensure proper synchronization. For
financial reasons, PRCs cannot be onboard each equipment or within each station (a geographical site grouping
equipments) since such clocks costs about 150,000 €. Therefore a synchronization network has been put on. It uses some
of the transmission links (STM-n and Tributaries) to transport the synchronization signal. Within a station, where
installing a cable is reasonably expensive, dedicated cables (2Mhz, 2Mbit/s) exist to pass the synchronization signal.
The synchronization network must be designed in order that every equipment receives a synchronization signal primarily
issued by the PRC. The synchronization network will look like a tree, with the PRC being the top node [KLE97].
Transmission equipments have a built-in low-quality clock called SDH Equipment Clock (SEC, defined in
[ITU813]). These clocks are stable enough to ensure a very short time (a few seconds) of autonomy if the reference
signal from the PRC is lost. The stability of a SEC is around 5.10-7 second a day when a PRC has a phase stability asset
to 10-11. Since SECs are not able to evaluate the quality of a signal, a system of messages giving information about the
quality of a signal has been set. A 4 bits message called Synchronization Status Message (SSM) [FER98] is passed with
each SDH frame (STM-n) and is processed by SEC. The values of the SSM ranges from G811 (quality PRC) to DNU
(Do Not Use). A SEC chooses one of its available input ports by comparing the SSM values. To avoid the loss of the
reference signal from the PRC and the loss of synchronization, backup links and clocks are used. Transmission
equipment can have several synchronization-supplying links but only one at a time can be selected. The remaining links
are "standby" links and are used as backup links in case the signal on the selected link becomes very degraded or is lost.
Synchronization Supply Units (SSU, defined in [ITU812]) are used in main stations to regenerate a signal that has
been degraded by passing through several SECs or to supply a backup signal reference in case the signal from the PRC
is lost. The stability of SSUs is at least 10-9s/day and lets a network isolated from the PRC to work fine for at least 4
days. SSUs have multiple input ports (2Mhz or 2Mbit/s) and are able to assess the quality of the input signal and to
"regenerate" it.
Topology of SDH transmission networks makes heavy use of double rings for protection purposes. As a fiber
transmits data in one way only, most of these links are duplicated in the opposite way allowing double rings to be in
opposite directions. Since the synchronization network leans on the transmission network, it takes advantage of these
characteristics.
We will see later the constraints to be respected when planning a SDH network, the selection process of each type of
clocks and the risks inherent to a bad planning.

2.1 Configuration of equipments and constraints

As main synchronization sources and as equipment dedicated to synchronization, PRCs do not have any input and
cannot be configured.
SSUs have inputs, do not handle the SSM but are able to analyze and squelch low-quality signals. A priority is
assigned to each port for the selection process.
SECs are the lowest quality clocks but with the most complex selection process using priorities and the SSM. Two
selectors (A and B) can choose a signal among 12 input ports, signals can carry a SSM, a SSM value can be given to
each input or output port masking the SSM transported by the signal and last, a priority is assigned to each input port.
The internal oscillator is used only if no signal is available or can be selected because of the configuration and this mode
is known as the holdover mode. Figure 1 shows how these functions are organized.

Figure 1 - Functional representation of a SEC

Multiple constraints must be observed when configuring all equipments in order to define the synchronization
network. An equipment must not be isolated i.e. an equipment must always be synchronized by a signal issued by the
PRC (possibly a SSU in case of failure) [WOL94]. A Synchronization loop must never occur [GHU97]. A loop is a
synchronization chain of equipment such that the last equipment synchronizes the first one thus amplifying the jitter and
the wander of its own clock. Other constraints set rules on the distances (number of hops) between PRCs, SSUs and
SECs and the maximum number of each type of equipment on a synchronization chain. As defined in the standard
[ITU803] no more than 60 SECs and 10 SSUs can be part of a synchronization chain, and a maximum of 20 SECs can
be between two SSUs.

2.2 Example of a network configuration and automatic reconfiguration

Figure 2 shows a small network with a PRC and a ring of SECs. The SECs are configured such as there is no
synchronization loop and in order to have the synchronization signal going clockwise through the ring. All links are
duplicated in the opposite way in order to let the network change direction to handle a
failure.

Figure 2 - example of automatic reconfiguration

In case of failure on the link between PRC and SEC1, the network automatically reconfigures using the available
standby links. SEC1 switches to one of its two other ports. Port with priority 2 receives a SSM quality "DNU" (SEC2
replies DNU to SEC1 because it is synchronized by SEC1. This is an automatic reply in order to avoid "micro"-timing
loop). Port with priority 3 receives SSM quality G811 from SEC6 and this is the port that will be selected by SEC1. If
we try to identify the synchronization source of SEC1 we find SEC6, SEC5, SEC4, SEC3, SEC2, and SEC1 again. This
is a typical example of a timing loop generated by a failure while initially the network is correctly configured. A solution
here would have to force the port with priority 3 of SEC1 to receive a DNU SSM in order to avoid any timing loop. All
the SECs would switch to holdover mode in case of the aforementioned failure.
Other effects of a failure are the modification of the 3-uple criteria. The above example is two small to show a
violation of the constraints.
The size of real networks (hundreds of equipments and more), the number of constraints, and the complexity of the
configuration of equipments make synchronization network planning hard to manage. Design a fault-tolerant network is
even harder because multiple failures have to be handled.

2.3 Survivable synchronization network planning

A network may have hardly predictable reactions to a failure because of the complexity and numerous possibilities of
configuration of equipments. The effect of a failure may be very localized because of a proper configuration or may
have wide effects if the planning has not been done properly. It is important for a synchronization network designer to
know the impact of failures on his network and to point out weak points of the network i.e. the equipments or links
where failures have the most disastrous effects. But since equipments may automatically reconfigure themselves
simultaneously it is difficult to know the state of the network after one or multiple failures. As the order and simultaneity
of failures may also induce changes in the reconfiguration of a network, we make use of a simulation engine.

3. SIMULATION OF SDH SYNCHRONIZATION NETWORKS

Our aim is to propose computer-assisted tools to synchronization network designers that help them choosing the
correct configuration of a SDH synchronization network.
We have divided the evaluation of the consequences of a failure on a network in two steps. The first step consists in
determining the state of the network after a failure resulting from the automatic reconfiguration mechanisms of each
equipment. This step is performed by simulating the collective behavior of the network equipments The second step,
taking the configuration of the network after failure as an input, checks that the synchronization chain structure
constraints are respected and that there is no isolation situation or synchronization loop. This second step may also be
profitably done before any failure injection in the network to ensure that the network is initially well configured.
The modeling environment used is Workbench 3.3 by SES/Hyperformix, a generic tool for modeling systems with
discrete events. Models are graphs of which edges represent utilization of resources. The edges can be delays, waiting
queues or calls to user functions. "Transactions" (like a token) travel through the edges, follow the vertices and pause at
delay edges. This system can be compared to Petri nets: delays are transitions, calls to user functions are nodes and
transactions are marks. The model describing SDH synchronization networks uses simulation concepts such as creation
of resources, waiting time, functions calls and needed about 5000 lines of C to be written.

3.1 Modeling

The fine grain modeling of transmission equipments clocks (SECs) and of equipments dedicated to synchronization
(SSUs and PRCs) lets us simulate the operation of the synchronization network and determine the state of the network
after one or multiple failures. To model the operation of equipments, the functional representation described in standards
has been used as a base. Figure 1 is the functional representation of a SEC as it is defined in [ITU783] and [ETS462].
Figure 3 corresponds to the model of a SEC within the modeling environment: each equipment of this type in the
network that we want to model is represented by an instance of this SEC model. Initially a transaction is created and will
then move within the loop that follows. Since equipments take some time before detecting a change in their inputs, we
define a delay in the model named "delay_before_read" before the function "read_input_ports". The same mechanism is
used for the output ports: a delay is inserted before reflecting a change in the inputs to the outputs. SQUELCH A and B
functions (see Figure 1) are filters that can squelch a signal that is below a chosen quality level. These functions have
been modeled too. Ports can be configured and individually assigned a forced SSM value.

Equipments dedicated to synchronization such as PRCs and SSUs have been modeled a similar way.

Figure 3 - SEC model

3.2 Simulation

The simulator takes as an input parameter a file describing the configuration of each equipment, the links between
them and a description of the scenario to be simulated (the failures to generate i.e. link or equipment failures) and the
time the failures must be triggered at. A scenario may be one of four main types. The first type lets the synchronization
network designer choose a limited number of failures and the time the failures will happen. Therefore simultaneous or
even nearly simultaneous failures can be generated. The second type is a list of sequential failures: the network will
reach a stable state before a new failure is injected (no time is given). The third type will test the network for all single
link failures. The last type of scenario tests the network for all double sequential link failures.
After the initialization phase mainly focused on reading the input file describing the network (equipments and links),
the simulation starts following the scenario. If the scenario consists in creating multiple sequential failures, the
simulation proceeds until the first stabilization of the network is reached. Then the network is checked for violation of
any constraints (this will be discussed later) and its state and the result of the checks are saved into memory. The first
failure can now be injected. The simulation resumes until a new stable state is reached. The network is checked again
and is compared to the previously stored state. These last steps are repeated until all failures have been tested.
The scenario testing for all single link failures is based on the scenario presented above (multiple sequential failures).
Nested loops allow restoring the initial stable state of the network to test for all single successive link failures (not
simultaneous).
To ensure that the network stable state has been reached, we have implemented a stability detection mechanism. This
mechanism uses a flag on each equipment and is not sensitive to the "latency delays" of each equipment that would lead
to the detection of false stable state. This flag indicates if an equipment is stable or not, that is to say if a change in its
entries has occurred and if it has been reflected in its outputs. As soon as the changes have been propagated to its
outputs not only the flag is set to "stable" but the flags of the equipments receiving synchronization from this equipment
are also set to "not stable" to avoid any transient not stable state. The network is stable as soon as the flags of all
equipments are set to "stable".
A report is written in a file giving information about the simulation, the results of checks for constraint violations and
about the effects of a failure. Report files can be more or less detailed depending on the user needs. Multiple options let
the synchronization network designer choose the level of detail of the report files.

3.3 Transient states of the network shown by simulation

By simulating a network and reading the detailed report file, we could check that its first stable is reached after very
different transient states. Let's consider a network involving a long ring of SECs and having a PRC at the two extremities
of the ring. Initially the network is synchronized by both PRC1 and PRC2 equitably (depending on time delays of
equipment). This is because the SSM has priority over the priorities assigned to ports. When the equipments in the
middle of the ring receive both signals and SSM from PRC1 and PRC2, they select the port coming from PRC1
(because of priority) then their neighbors synchronized by PRC2 will switch to its port synchronized by PRC1 and so
on. Finally the network is configured such as most of the ring is synchronized by PRC1, while PRC2 is only a backup
reference. The synchronization behaves like to waves: one coming from PRC1, the other one from PRC2. When the two
meet, the wave from PRC1 covers the one from PRC2 because of priorities.

Figure 4 - Transient states before stabilization

4. EVALUATION OF THE CORRECTNESS OF A CONFIGURATION

A simulation let us know the way equipments will be reconfigured after the initialization or a failure. We have
written and implemented in C multiple algorithms in order to check the correctness of the configuration of a network.
The network is checked for loop, for isolated equipments, and for the 3-uple criteria constraints violation. As mentioned
before, these algorithms can be applied to the network at different stages: initialization or failure injection stages.

4.1 Loop detection and chain structure constraints checking algorithms

After a simulation, equipments have selected their synchronization source among the multiple available ones. The
directed graph corresponding to the network may be a set of directed graphs of the following shapes: a tree of
equipments or a loop with trees connected to it. A chain or a single isolated equipment are special shapes included in the
tree shape. Figure 5 shows two shapes: a tree connected to a loop and a tree.
 Figure 5 - Loop and Trees
We first check for loops in the directed graph of the network, using a pruning algorithm in three steps (We assume
that "nb_succ" is a variable assigned to each equipment and that it is initialized to 0. After the step 1 described below,
"nb_succ " will hold the number of successors of a given equipment):
1 Identifying the leaves: we perform a search through all nodes (sequentially). For each node we increment the
"nb_succ" counter of its predecessors if any. After the search, nodes with "nb_succ" equal to 0 have no
successor and are leaves.
2 Pruning of the trees: sequentially for each leaf, we visit the graph backward from the given leaf, cut the leaf and
decrement the "nb_succ" of its predecessor. If "nb_succ" of a predecessor equals 0, it is detected as a leaf and
we repeat the operations. If "nb_succ" is different than 0 we visit the next leaf.
3 Searching for loops: if some nodes remain unvisited, they belong to isolated loops. We determine each loop by
visiting the graph backward from any of the remaining nodes.

Next we detect isolated equipments by searching through the list of roots of the trees. Since an isolated equipment is
an equipment not receiving a signal from the PRC, a root of a tree that is not a PRC is an isolated equipment and its
whole tree is also isolated.

To check the synchronization chain structure constraints, we introduce a 3-uple criteria: [number of SECs on the
chain, number of SECs since last SSU, number of SSUs on the chain]. This 3-uple criteria is computed by searching
through each tree with a PRC as the root using a breadth-first or depth-first search algorithm. [0,0,0] is assigned to a
PRC. The 3-uple is computed on the fly when visiting the graph using the 3-uple of the predecessor of the current node.
The Figure 6 shows a very simple example of a network with a PRC, a SSU and 4 SECs only to show the 3-uple criteria
of each equipment.

Figure 6 - example of a network with the 3-uple criteria

4.2 Particular cases

As we have seen before on the SEC functional model, a SEC has two main selectors. Only selector B is used to
synchronize the input and output ports and has its signal processed through the internal oscillator of the SEC. Selector A
and SQUELCH A only select a signal among the available ones and let it propagate or squelch it. If selector C is
configured to use selector A then the signal available at the T4 port of the SEC is the signal selected by selector A
without any modification. This particular case (signal on selector A, not squelched and selector C uses selector A) needs
that when computing the 3-uple criteria such a SEC must not be taken into account.
This can be complicated as multiple SECs with this special configuration can be linked together. The algorithms
described before use a special function to identify the real source of synchronization of a given equipment.

Figure 7 - T4 port and 3-uple criteria

The Figure 7 shows an example with 3 SECs configured differently. SEC1 receives signal on selector B and outputs
it on T0 thus affecting the 3-uple criteria for SEC2. SEC2 receives signal on selectors A and B. But the output signal is
taken from port T4 using selector A and this configuration does not affect the 3-uple criteria for SEC3. Even if SEC3
outputs its signal on T4, since it receives it on selector B it does affect the 3-uple criteria of SEC4.

4.3 Performances

To check that our algorithms are suitable for use in real networks testing we have measured the performances of the
simulator and of the algorithms on various examples. Examples make use of particular configurations that can be found
in real networks (ADM with SSU mode, microwaves etc...) to validate the correctness of the platform. The graphs below
show the performances measured on 3 networks of different sizes. Two scenarios have been tested: a test for all single
failures of links and a test for all double failures of links.
550
600ms
400ms
40 90
200ms
0ms
8 equipments, 19 links 13 equipments, 38 links 35 equipments, 82 links

Figure 8 - Performances for test of all single failures

44,02
60s
40s
20s 0,32 3,35

0s
8 equipments, 19 links 13 equipments, 38 links 35 equipments, 82 links

Figure 9 - Performances for test of all double failures

4.4 Simulation and evaluation platform

All the algorithms for checking the validity of a network configuration and the simulation engine have been gathered
in a user-friendly platform written in Java. The platform described in [DGF99] is a simulation environment for network
management system. A part of this tool has been written in Java and another adapted so that it can be used to design
SDH synchronization networks. The graphical user interface lets the network designer draw and configure its (virtual)
network, define a scenario for failures generation and then launch the simulation. The detail level of results can be set to
enhance readability.

5. CONCLUSION

The model we have written allows simulation of networks in a very short time. We are currently testing it to work on
much larger networks (hundreds of equipments). The aim is to obtain an algorithm determining a better configuration
than the one submitted by the synchronization network designer. To do so we are going to test multiple configurations
that are modified on "strategic" nodes. By doing an anticipated study of network failures, we can have a network with a
better fault tolerance. We are also working on filtering the simulation results so that weak points of the network are
pointed out.

REFERENCES

[DGF99] Gérard Damm, Stefano Giorcelli and Guy Fouquet, "A Simulation Environment for Dimensioning
Telecommunication Management Systems", Proceedings of ASSET'99 (IEEE Symposium on Application-
Specific Systems and Software Engineering Technology), p. 290-293 Richardson, Texas, USA, March 1999
[ETS462] ETSI EN 300 462-2-1, "Transmission and Multiplexing (TM); Generic requirements for synchronization
networks; Part 2-1: Synchronization network architecture", August 1999
[FER98] Jean-Loup Ferrant, "SDH synchronization tutorial", Alcatel technical report, October 1998
[GHU97] Mike Green, G. Scott Henderson and Ed M. Underwood, "Keeping in sync with SONET", America's
network, September 15th 1997
[ITU783] ITU-T G.783, "Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks", April
1997
[ITU803] ITU-T G.803, "Architecture of transport networks based on the synchronous digital hierarchy (SDH)", June
1997
[ITU811] ITU-T G.811, "Timing characteristics of primary reference clocks", September 1997
[ITU812] ITU-T G.812, "Timing requirements of slave clocks suitable for use as node clocks in synchronization
networks", June 1998
[ITU813] ITU-T G.813, "Timing characteristics of SDH equipment slave clocks (SEC)", August 1996
[KLE96] Thomas Klett, "Alcatel Synchronization Evolution", Alcatel technical report, May 1996
[KLE97] Thomas Klett, "Network synchronization aspects ", Alcatel Telecommunications Review, 1st quarter 1997
[SS96] C. A. Siller & M. Shafi, "Synchronous Optical Network, Synchronous Digital Hierarchy: An overview of
Synchronous Networking ", SONET SDH a sourcebook of synchronous networking, IEEE Press, 1996
[WOL94] Michael Wolf, "Alcatel Network View on Synchronization", Alcatel technical report, October 1994
[WOL97] Dan Wolaver, "In sync with SONET, America's network, February 15th 1997