M3 - 6. Introduction

Introduction

Just as a multiplexing structure is defined for the plesiochronous hierarchy PDH by ITU recommendations, so too is a multiplexing structure defined for the SDH hierarchy, also by these recommendations. This structure defines the standard transmission rates for synchronous signals and the way in which tributary signals from lower levels are transported.

● SDH multiplexing

�❍ Multiplexing map �❍ Containers (C-n): the transport interface �❍ Path overhead (POH) �❍ Virtual containers (VC-n): the unit of exchange �❍ Pointers and payload shift �❍ The STM-1 frame �❍ STM-N

■ Forming STM-N frames ■ Concatenation of AU-4

�❍ Transporting low rate tributaries ■ Containers: C-3, C-2, C-12 and C-11 ■ Virtual containers: VC-3, VC-2, VC-12 and VC-11 ■ Tributary units: TU-12, TU-3 and TU-2 ■ TU multiframes ■ Tributary unit groups: TUG-3 and TUG-2

http://www.trendcomms.com/multimedia/training/broa...%20networks/web/main/m3/temari/seccio6/f_arbre.htm [10/31/2007 9:17:25 PM]

M3 - 6.1. Multiplexing map

Multiplexing map

This shows the paths through which it is possible to configure an STM-1 transport frame.

On the right of the figure we can see the tributaries that can be transported. First these are mapped into their C-n container, then an overhead is added and they become VC-n virtual containers. Next they are aligned when the pointer bytes are associated with them, giving rise to the tributary units and administrative units, TU-n and AU-n respectively. The multiplexing process is the next step, whereby the various units form into groups: TUG-n and AUG (tributary unit groups and administrative unit groups, respectively). Finally these are placed in an STM-n transport frame.

http://www.trendcomms.com/multimedia/training/bro...nd%20networks/web/main/m3/temari/seccio6/mapa.htm [10/31/2007 9:18:04 PM]

M3 - 6.2. Containers (C-n): the transport interface

Containers (C-n): the transport interface

The synchronous network was designed in such a way that it would be able to transport plesiochronous signals, as the existing PDH networks would still be used during a transition period (indeed, synchronous and plesiochronous networks still coexist today). Synchronous transport units were designed to transport plesiochronous signals in SDH networks - these are called containers.

Placing the plesiochronous signals inside a container is a problem of plesiochronous multiplexing, so justification is carried out to adapt the transmission rate of each plesiochronous signal to the rate of its associated container. For this reason, inside a container (which is no more than a frame of bits) we can find the bits of the plesiochronous signal together with the justification control bits and justification oppportunity bits, amongst others, depending on the mapping procedure used, as in the case of the PDH signals themselves. As well as transporting PDH signals, the containers can also transport ATM signals and signals from a metropolitan Ethernet network).

Let us look now at the mapping process for a 140 Mbit/s PDH tributary. On the multiplexing map we can see that the C-4 container should be used, in which the information that arrives will be placed byte by byte.

http://www.trendcomms.com/multimedia/training/broa...tworks/web/main/m3/temari/seccio6/contenedores.htm [10/31/2007 9:18:20 PM]

M3 - 6.3. Path overhead (POH)

Path overhead (POH)

A series of bytes is added to each container (C-n) and these carry information that enables the system to manage this container. These bytes are known as the overhead. Together, the overhead bytes and the container is known as the virtual container. The transmission media and the network elements between the point in which a virtual container is assembled, and the point in which it is disassembled in order to extract the information it is carrying, is called a path. The previously mentioned overhead is therefore called a Path Overhead (POH).

This overhead provides information about the path and lets us monitor different parameters associated with the tributary from the point in which it was introduced into the network until its plesiochronous contents are delivered.

http://www.trendcomms.com/multimedia/training/...%20networks/web/main/m3/temari/seccio6/poh.htm (1 of 2) [10/31/2007 9:18:37 PM]

M3 - 6.3. Path overhead (POH)

http://www.trendcomms.com/multimedia/training/...%20networks/web/main/m3/temari/seccio6/poh.htm (2 of 2) [10/31/2007 9:18:37 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

Virtual containers (VC-n): the unit of exchange

The virtual container (VC) is the unit of transport between the input and output points for the tributaries, whether they are plesiochronous signals, ATM signals or signals from metropolitan Ethernet networks. A basic SDH frame has a capacity of 155 Mbit/s, which means that it can either transport one VC-4 virtual container (designed for plesiochronous signals at 140 Mbit/s) or three VC-3 virtual containers (designed to transport plesiochronous signals at 34 Mbit/s or 45 Mbit/s). The payload of each of these containers can be one high rate tributary or a combination of tributary unit groups that contain low rate signals (see the multiplexing map). The next step consists of placing the VC-4 inside the basic synchronous frame, the STM-1 (synchronous transport module). This STM-1 signal is a continuous frame, like an endless train that permanently runs back and forth between its starting point and its destination and can fit a VC-4 exactly inside its freight cars. Here we can see the most interesting characteristic of the SDH system: the payload can be situated between two frames, that is, one part of the VC-4 can be in one STM-1 frame and the rest in the next frame. In other words, the freight cars of our train are not separate: they are all connected. What is the reason for this? Let us continue with the train metaphor. Imagine a freight train travelling at a constant speed of 155 km/h. The train passes under a device that drops the containers carrying the freight (VC-4 virtual containers) into the freight cars. These containers are dropped at a regular pace (they travel at about 150 km/h down the dispensing pipe), and each of them fits exactly in its freight car. Let us now imagine that there is a fluctuation in this regular pace, and the speed decreases. In this case part of the container will fall on one freight car and part on the next. When the train reaches its destination, the workers who are responsible for unloading the freight cars will need to know which car each container belongs to, in order to send it to the place on the loading bay that has been assigned for it. Fortunately, the train driver has a list showing the freight car where each container starts (since in our system a container can take up two freight cars, and often does so). With this information it is possible to recover all the freight correctly. Why do we let the payload containers be split up between different freight cars? An alternative system could be thought up that would avoid it. By incorporating a buffering system in the device that drops the containers into the freight cars, each container could then be held up if needed for as long as it took for it to fit perfectly in a single freight car. A container held up in this way would then wait for the first freight car into which it would fit completely. The disadvantage of this system is that, if the delays were to build up, the system would need an arbitrarily large buffering capacity, and in addition the delays in the delivery of the freight at its destination could also get to be arbitrarily long.

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (1 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

To get back to SDH transmission, the above solution would lead to unacceptable delays, as well as arbritarily large buffers (temporary storage subsystem). That is why the first solution was adopted. Each STM-1 frame (freight car) receives one VC-4 virtual container that can be split into two consecutive frames. The starting point of each VC-4 container inside the STM-1 frame is indicated by the value of AU-4 pointer bytes in the frame overhead, which increase or decrease their value depending on the bit rate of the VC-4 container. The nominal rate of a VC-4 virtual container is 149.76 Mbit/s.

At this point a paradox arises: if the SDH system is based on the synchronization of the signals, why do fluctuations occur in the bit rates of the virtual containers? The answer lies in the practical limitations of the above mentioned synchronization. SDH networks use a high quality clock for synchronizing the network elements that they are made up of. However, bear in mind that:

● A number of SDH islands exist (for instance, the SDH networks in each country, or even of every operator), each with its own synchronization source - which, although they may be nominally the same, are in fact almost never exactly the same.

● Inside a single SDH network, different types of breakdown may cause a temporary loss of synchronization, in which case every network element switches over to a secondary clock source, which may be its internal clock, of a lesser quality than the one provided by the primary source, and as a result this may lead to frequency offsets (bit rate).

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (2 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.4. Virtual containers (VC-n): the unit of exchange

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/virtual.htm (3 of 3) [10/31/2007 9:18:52 PM]

M3 - 6.5. Pointers and payload shift

Pointers and payload shift

Let us look more closely at the problem of differences in frequency between the tributary and the carrier frame (synchronous transport module). We must accept the fact that the networks are not synchronized, which makes it inevitable that there will be tiny differences of millionths between the nominal values and the real values of the bit rates being looked at, which will build up over time.

What happens when the bit rate of the VC-4 is too slow compared to that of the STM-1 signal? The pointer of the corresponding AU-4 will have to update its value, pointing to a later start position. In order to keep the VC-4 containers contiguous, positive justification is used, that is, stuffing bytes are added. The figure shows how a unitary increment in the pointer value means a shift of three bytes.

What if the rate of the VC-4 is too fast compared to that of the STM-1 signal? In this case a point will be reached where the payload will have to be moved forward to provide extra space for three bytes (known as H3) given up by the AU-4 pointer.

The pointers are placed in set positions inside the carrier frame. The AU pointer (administrative unit) is located directly in the STM-1 frame, while the tributary units (TU) have other pointers that occupy set positions inside the VC-4. To locate a VC-n, first locate the VC-4 and then the TU-n pointer.

Without a doubt, this is the key mechanism in SDH networks: synchronous frames, the STM-1 modules, that transport payloads that may not be synchronized. The pointer mechanism does have a downside, however: a pointer adjustment causes a slip several bits long (for instance, an AU pointer adjustment causes a slip of 24 bits). This slip is unimportant as long as the signal remains inside the SDH network, but when the tributary is extracted from the SDH signal that is transporting it, the phase slip causes phase fluctuation peaks that are difficult for the PDH networks to deal with.

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/puntero.htm (1 of 2) [10/31/2007 9:19:13 PM]

M3 - 6.5. Pointers and payload shift

http://www.trendcomms.com/multimedia/training/b...networks/web/main/m3/temari/seccio6/puntero.htm (2 of 2) [10/31/2007 9:19:13 PM]

M3 - 6.6. The STM-1 frame

The STM-1 frame

Finally we come to the basic STM-1 carrier frame, which consists of two overheads, one pointer and a space for the payload. The overheads are the regeneration section overhead (RSOH), associated with the regenerators, and the multiplex section overhead (MSOH), associated with the multiplexers. The space for the payload carries the VC-4 container, the first byte of which is signalled by the AU-4 pointer and which is allowed to move in order to accommodate frequency variations. In previous sections we have looked at an example in which a 140 Mbit/s signal was mapped into a VC-4, but the multiplexing map lets the STM-1 signal transport other types of plesiochronous signals and even combinations of signals. All the possibilities are shown in the table below:

Composition 2 Mbit/s 34 Mbit/s 140 Mbit/s

1xVC-4 0 0 1

3xVC-3 0 3 0

21xVC-12+2xVC-3 21 2 0

42xVC-12+2xVC-3 42 1 0

63xVC-12 42 1 0

Table 1.- Composition of an STM-1 signal: possibilities

The basic transport rate is 155.52 Mbit/s and is defined in the ITU-T recommendation G.707. The basic STM-1 frame is represented, for the sake of simplicity, as a rectangular structure of 270 columns and 9 rows, which gives a total of 270 x 9 = 2430 bytes. The frame period is therefore:

(2430 byte x 8 bit/byte)/155.52·106bit/s = 125ms.

As mentioned above, the overhead of an STM-1 signal (SOH) is divided into two parts: the MSOH and the RSOH. The overheads contain information from the system itself, which is used for a wide range of management functions, such as monitoring transmission quality, detecting failures, managing alarms, data communication channels, service channels, etc. These functions will be described in more detail in the section on network management services.

The VC is pointed at by the AU pointer; for the case of an VC-4, the virtual container and the pointer together are referred to as level 4 administrative unit, or AU-4 for short.

http://www.trendcomms.com/multimedia/training/...20networks/web/main/m3/temari/seccio6/stm1.htm (1 of 2) [10/31/2007 9:19:26 PM]

M3 - 6.6. The STM-1 frame

http://www.trendcomms.com/multimedia/training/...20networks/web/main/m3/temari/seccio6/stm1.htm (2 of 2) [10/31/2007 9:19:26 PM]

M3 - 6.7. STM-N

STM-N

By multiplexing basic STM-1 frames, STM-N higher order frames can be formed. This section looks at the options for doing so in more detail (direct or indirect multiplexing), along with the concept of concatenation.

http://www.trendcomms.com/multimedia/training/bro...nd%20networks/web/main/m3/temari/seccio6/stmn.htm [10/31/2007 9:19:40 PM]

M3 - 6.7.1. Forming STM-N frames

Forming STM-N frames

The basic frame in the SDH hierarchy is the sychronous transport module STM-1. The hierarchy defines higher order frames whose bit rates are obtained by multiplying successively by four. For the sake of simplicity, each of the bit rates is usually referred to by its rounded-off value, as shown in the table:

Frame Bit rate (kbits/s) Rounded-off bit rate

STM-1 155.520 155 Mbit/s

STM-4 155.520 x 4 = 622.080 622 Mbit/s

STM-16 155.520 x 16 = 2.488.320 2.5 Gbit/s

STM-64 155.520 x 64 = 9.953.280 10 Gbit/s

Table 2.- SDH sychronous transport modules

To form an STM-N synchronous transport module from an STM-1, AU-4 byte-interleaved multiplexing is used, adding a new overhead; this is because the multiplexers take apart the section overheads received and add new overheads to the multiplex signals they transmit.

Like the STM-1 frame, the STM-N frame is represented as a rectangular structure of 270 x N columns and 9 rows, which gives a total of 270 x N x 9 = 2430 x N bytes. Nonetheless, the frame period remains the same as that of the STM-1 frame: 125ms. The new section overhead is therefore 9 x N columns and 8 rows (one row is taken up by the AU-N pointer, which has been formed by interleaving the bytes).

When looking at the STM-N frames, the concept of indirect multiplexing must be introduced. To explain this, let us look at the example of the STM-16 frame. Forming one of these frames by direct multiplexing means that it has been formed by interleaving bytes from 16 STM-1 frames. But an STM-16 structure can also be obtained from 4 STM-4 frame, that is, by indirect multiplexing (not directly from STM-1 frames). In this case, the interleaving is carried out in blocks of 4 bytes. The end result is therefore the same as that achieved by interleaving bytes from STM-1.

In addition to its functions outlined in previous sections, the pointers mechanism also facilitates the construction of STM-N. In effect, due to the imperfection that is inherent to the synchronization of networks, the STM frames reach the multiplexers with random relative alignments, that is, some of them out of phase with respect to the others. Nonetheless, the STM-N higher order frame that leaves the multiplexer keeps its bytes grouped together in a single block. The payloads of the frames

http://www.trendcomms.com/multimedia/training/b...tworks/web/main/m3/temari/seccio6/formacion.htm (1 of 2) [10/31/2007 9:20:10 PM]

M3 - 6.7.1. Forming STM-N frames

to the multiplexed can be interleaved without needing prior alignment, since the virtual containers will have a pointer value that has been recalculated in the overhead of the outgoing frame.

http://www.trendcomms.com/multimedia/training/b...tworks/web/main/m3/temari/seccio6/formacion.htm (2 of 2) [10/31/2007 9:20:10 PM]

M3 - 6.7.2. Concatenation of AU-4

Concatenation of AU-4

Supposing we want to transmit a broadband signal of hundreds of Mbit/s inside an SDH signal. The SDH system does not define optimized containers for transporting tributary signals whose bit rate is higher than 140 Mbit/s. This means that a signal with a transmission rate of higher than 140 Mbit/s cannot be packed in any predefined container. So, how can we transport such a signal?

The concatenation mechanism provides a solution to this problem. It consists of combining the number of virtual containers needed to form a virtual container whose capacity is greater than or equal to the capacity required.

ITU recommendations define the concatenation of VC-2 and VC-4 virtual containers. For a signal of hundreds of Mbit/s it is best to associate the structures with the largest capacity available, that is, the VC-4, capable of accomodating signals of up to 140 Mbit/s. Additionally, the STM-4 structure provides a rate of 622 Mbit/s. The process consists of forming a container based on several concatenated VC-4 that takes up the whole STM-4 frame. Note that the structure is analogous to that of an STM-1 in relation to its VC-4: The STM-4 frame transports a single virtual container, instead of transporting 4 byte-interleaved VC-4 from other STM-1 frames. Concatenation guarantees the integrity of a sequence of bits in the broadband signal transported.

The STM-4c frame (STM-4 with concatenation) has a space of 1040 columns for the payload. Since it is a virtual container, called VC-4-4c (the last 4 due to the fact that four VC-4 are concatenated), one column is reserved for the path overhead (POH) and 3 columns are for fixed stuffing, leaving 1040 columns for the C-4-4c container. It can easily be seen that this container has a capacity of 599.040 Mbit/s, enough to transport standard broadband signals (for the sake of simplicity, in this case we talk about 600 Mbit/s broadband signals, rounding up the bit rate). The VC-4-4c container is standardized for transporting ATM and other broadband signals. ITU-T usually considers pointers too, so we talk about AU-4-Xc transported over STM-N. The value of X is only limited by the maximum payload capacity of the STM-N used. In the previous example X=4 and N=4. Other possible values for X=4 are N=16 and N=64, although for the moment this is more theoretical than of any practical application.

The AU-4-4c pointer is formed by interleaving the bytes of the pointers of the concatenated AU-4. Before interleaving, the first AU-4 takes the typical values of any conventional AU-4 pointer, while the remaining AU-4 pointers take fixed values in their first bits, to indicate concatenation.

VC-4-4c can be transported in STM-16 and STM-64 frames too.

http://www.trendcomms.com/multimedia/training/broad...tworks/web/main/m3/temari/seccio6/concatenacion.htm [10/31/2007 9:20:32 PM]

M3 - 6.8. Transporting low rate tributaries

Transporting low rate tributaries

The transport of plesiochronous signals from hierarchical levels under 140 Mbit/s in SDH networks defines a series of synchronous signals that make up the elements of the multiplexing map previously introduced. This section presents these elements and their composition.

http://www.trendcomms.com/multimedia/training/broadband%20networks/web/main/m3/temari/seccio6/baja.htm [10/31/2007 9:21:11 PM]

M3 - 6.8.1 Containers: C-3, C-2, C-12 and C-11

Containers: C-3, C-2, C-12 and C-11

So far we have looked at the transport of tributaries in STM frames in the VC-4 container, which defines a higher order path. However, it is more common to use tributaries at lower rates that define lower order paths. Other containers exist for these, defined in such a way as to optimize their transport: C11, C12, C2 and C3 (see also the multiplexing map):

Container Carries signals at

C-11 1.544 Mbit/s

C-12 2.048 Mbit/s

C-2 6.312 Mbit/s

C-3 34.368 Mbit/s and 44.736 Mbit/s

C-4 139.264 Mbit/s

The containers contain the bits of the tributary signal and other justification opportunity and justification control bits or additional information (for C-11 and C-12).

http://www.trendcomms.com/multimedia/training/broa...rks/web/main/m3/temari/seccio6/masContenedores.htm [10/31/2007 9:21:42 PM]

M3 - 6.8.2. Virtual containers: VC-3, VC-2, VC-12 and VC-11

Virtual containers: VC-3, VC-2, VC-12 and VC-11

Virtual containers are formed when the corresponding path overhead (POH) is added to the C-n containers. The virtual containers VC-11 and VC-2 are the result of mapping in the American plesiochronous hierarchy, but here we will limit ourselves to describing the virtual containers for European PDH signals.

For 34 Mbit/s signals mapped into VC-3 containers, from the multiplexing map it can be seen that the VC3 can be transported inside a VC-4 or can be multiplexed in threes directly over the STM-1 frame. This second case defines a multiplexing route that permits compatability with interfaces from the North American hierarchy STM-0 (51 Mbit/s) via an AU-3 administrative unit.

In the first case a VC-4 virtual container transports three VC-3. There are three TU-3 pointers that locate the VC-3 with respect to the TU-3, pointing at the J1 byte, the first of the POH of a VC-3.

In the case of VC-3 via AU-3 there are three AU-3 pointers in the STM-N frame that indicate the beginning of the respective virtual containers. The pointer bytes appear interleaved in the space assigned for them in the structure of the synchronous transport module.

The VC-12 (and likewise the VC-2 and the VC-11) must be transported in other containers with a greater capacity (VC-3 or VC-4) before being introduced in the STM-1 frame. The containers with a greater capacity, which in the case of European countries will be of the type VC-4, can transport up to 63 VC-12 in the STM-1 frame (see the table showing the possible composition of an STM-1 frame). The VC-4 container has 63 pointers that find the location of each of the VC-12 transported with respect to the VC-4. Each of these pointers signals the start byte of the respective path overheads (POH), the V5 byte, which is the first in the sequence. Together, each pointer and its VC-12 virtual container is called a tributary unit (TU-12), so the pointers are known as TU pointers.

http://www.trendcomms.com/multimedia/training/broad...0networks/web/main/m3/temari/seccio6/masVirtual.htm [10/31/2007 9:22:10 PM]

M3 - 6.8.3. Tributary Units TU-12, TU-3 and TU-2

Tributary Units TU-12, TU-3 and TU-2

So that the VCs can really float through the network, a pointer is needed that signals the start of the POH, as has been mentioned in previous sections. Together, the pointer and the VC-n make up the tributary unit (TU). The process of adding the pointer is known as alignment. The TU-3 corresponds to the VC-3, the TU-2 corresponds to the VC-2 and the TU-12 corresponds to the VC-12 and also the VC-11.

http://www.trendcomms.com/multimedia/training/broa...20networks/web/main/m3/temari/seccio6/unidades.htm [10/31/2007 9:22:31 PM]

M3 - 6.8.4. TU multiframes

TU multiframes

The processes of mapping in virtual containers associated with lower order paths define what are known as TU multiframes. The lower order paths are VC-11, VC-12, VC-2 and VC-3 paths. The higher order paths are VC-4 and also VC-3, which is thought of as a higher order path if it follows a multiplexing path via AU-3 (see the multiplexing map). For VC-11 and VC-12 containers, multiframes are only defined in floating mode.

In the case of 2 Mbit/s signals, the multiframe is formed by associating four of these signals and their corresponding TU-12. Each of these TU-12 travels in the VC-4 of a different STM-N frame. There exists a multiframe overhead formed by the first bytes of the TU-12: 4 bytes in total. The first two bytes make up the pointer of the VC-12, that is, they signal where the multiframe payload begins. Inside the VC-4 path overhead, there is a multiframe indication byte (called H4) that indicates the number of TU in the multiframe that contains the following STM-N signal.

http://www.trendcomms.com/multimedia/training/broad...networks/web/main/m3/temari/seccio6/multitramas.htm [10/31/2007 9:22:57 PM]

M3 - 6.8.5. Tributary unit groups: TUG-2 and TUG-3

Tributary unit groups: TUG-2 and TUG-3

The multiplexing map shows how an AU-4 container can be formed from a VC-4 that contains a C-4 or three TUG-3 multiplexed by byte interleaving, that is, three groups of level three tributary units.

A tributary unit group (TUG) is an SDH signal made up from the byte-interleaved multiplexing of tributary units (TU). In other cases lower order TUG are multiplexed to form higher order TUG (for instance, seven multiplexed TUG-2 form one TUG-3), and in other cases a TUG is formed from a single tributary unit (for instance, a single TU-3 is enough to form a TUG-3).

An example may be useful to illustrate this multiplexing. Let us consider a VC-4 made up of three TUG-3. Let us now consider one of these TUG-3. Imagine we wanted to introduce a mixed payload in this TUG-3 consisting of nine TU-12 and four TU-2. The nine TU-12 can be mutiplexed in threes and can take up three TUG-2. The four TU-2 will take up four TUG-2. In total there are seven TUG-2 that can be multiplexed to form a TUG-3.

http://www.trendcomms.com/multimedia/training/b...0networks/web/main/m3/temari/seccio6/grupos.htm (1 of 2) [10/31/2007 9:23:17 PM]

M3 - 6.8.5. Tributary unit groups: TUG-2 and TUG-3

http://www.trendcomms.com/multimedia/training/b...0networks/web/main/m3/temari/seccio6/grupos.htm (2 of 2) [10/31/2007 9:23:17 PM]