SDH

 

This is a second page about data transmission over fibre, it is briefly about SONET, but mostly about SDH. I have found SDH to be quite a hard transport mechanism to get my head round - it is very different from Ethernet and MPLS, but it still widely used in trunking and fibre WAN`s.

One of the major problems that I have met is that none of the webpages about SDH have the full story. They all have just some bit of it, and miss out other bits. So it has been very time consuming continually swapping between different sites, trying to build up a wider picture of what SDH is about.

There is still loads of stuff I haven`t found about - it is a complicated technology, with a lot of meat to it. So this webpage is yet another incomplete picture. To provide a full description of SDH would take a whole book !

 

Sonet and SDH

First off - their full names :-

SONET and SDH are in some respects quite similar, but they are different, and not directly interconnectable.

SONET is an American standard, and is mostly used in America and Japan. SDH is a European standard.

They are both a mechanism for time-shared multiplexing of numerous 64kb/s PCM data streams onto one carrier.

In both of them, there is a very rigidly designed multiplexing structure, where a specific 64kb/s PCM data stream is always carried in exactly the same time slot in every frame, so the multiplexed signal can be passed through an ADM - Add Drop Multiplexer - which can pick out that one 64kb/s PCM data stream from the thousands of other ones that are all multiplexed together.

It is this specific feature of SONET and SDH that was one of the main reasons for the development of SONET and SDH. There was a previous time-shared multiplexing mechanism known as PDH - Pleisiochronous Digital Hierarchy - in which this was not possible. If one specific 64kb/s data stream was required, then the whole carrier had to be de-multiplexed, the one 64kb/s data stream extracted, and all the other 64kb/s data streams re-multiplexed for onward transmission.

The time-slot mapping in SDH is the same as the time-slot mapping in SONET.

Finally for this section, the reason that SONET/SDH are very different from Ethernet and MPLS is that -

That`s as far as I am going with SONET, from now on, this page is about SDH.

 

SDH speeds

SDH uses a framing structure known as STM`s - Synchronous Transport Modules. There are now five different STM`s, each one carries four times the data than the one below it carries.

However just to confuse things, different pages on the web have different speeds listed, I`ve no idea which are right, but the figures shown are the 4x multiples of the lower speed.

I am not sure how much STM-256 is being used. I have also seen a single reference to STM-1024, which operates at 160Gb/s. Whether it exists in reality I have no idea.

 

SDH frames

In the IP world, the data is carried in a packet, which has two basic parts :-

Each packet is a self contained unit, which can transverse the network, though they may be linked to others, if more data than will fit into one packet needs to be carried.

In the ethernet world, each IP packet is wrapped up in a layer 2 frame, and again, the frame has two basic parts :-

Each frame is completely separate from other frames, and may travel across the network via a different path from other frames moving between the same sending and receiving nodes.

In SDH, the blocks of data are also carried in frames, but SDH frames are somewhat different both in concept and in practice. SDH frames aren`t the easiest things to understand, if you`re more used to thinking about ethernet frames.

For SDH, I think it is easier to think of the frames being constructed around "packets", but in a specific way. An SDH frame can be thought of as being based on a rigid sequence of 9 "packets". In the different STM frames, the "packet" size is different, so the following description refers to the STM-1 frame.

Within each "packet, there is a header block, and a data block. However the header block doesn`t contain the header information for that particular "packet" - it contains a portion of the headers for the whole frame - to get the header information for the whole frame, the node receiving the transmission needs all 9 "packets" in the sequence, and it can build the header information out of the 9 "packets".

In the STM world, the header information is called the "Overhead", and the data information is called the "Payload".

In an STM-1 frame, the header part of each "packet" is 9 bytes long, and the data part of each "packet" is a fixed length, and is 261 bytes long, giving 270 bytes for each "packet".

This means that the whole STM-1 frame is 9 x 270 = 2430 bytes long, and it takes 125 microseconds to pass any fixed point on the network - there are therefore 8000 frames transmitted per second.

8000 frames x 2430 bytes per frame = 19,440,000 bytes per second = 155,520,000 bits per second.

The various higher rate STM frames also take 125 microseconds to pass a fixed point on the network. The increased bit rate and carrying capacity are obtained by increasing the size of the frames by a factor of four, for each higher STM rate.

STM frames are usually shown as an array - where "packet" 1 forms the first row of the array, "packet" 2 forms the second row, etc. So you end up with an array with 9 rows ( one for each of the 9 "packets" ), and with 270 columns.

The overhead for the whole frame occupies the first 9 columns of the array. All the other columns carry the data information - equivalent to 1 byte for each 64kb/s PCM data channel.

Once this is done, it is easier to see how the overhead for the STM-1 frame is set up :-

Since the overhead occupies the first 9 columns, and there are 9 rows in the array, there are 81 bytes in each frame occupied by the overhead.

The first six bytes of the first row of the overhead are used to identify the start of the SDH frame -

Amongst the bytes in the lower rows, there are four bytes that are used for parity checking - however they are not a parity check for the frame that contains them, they are a parity check for the previous frame. It looks as if in various places within the frame there are 4 bytes, named K1, K2, K3, and K4, that can contain various management and status messages. It also appears that there are various places within the several processes involved in producing the final SDH bit stream that signals are sent back from, to the sending node. So I guess these various parts build into quite a complex status and alarm mechanism.

None of the bytes in the first row - first 9 columns are scrambled. Everything else in the frame is scrambled.

 

Scrambling

When an Add Drop Multiplexer is to be used to add or extract any particular subset of the payload data, it needs to know the clock rate of the SDH signal. This isn`t transmitted as a separate signal, so the ADM has to extract the clock rate of the STM frame from the bit stream, by looking at the transitions between "0" and "1".

However if the bit stream contains a long stream of "0"`s or "1"`s, there are no transitions, so the clock rate can`t be extracted.

In order to prevent this, a technique called scrambling is used to break up long streams of the same polarity, by changing some of the bits - this is done by the sending node. The bit scrambling is done in a specific, defined way, and the ADM can use the scrambled bit stream to extract the clock signal, and then de-scramble the bit stream to extract the original data.

 

Containers

SDH can carry many different types of bit streams within the multiplex structure. It does this through the technique of containers for the incoming bit streams.

When a bit stream arrives at the edge of an SDH network, the ingress multiplexer sets up a series of containers, and the incoming bit streams drop into this series of containers. The type of container is specific to the type of incoming bit stream.

So for example, if the incoming bit stream is a PDH bit stream, there are five different containers called C11, C12, C2, C3, C4 - with the different containers for the different speeds of the PDH bit stream.

These containers are then assembled into Virtual Containers by the addition of a leading single column called the Path Overhead, which carries administrative information about the container that follows. These virtual containers are then fitted in to the 261 columns of the Payload section of the STM frame. Because of the additional column, the virtual containers have a higher bit rate than the original Containers.

So a VC-4 virtual container will exactly fill the payload section of the STM-1 frame. However there will be multiple virtual containers of the other types within the 261 columns of the payload section of the STM-1 frame.

Because of this, the VC-4 virtual containers are treated differently from the other virtual containers.

The VC-4 virtual containers become AU-4`s - ie, Administrative Units - by the creation of pointers ( bytes H1, H2, H3 ) in the fourth row of the STM-1 frame overhead. These pointers tell the receiving node where the virtual containers are within the STM frame payload section.

Just to make things a bit more complicated, the boundaries of a VC-4 virtual container don`t have to coincide with the boundaries of the STM frame payload section - it can be shifted left or right. So an STM frame payload section can contain parts of two VC-4 virtual containers, with the boundaries between them anywhere within the STM frame payload section - which is why the pointers are required.

It appears that there are two ways that the VC-3 virtual containers can be handled :-

The three lower order virtual containers - ie, VC-11, VC-12, VC-2 - can also be treated in two ways.

First off, each VC maps into a Tributary Unit - ie, TU-11, TU-12, TU-2 - then the tributary units can be sub-multiplexed ( TUG-2 ) - then :-

 

Bit stuffing

One of the things that SDH can cope with is incoming bit streams that are not synchronised with the SDH clock.

It can do this through the use of bit stuffing - when an incoming bit stream arrives and is fed into the containers, and during the multiplexing, empty bits are added to the bit stream, so that the relative timing of the incoming bit stream and the SDH containers are brought into line. To accomodate these extra bits, the containers are designed with a larger capacity than that required to accomodate the incoming bit stream. So the incoming bit stream can "float" around in time within the containers.

 

Some final titbits

 

 

 

 

 

website design by ron-t

 

website hosting by freevirtualservers.com

 

© 2024   Ron Turner

 

+                                   +  

 

Link to the W3C website.   Link to the W3C website.