How Does a SONET Network Element Acquire Frame Synchronization with an incoming STS-1 Signal?

This blog post describes how the Receive STS-1 Framer uses the SEF/LOF Declaration Clearance State Machine diagram to acquire and maintain STS-1 Frame Synchronization.

Introduction

An STS-1 Network Element relies on the A1 and A2 bytes within the Section Overhead (SOH) to acquire and maintain STS-1 Frame Synchronization. 

Figure 1 illustrates the Section Overhead bytes with the A1 and A2 bytes highlighted.

The STS-1 Section Overhead (SOH) Bytes within the A1 and A2 bytes highlighted

Figure 1, Illustration of the SOH with the A1 and A2 bytes highlighted. 

Whenever an STS-1 Transmitter (or STE) generates and transmits an STS-1 frame, it will always set the A1 and A2 bytes to the following values:

  • A1 = 0xF6
  • A2 = 0x28

I show an additional drawing of SOH, with the values for A1 and A2 filled in.

The SONET STS-1 Section Overhead (SOH) Bytes with values inserted into the A1 and A2 byte-fields

Figure 2, Illustration of the SOH with the A1 and A2 bytes set to their actual values.

Receive STS-1 Framer Tries to Acquire STS-1 Frame Synchronization

The Receive STS-1 Framer (at the remote end of the network – receiving this STS-1 signal) will search for and locate the A1 and A2 bytes (within its incoming STS-1 data stream). As the Receive STS-1 Framer receives this signal, it will attempt to acquire and maintain STS-1 Frame Synchronization with this incoming STS-1 data stream.

A given STE (receiving this STS-1 signal) will declare and clear either of the following defect conditions based on its ability to receive the A1 and A2 bytes.

  • dSEF – Severely Erred Frame Defect
  • dLOF – Loss of Frame Defect

The SEF/LOF Defect Declaration/Clearance State Machine

The decision to declare and clear the dSEF and/or dLOF Defects is best understood by reviewing the “SEF/LOF Defect Declaration/Clearance State Machine” Diagram. I show this diagram below in Figure 3. 

The SONET STS-1 Frame Acquisition State Machine Diagram.

Figure 3, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram.

You can see that the “SEF/LOF Declaration/Clearance State Machine Diagram” contains the following four states.

  • The In-Frame (or SEF = 0/LOF = 0) State (the Most Desirable State to Operate in).
  • The SEF = 1/LOF = 0 State (Declaring the SEF – Severely Erred Frame defect condition).
  • The SEF = 1/LOF = 1 State (SONET Framer has not located the A1 and A2 bytes at all), and
  • The SEF = 0/LOF = 1 State (The SONET Framer has cleared the SEF defect and is now trying to clear the LOF defect condition).

Let’s Take a Walk through the SEF/LOF Declaration/Clearance State Machine Diagram

Let’s start at the “SEF = 1/LOF = 1” state.

The dSEF = 1/dLOF = 1 State

I show a drawing of the SEF/LOF Declaration/Clearance State Machine Diagram with the “SEF = 1/LOF = 1” state highlighted in Figure 4.

The SONET Framing State Machine Diagram wtih dSEF = dLOF = 1 State Highlighted.

Figure 4, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram – with the SEF = 1/LOF = 1 state highlighted.

We hope the Receive STS-1 Framer is rarely operating in this state.

Let’s assume (and hope) that the Receive STS-1 Framer only operates in this state upon system power-up. Shortly after power-up, the Receive STS-1 Framer will operate in this state as it receives an STS-1 Data Stream.

As it receives this STS-1 Data Stream, it will parse this incoming data stream and search for the A1 and A2 bytes.

Once it locates (what it believes) are the A1 and A2 bytes (e.g., 0xF628), it will note this location, and it will search again exactly 810 bytes (e.g., one STS-1 frame period) later.

If it determines that the framing pattern (e.g., 0xF628) is NOT present, then the Receive STS-1 Framer will assume that it was momentarily fooled by data bytes mimicking the A1, A2 bytes.

On the other hand, if the Receive STS-1 Framer detects the framing alignment pattern again (exactly 810 bytes after finding it the first time), then it will “believe” that it is on to something and transition into the “dSEF = 0/dLOF = 1” state.

NOTE: In this case, the Framer will transition into the “dSEF = 0/dLOF = 1” state after the Framer has correctly detected the A1 and A2 bytes in two consecutive STS-1 frames.

The dSEF = 0/dLOF = 1 State

I show a drawing of the SEF/LOF Declaration/Clearance State Machine Diagram with the “dSEF = 0/dLOF = 1” state highlighted in Figure 5.

The SONET Framing State Machine Diagram with dSEF = 0, dLOF = 1 State Highlighted.

Figure 5, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram – with the dSEF = 0/dLOF = 1 state highlighted.

Once in this state, the Receive STS-1 Framer block will clear the dSEF (Severely Erred Frame) alarm. It will also continue to check the incoming A1 and A2 bytes for the Framing Pattern.

Telcordia GR-253-CORE states that “the SONET NE shall terminate a LOF defect 1ms to 3ms after terminating the SEF defect on the incoming SONET signal if the SEF defect is not (re) detected before the LOF defect is terminated.”

This is why we labeled the transition (from the “dSEF = 0/dLOF = 1” State to the “In-Frame” State) as “Unerred SONET Frames Are Detected in a User Number of SONET Frames“.

The user can select the criteria for clearing the dLOF defect to either be “1ms or 3ms” of Operating in the dSEF = 0 condition (with no re-declaration of the dSEF condition during that period).

Either way, if the SONET NE can meet these requirements, it will transition into the In-Frame State.

The In-Frame State

I show a drawing of the dSEF/dLOF Declaration/Clearance State Machine Diagram with the “In-Frame” state highlighted in Figure 6.

SONET Framing State Machiune Diagram with the In-Frame (dSEF = dLOF = 0) State Highlighted

Figure 6, Illustration of the dSEF/dLOF Declaration/Clearance State Machine Diagram – with the In-Frame State Highlighted.

We hope that the Receive STS-1 Framer will operate in this state for most of its lifetime.

When the Receiver STS-1 Framer circuitry is operating in this state, the SONET NE can now do its other processing of STS-1 frames (checking for B1 bytes errors, using the H1 and H2 bytes to search for the SPE, etc.).

All of these things are possible whenever the Receiver STS-1 Framer is operating in this state. None of these things are possible if the Receiver STS-1 Framer is not operating in this state.

Is it possible for “Bad Things to Happen” such that We Have to Leave this State?

Yes, all good things “can and sometimes do come to an end.”

In other words, it is possible for “bad things to happen” that will cause the Receive STS-1 Framer to leave the “In-Frame” state.

If the Receive Framer were to detect FA1/FA2 errors within 4 consecutive STS-1 Frame, then it would declare the dSEF defect condition and transition into the “dSEF = 1/dLOF = 0” state.

The dSEF = 1/dLOF = 0 State

I show a drawing of the dSEF/dLOF Declaration/Clearance State Machine Diagram with the “dSEF = 1/dLOF = 0” state highlighted in Figure 7.

The SONET Framing State Machine Diagram with the dSEF = 1, dLOF = 0 State Highlighted.

Figure 8, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram – with the SEF = 1/LOF = 0 State Highlighted.

If the Receive STS-1 Framer transitions into this state, then one of two things can happen from here.

The Good Option

The burst of errors could go away, and the Receive STS-1 Framer block could (then) detect two consecutive STS-1 Framers with NO FA1/FA2 byte errors.

If this occurs, the Receive STS-1 Framer block will clear the dSEF defect and transition back into the “In-Frame” state (the Good State). Once again, I show a drawing of the dSEF/dLOF Declaration/Clearance State Machine Diagram with the “In-Frame” state highlighted in Figure 9.

SONET Framing State Machiune Diagram with the In-Frame (dSEF = dLOF = 0) State Highlighted

Figure 9, Illustration of the dSEF/dLOF Declaration/Clearance State Machine Diagram – with the dSEF = 0/dLOF = 0 State Highlighted.

And there is the Bad Option.

The Bad Option

The burst of errors does not go away, and the Receive STS-1 Framer continues to operate continuously in the “dSEF Condition” for 3ms. When this occurs, then the Receive STS-1 Framer will declare the dLOF defect, and we will transition back into the “dSEF = 1/dLOF = 1” state.

In What States will the Receive STS-1 Framer declare the dLOF Defect Condition?

The Receive STS-1 Framer block will declare the dLOF defect condition whenever it is operating in the following two states:

  • dSEF = 1/dLOF = 1
  • dSEF = 0/dLOF = 1

In short, whenever dLOF = 1, then the Receive STS-1 Framer block declares the dLOF (Loss of Frame) defect condition.

In What States is the Receive STS-1 Framer NOT declaring the dLOF Defect Condition

The Receive STS-1 Framer block will clear the dLOF defect condition whenever it is operating in the following two states:

  • In-Frame
  • dSEF = 1/dLOF = 0

In short, whenever dLOF = 0, then the Receive STS-1 Framer clears the dLOF defect condition.

In Figure 10, I illustrate the SEF/LOF Declaration/Clearance State Machine Diagram, with two states immersed in “green shade” and the other two in “red shade.”

The SONET Framing State Machine Diagram - Shaded to Indicator which states in which the Framer declares and clears the LOF defect.

Figure 10, Illustration of the SEF/LOF Declaration/Clearance Machine Diagram – In which states will the Receive STS-1 Frramer declare or clear the dLOF defect condition.

The two states immersed in the Green Shade are those states in which the Receive STS-1 Framer will clear the dLOF defect condition.

On the other hand, the states immersed in the Red Shade are those states in which the Receive STS-1 Framer will declare the dLOF defect condition.

This concludes our introduction to the “SEF/LOF Declaration/Clearance” State Machine.

What is the Role/Function of the Path Overhead (POH) Bytes in a SONET Signal?

This blog post presents a brief description of the role/function of the Path Overhead (POH) Bytes.

What is the Purpose of the Path Layer in the SONET Network?

The purpose of the Path Layer is to support and manage the transport of “non-SONET” client data from the point where it gets mapped into a SONET signal to the point where it exits (or is de-mapped) from that same SONET signal.

Examples of non-SONET data being mapped into and transported via a SONET Network are DS1, E1, DS3, ATM, Ethernet, etc.

Each STS-N SPE consists of nine (9) Path Overhead bytes.

Figure 1 illustrates the Location of the Path Layer within our drawing of Optical Equipment.

Identifcation of the Path Layer within our SONET Reference Model.

Figure 1, Location/Identification of the Path Layer, within our drawing of Optical Equipment

What is Path Terminating Equipment (PTE)?

Any piece of equipment that manages the transmission and reception of non-SONET data, or client signal, from the point that it enters the SONET network to the point that the SONET Network is terminated (and the client signal is de-mapped from the SONET signal) is referred to as a PTE (Path Terminating Equipment).

A PTE will manage the transmission and reception of non-SONET client data (through the SONET network) via the “Path Overhead” (POH) bytes.

NOTE:  All PTEs are also LTEs and STEs.

Therefore, all PTEs will manage the transmission and reception of STS-N data via both the “SOH,” “TOH,” and “POH” bytes.

The POH bytes reside within the first column in the SPE (Synchronous Payload Envelope). 

In Figure 2, I show a picture of an SPE with the POH Bytes included.

The STS-1 Synchronous Payload Envelope (SPE)

Figure 2, Illustration of an SPE with the POH Bytes

The Definition of the Path Overhead (POH) Bytes

We will briefly define each of the POH bytes (within an SPE) below.

The J1 – Path Trace Byte

In Figure 3, I show a picture of the STS-1 SPE and POH with the J1 byte highlighted.

STS-1 Synchronous Payload Envelope with the J1 Byte Highlighted

Figure 3, Illustration of the STS-1 SPE and POH bytes, with the J1 Byte Highlighted

The J1 byte is the very first byte within the SPE.  This is also the byte that the H1 and H2 bytes (e.g., the Pointer Bytes) point to with an STS-N frame. 

For SONET applications, this byte is used to transport a repetitive 64-byte message so that the receiving Path Terminal Equipment (PTE) can verify its continued connection to the intended transmitting STS-N PTE.

NOTE:  For SDH applications, this byte can be used to transport a repetitive 16-byte message instead.

A given PTE will declare and clear the TIM-P (Path-Trace Identification Mismatch) defect condition. 

The TIM-P defect is typically an indication of a cross-connecting or provisioning error. 

I discuss the TIM-P defect condition in greater detail in another blog post.

B3 – Path BIP-8 Byte

Figure 4 presents the location of the B3 byte within the POH.

STS-1 Synchronous Payload Envelope with the B3 Byte Highlighted

Figure 4, The Location of the B3 Byte within the POH.

The Role of the Transmit PTE (in Handling the B3 Byte)

A Transmitting PTE will compute the contents of the B3 byte by performing a BIP-8 calculation over all bits within the POH and the SPE (after scrambling). 

This byte value is inserted into the B3 Byte field (within the very next outbound SPE) before scrambling the current STS-1 frame. 

The Role of the Receive PTE (in Handling the B3 Byte)
  • As a Receiving PTE receives its STS-1 SPE data stream, it will compute its own BIP-8 value. 
  • Afterward, the Receive PTE will compare its “locally” computed BIP-8 value with the value residing within the B3 byte field of the next STS-1 SPE.
  • If the two values are the same, then the Receive PTE will “conclude” that it has received this STS-1 SPE data in an un-erred manner.
  • If the two values are different, then the Receive PTE  will “conclude” that it received this STS-1 SPE in an erred manner. 
  • We discuss how SONET PTE should flag the occurrence of B3 byte errors in another blog post.

NOTES:

  1. The B3 byte (in SONET) is analogous to the Path BIP within an ODU Frame. 
  2. In another blog post, we will discuss how the Transmit PTE computes the B3 byte and how the Receive PTE Terminal verifies the B3 byte. 

C2 – Path Signal Label Byte

Figure 5 presents the location of the C2 byte within the POH.

STS-1 Synchronous Payload Envelope with the C2 Byte Highlighted

Figure 5, The Location of the C2 Byte within the POH.

The C2 (Payload Label) byte is used to indicate the content (or type of data) that is being carried within the SPE.

The C2 byte also includes the status of Mapped Payloads.

This byte can indicate the occurrence of defects within the data we are transporting via the SPE.

The C2 byte is analogous to the PSI (Payload Structure Identifier) Message that OPU frames transport in OTN. 

I describe the roles of the C2 byte in greater detail in another blog post.

G1 – Path Status Byte

Figure 6 presents the location of the G1 byte within the POH.

STS-1 Synchronous Payload Envelope with the G1 Byte Highlighted

Figure 6, The Location of the G1 Byte within the POH.

We use the G1 byte to transport the following alarm/defect conditions throughout the SONET Network.

  • REI-P (Path – Remote Error Indication)
  • RDI-P (Path – Remote Defect Indication)

I discuss the role of the G1 byte and the transport of the REI-P and RDI-P alarm/defect conditions in another post.

H4 Byte – Mapping Indicator Byte

Figure 7 presents the location of the H4 byte within the POH.

STS-1 Synchronous Payload Envelope with the H4 Byte Highlighted

Figure 7, Location of the H4 Byte within the POH.

The H4 Bye is defined for use as a “mapping-specific indicator” byte. Currently, the only applications that use the H4 byte involve VT-mapping and virtual concatenation.

We discuss how we use the H4 byte in VT-Mapping and Virtual Concatenation applications in other blog posts.

Z3 Byte – Undefined (For Future Use)

Z4 Byte – Undefined (For Future Use)

Z5 (or N1) Byte – STS Tandem Connection Monitoring

Figure 8 presents the location of the Z5 (N1) byte within the POH.

STS-1 Synchronous Payload Envelope with the Z5 or N1 Byte Highlighted

Figure 8, The Location of the Z5 (or N1) Byte within the POH.

We use the Z5 (or N1) byte to support TCM (Tandem Connection Monitoring) in the SONET Network.

We discuss using the N1 byte for Tandem Connection Monitoring in the SONET Network in another blog post. 

The STS-1 Envelope Capacity and Synchronous Payload Envelope

This blog post describes both the Envelope Capacity and the Synchronous Payload Envelope wtihin an STS-1 Frame.

In an earlier blog post, I showed a simple drawing of an STS-1 Frame.  In this drawing, I show the SOH (Section Overhead) and the LOH (Line Overhead).  I show this simple drawing again below in Figure 1.

Basic Structure of a SONET STS-1 Frame with Section Overhead (SOH) and Line Overhead (LOH)

Figure 1, Simplified Drawing of the STS-1 Frame. 

I have also briefly defined and discussed these byte fields in other posts. 

This blog post will briefly discuss the STS-1 Envelope Capacity and the Synchronous Payload Envelope. 

In Figure 1, you clearly see the Envelope Capacity within the STS-1 Frame.  It is clearly marked and takes up much of the STS-1 Frame. 

Where is the Synchronous Payload Envelope (SPE)?

Figure 1 also shows the SPE, but you don’t see it labeled in the Figure. 

What is the Purpose of the Envelope Capacity within the STS-1 Frame?

The purpose of the Envelope Capacity is to transport the client (or user) data. 

What is the Purpose of the SPE within the STS-1 Frame?

The purpose of the SPE is to transport the client (or user) data. 

So, the Envelope Capacity and the SPE have the exact same purpose.

Where is the SPE?

So, Where is the SPE?

The SPE and the Envelope Capacity are (sort of) one and the same.  The SPE has the same role/function as the Envelope Capacity. 

Further, the SPE is located within the Envelope Capacity.  And you can argue that the Envelope Capacity is located within the SPE. 

Location of the Envelope Capacity (within the STS-1 Frame)

The Envelope Capacity begins with the byte just to the right of the C1/J0 Byte (within the SOH).  I show the location of the first byte within the Envelope Capacity in Figure 2.

The 1st Byte within the Envelope Capacity Highlighted within an STS-1 Frame

Figure 2, Illustration of the Very First Byte within the Envelope Capacity

Figure 2 also shows that Byte 1 (the 2nd byte within the Envelope Capacity) is located just to the right of Byte 1, and so on. 

I show the Byte Numbering scheme for the Envelope Capacity below in Figure 3.

Byte Number within the Envelope Capacity of an STS-1 Frame

Figure 3, Byte-Numbering Scheme within the Envelope Capacity, within an STS-1 Frame (from Bytes 0 to Byte 782).

So, Where is the SPE?

The SPE is located in the exact same space as the Envelope Capacity.  However, its Byte Numbering Scheme is different. 

I show a drawing of the SPE below in Figure 4.

The STS-1 Synchronous Payload Envelope (SPE)

Figure 4, The SPE (Synchronous Payload Envelope)

Figure 4 shows the SPE (e.g., the Payload or User Data) along with the Nine Path Overhead (POH) bytes located in the left-most column (of the SPE).  This figure also shows that the STS-1 SPE is a 9 Row x 87 Byte Column Structure (the same size as the Envelope Capacity).

I discuss the role/function of the Path Overhead (or POH) bytes in another blog post

Figure 4 also shows that the very first byte of the SPE is the J1 byte (located in the upper left-hand corner of the SPE).  

What is the Byte-Numbering Scheme of the SPE within an STS-1 Frame

So, What is the Byte-Numbering Scheme of the SPE within an STS-1 Frame

The Byte-Numbering scheme differs for the STS-1 SPE from what we showed for the Envelope Capacity. 

In the case of the Envelope Capacity, Byte 0 is located just to the right of the C1/J0 byte (within the SOH), as I stated earlier.  Further, Byte 0 (within the Envelope Capacity is always in that same location (just East of the C1/J0 byte). 

In the case of the SPE, Byte 0 (e.g., the J1 byte) is located wherever the Pointer Bytes (H1 and H2) say that it is.  The H1 and H2 bytes permit the SONET Receiver to locate the SPE within the STS-1 frame.

The main difference between the SPE and the Envelope Capacity is that the location of the Envelope Capacity is fixed (Byte 0 is always located just East of the C1/J0 Byte). 

In the case of the SPE, Byte 0 (the J1 byte within the POH) can “float” anywhere within the Envelope Capacity. 

The Envelope Capacity and the SPE have the same roles and are of the same size (e.g., 783 bytes).  However, the location of the Envelope Capacity is fixed and aligned with the SOH and LOH bytes within the STS-1 Frame. 

The location of the SPE is not fixed (with respect to the SOH and LOH bytes) and can float. This means that the SPE can begin within any of the 783 bytes within the Envelope Capacity. 

I discuss the roles of the H1, H2, and H3 bytes and the location of the SPE (within the Envelope Capacity) in another blog post. 

However, in Figures 5, 6, 7, and 8, I show a couple of possible locations of the SPE (within the Envelope Capacity).

STS-1 SPE located at Pointer Location 00 0000 0000 within an STS-1 Frame - Frame 1 Shown

Figure 5, Illustration of the SPE, located at Byte 0 (just to the right of the H3 byte)STS-1 Frame N.

STS-1 SPE located at Pointer Location 00 0000 0000 within an STS-1 Frame - Frame 2 Shown

Figure 6, Illustration of the SPE (again located at Byte 0) – STS-1 Frame N+1.

In Figures 5 and 6, I also show that the pointer’s value (within the H1 and H2 bytes) is 0.  In this case, the SPE begins at Byte 0 (the Byte just to the right of the H3 byte).

Please note that the SPE will often straddle across two consecutive STS-1 frames. Figure 5 shows the location of the SPE within STS-1 Frame N. Further, Figure 6 shows the location of the same SPE within the next frame (STS-1 Frame N+1).

An STS-1 SPE located at Pointer Position Number 522.

Figure 7, Illustration of the SPE, located at Byte 522 (just to the right of the C1/J0 byte). 

In Figure 7, I show that the value of the H1 and H2 bytes are 522 (0x020A).  In this case, the SPE happens to be (accidentally) aligned with the SOH and LOF of the STS-1 Frame and located just to the right of the C1/J0 byte.

What Do the Pointer Values (within the H1 and H2 Bytes) Mean?

Finally, I show the Byte Numbering Scheme for SPEs in Figure 8.

What the H1 and H2 (Pointer Values) mean for the beginning of the STS-1 SPE.

Figure 8, What the Values of the H1 and H2 Bytes Mean – for the location of the J1 Byte within the SPE. 

In other words, Figure 8 presents the relationship between the value of the Pointers (within the H1 and H2 byte) and the location of the J1 Byte (within the SPE) within the STS-1 Frame.

Figure 8 shows that a Pointer Value of 0 corresponds with the STS-1 SPE starting at the byte, just to the right of the H3 Byte. I show an example of an SPE at this location in Figures 5 and 6.

This same figure also shows that a Pointer Value of 522 corresponds with the STS-1 SPE starting at the byte, just to the right of the C1/J0 byte. I show an example of an SPE at this location in Figure 7.

Why Don’t We Fix the Location of the SPE within the STS-1 Frame?

One important difference that the SPE has (from that of the Envelope Capacity) is that the location of the SPE can move from time to time. We refer to events (in which the SPE changes its location within the STS-1 Frame) as Pointer Adjustment events.

Whenever these Pointer Adjustment events occur, the values within the Pointer Bytes (e.g., the H1 and H2 bytes) will change. The SONET Network uses pointer adjustment to accommodate timing differences throughout the network.

I will discuss the H1, H2, H3 bytes, and Pointer Adjustments in another blog post.

What is the Role/Function of the Line Overhead (LOH) Bytes in a SONET Signal?

This blog post briefly describes/defines the roles/functions of the Line Overhead Bytes within a SONET signals.

The Line Layer

The Line Layer is the second highest layer within the SONET Reference Model.

The purpose of the Line Layer is to support the transmission of data between the Source and Sink Terminal of a given STS-N signal. 

Figure 1 presents an illustration of some STS-1 and STS-3 circuitry that helps to define the Line.

Illustration of a SONET Line. Also shows Sections, STEs and LTEs

Figure 1, Definition of an STS-N Line

In Figure 1, I show that an STS-3 Line Signal begins and ends at the STS-1 to the STS-3 MUX/DeMUX block (which originates and terminates the STS-3 signal).

What is an LTE – Line Terminating Equipment

Any piece of equipment that manages the transmission and reception of an STS-N data stream, from the point that we create this signal to the point where we terminate this signal.

An LTE will manage the transmission and reception of STS-N data via the Line Overhead (LOH) bytes.

The LOH bytes reside in (and are a subset of) what we often refer to as the “Transport Overhead” (TOH) bytes. Figure 2 illustrates the Line Overhead Bytes within an STS-1 Signal.

Illustration of the LOH (Line Overhead) Bytes within an STS-1 Frame

Figure 2, Illustration of the Line Overhead Bytes within an STS-1 Signal.

All LTEs are also STEs

Therefore, all LTEs will manage the transmission and reception of STS-N data via both the “SOH” and “LOH” bytes. 

We briefly define the SOH bytes (within an STS-1 frame) in another blog post.

Description of the Line Overhead (LOH) Bytes

H1 and H2 Pointer Bytes

Figure 3 highlights the location of the H1 and H2 bytes within the LOH.

The Line Overhead Bytes within an STS-1 signal with the H1 and H2 Bytes Highlighted

Figure 3, The Location of the H1 and H2 bytes within the LOH

The contents of the H1 and H2 bytes are used to indicate the offset between the location of these bytes and the first byte within the STS-1 Synchronous Payload Envelope (SPE).

An STS-1 Transmitter will compute a 10-bit pointer value and will insert this data into the H1 and H2 bytes within a given “outbound” STS-1 frame. 

An STS-1 Receiver will use this 10-bit pointer to locate the SPE within the incoming STS-1 data stream.

I present a more detailed discussion of the H1 and H2 bytes in another blog post.

H3 Pointer Action Byte

Figure 4 highlights the location of the H3 byte within the LOH.

The Line Overhead Bytes within an STS-1 signal with the H3 Bytes Highlighted

Figure 4, The Location of the H3 byte within the LOH.

We typically use the H3 byte for “Frequency” or “Pointer Justification” purposes.

I present a more detailed discussion of the H3 byte in another blog post.

The B2 Byte

Figure 5 presents the location of the B2 byte within the LOH.

The Line Overhead Bytes within an STS-1 signal with the B2 Byte Highlighted

Figure 5, The Location of the B2 Byte within the LOH.

The Role of the Transmit STS-1 Terminal

A Transmitting STS-1 Terminal will computer the contents of the B2 byte by performing a BIP-8 calculation over all bits within the LOH and the Envelope Capacity within a given “outbound” STS-1 frame (after scrambling). 

This byte value is inserted into the B2 Byte field (within the very next outbound STS-1 frame) before scrambling (of the current STS-1 frame).

The Role of the Receive STS-1 Terminal
  • As a Receiving STS-1 Terminal receives the LOH and the Envelope Capacity data (within a given STS-1 frame), it will compute its own BIP-8 value. 
  • Afterwards, the Receive STS-1 Terminal will compare the value of its “locally” computed BIP-8 value with the value residing within the B2 byte-field of the very next STS-1 frame.
  • If the two values are the same, then the Receive STS-1 Terminal will “conclude” that it has received the LOH and Envelope Capacity data in an un-erred manner.
  • If the two values are different, then the Receive STS-1 Terminal will “conclude” that it received the LOH and Envelope Capacity in an erred manner. 
  • We will discuss how SONET STEs should flag the occurrence of B2 byte errors in a future blog post.

NOTES:

  1. The B2 byte (in SONET) is analogous to the Section BIP within an OTU Frame. 
  2. We will discuss how the Transmit STS-1 Terminal computes the B2 byte and how the Receive STS-1 Terminal verifies the B2 byte in another blog post. 

The K1 and K2 (Automatic Protection Switching) Bytes

Figure 6 highlights the location of the K1 and K2 bytes within the LOH.

The Line Overhead Bytes within an STS-1 signal with the K1 and K2 Bytes Highlighted

Figure 6, The Location of the K1 and K2 Bytes within the LOH.

The SONET Protocol uses the K1 and K2 bytes for the following purposes:

  • To transport the APS signaling protocol (Used in BLSR and Linear APS schemes).
  • A given LTE will use the K1 and K2 bytes to detect/clear the following defect conditions within a SONET signal.
    • AIS-L (Line AIS) Defect
    • RDI-L (Line – Remote Defect Inidicator).

We will discuss the APS Protocol in another blog post. 

We will also discuss how the SONET Terminal transmits and declares the AIS-L and RDI-L defect conditions in another post. 

The Line Data Communication Channel (D4 through D12) Bytes

Figure 7 highlights the location of the Line Data Communication Channel Bytes within the LOH

The Line Overhead Bytes within an STS-1 signal with the Line Data Communication Channel (DCC) Bytes Highlighted

Figure 7, The Location of the Line DCC (Data Communication Channel) Bytes – D4 through D12 within the LOH

The D4 through D12 bytes are located in the first STS-1 of an STS-N and are considered as one 576kbps message-based channel for alarms, maintenance, control, monitoring and administering, and other communication needs. 

This channel is available for internally generated, externally generated, and supplier-specific messages.

I will discuss what I mean by the expression: “the first STS-1 of an STS-N” in another blog post. 

The S1 – Synchronization Status Byte

Figure 8 presents the location of the S1 Byte within the LOH.

The Line Overhead Bytes within an STS-1 signal with the S1 Byte Highlighted

Figure 8, Illustration of the LOH with the S1 Byte Highlighted

We use this byte to transport the Synchronization Status Message (SSM). 

I will discuss how we use the S1 byte in another blog post.

The M0 Byte – STS REI-L (Remote Error Indicator – Line)

Figure 9 presents the location of the M0 Byte within the LOH.

The Line Overhead Bytes within an STS-1 signal with the M0 Byte Highlighted

Figure 9, Location of the M0 Byte within the LOH.

The purpose of the M0 byte is to transmit the REI-L (Line – Remote Error Indicator) to a remote LTE. 

REI-L conveys the error count detected by the LTE (within the B2 byte) back to its peer LTE.

We will discuss the REI-L indicator and how we use it in another blog post. 

E2 Byte – Undefined

Figure 10 presents the location of the E2 byte within the LOH.

The Line Overhead Bytes within an STS-1 signal with the E2 Byte Highlighted

Figure 10, Location of the E2 Byte within the LOH.

What is the Role/Function of the Section Overhead (SOH) Bytes?

This blog post briefly defines the Section Overhead bytes within the SONET Frame.

The Section Layer and the Section Overhead (SOH) Bytes

The Section Layer involves transporting an STS-N data stream across the physical medium (e.g., copper or optical fiber) in a point-to-point manner (e.g., between any two adjacent pieces of equipment). 

The purpose of the Section Layer is to ensure that the STS-N data stream, which is being transported over a given link or coaxial cable or optical fiber, is properly received. 

Functions within this layer include:

  • Framing
  • Scrambling
  • Error detection
  • Section-Level Communications Overhead, such as the local orderwire.
  • Data Communication Channels (DCC) to carry information for OAM & P (Operation, Administration, Maintenance, and Performance). 

The Section Terminating Equipment (STE)

We refer to any piece of equipment that manages the transmission and reception of STS-N data over a single link of optical fiber or coaxial cable as an STE (Section Terminating Equipment).

An STE will manage the transmission and reception of STS-N data via the Section Overhead (SOH) bytes. 

The Section Overhead (SOH) Bytes

The SOH bytes reside in (and are a subset of) what we refer to as the “Transport Overhead” (TOH) bytes. 

Figure 1 illustrates the SONET Frame, with the SOH and LOH bytes field identified.

STS-1 Frame with the SOH (Section Overhead) and the LOH (Line Overhead) Shown

Figure 1, Another Look at the SONET Frame – SOH and LOH Bytes Highlighted.

I show and identify the Section Overhead (SOH) bytes in Figure 2 below.

Illustration of the SOH (Section Overhead) Bytes

Figure 2, Illustration and Identification of the Section Overhead Bytes

I will briefly describe the SOH bytes below.

The A1 and A2 (Framing Alignment) Bytes

In Figure 3, I show the location of the A1 and A2 bytes within the SOH. 

The STS-1 Section Overhead (SOH) Bytes within the A1 and A2 bytes highlighted

Figure 3, Location of the A1 and A2 Bytes within the Section Overhead

The A1 and A2 bytes are the Framing Alignment bytes.

These two bytes are assigned the following values:

  • A1 = 0xF6, and
  • A2 = 0x28

NOTE:  These values are the same as the FA1 and FA2 bytes within the OTU frame

A given STS-1 Transmitter will always set the A1 and A2 bytes to these specific values. 

The STS-1 Receiver (receiving this STS-1 signal) will search for and locate the “A1” and “A2” bytes to acquire and maintain STS-1 Frame Synchronization within this incoming STS-1 data stream.

A given STS-1 (receiving an STS-1 signal) will declare either of the following defect conditions based on its success in receiving the A1 and A2 bytes.

  • dSEF – Severely Erred Frame
  • dLOF – Loss of Frame

The STE will declare/clear the SEF and LOF Defect by using the “SEF/LOF Defect Declaration/Clearance – State Machine” diagram, which I show in Figure 4.

The SONET STS-1 Frame Acquisition State Machine Diagram.

Figure 4, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram

NOTE: We discuss the SEF/LOF Declaration/Clearance State Machine Diagram (and how the STE declares the dSEF or dLOF defect) in another blog post.

The C1 (STS-1 ID)/J0 (Section Trace Message) Byte

In Figure 5, I show the location of the C1 within the SOH. 

The SONET STS-1 Section Overhead (SOH) Bytes with the C1/J0 Bytes Highlighted.

Figure 5, Location of the C1/J0 Byte, within the Section Overhead

This Byte-Field serves two possible roles:

The C1 Byte (STS-1 ID)

In earlier editions of GR-253-CORE, the C1 byte was allocated to function as an “STS-1 ID” function. 

The C1 byte is no longer used for this purpose.

However, to ensure interoperability with older SONET equipment, this byte must be capable of transmitting and receiving the “STS-1 ID” number.

The J0 Byte – Section Trace Byte

The STE uses this byte to repetitively transmit a 1, 16, or 64-byte message so that the receiving STE can verify its continued connection to the intended transmitting sTS-1 STE. 

NOTE:  This is similar to the Trail Trace Identifier fields within the OTU and ODU frames. 

The B1 (Section BIP-8) Byte

In Figure 6, I present the location of the B1 byte within the STS-1 SOH.

The SONET STS-1 Section Overhead Bytes with the B1 Byte Highlighted

Figure 6, Location of the B1 Byte within the STS-1 SOH.

The Role of the Transmit STS-1 Terminal

A Transmitting STS-1 Terminal will computer the contents of the B1 byte by performing a BIP-8 calculation over all bits within a given “outbound” STS-1 frame (after scrambling). 

This byte value is inserted into the B1 Byte field (within the very next outbound STS-1 frame) before scrambling (of the current STS-1 frame).

The Role of the Receive STS-1 Terminal

  • As a Receiving STS-1 Terminal receives this STS-1 signal, it will compute its own BIP-8 value. 
  • Afterward, the Receive STS-1 Terminal will compare its “locally” computed BIP-8 value with the value residing within the B1 byte field of the next STS-1 frame.
  • If the two values are the same, then the Receive STS-1 Terminal will “conclude” that it has received this STS-1 signal in an un-erred manner.
  • If the two values are different, then the Receive STS-1 Terminal will “conclude” that it received this STS-1 signal in an erred manner. 
  • We will discuss how SONET STEs should check for and flag the occurrence of B1 byte errors in a future blog post.

NOTE:  The B1 byte (in SONET) is analogous to the Section BIP within an OTU Frame. 

The E1 (Orderwire) Byte

Figure 7 presents the location of the E1 byte within the STS-1 SOH.

The SONET STS-1 Section Overhead (SOH) with the E1 Byte Highlighted.

Figure 7, Location of the E1 Byte within the STS-1 SOH.

We refer to this byte as the Section Order-Wire Byte. 

The Standard Committee allocated this byte for use as a local order wire channel for voice communication between regenerators, hubs, and remote terminal locations.

The F1 (Section User Channel) Byte

Figure 8 presents the location of the F1 byte within the STS-1 SOH.

The SONET STS-1 Section Overhead (SOH) with the F1 Byte Highlighted.

Figure 8, Location of the F1 Byte within the STS-1 SOH.

The Standard Committee set aside the F1 byte for the user’s purposes. 

This byte is passed from STE to STE over the STS-N transmission media. 

This byte can typically be written into/read from at any STE.

Use of this byte is optional.

The D1, D2 and D3 (Section Layer – Data Communication Channel) Bytes

Figure 9 presents the location of the Section Layer Data Communication Channel (DCC) bytes within the STS-1 SOH.

The SONET STS-1 Frame with the Section Data Communication Channels (D1, D2, D3 Bytes) Highlighted.

Figure 9, Location of the Section Layer DCC Bytes within the STS-1 SOH.

These three bytes form a 192kbps message channel that supports transmitting OAM & P (Operation, Administration, Maintenance, and Provisioning) messages between pieces of Section Terminating Equipment.

ANSI.105.04 defines the protocols that we use in the Section Layer DCC.

Examples of STE (Section Terminating Equipment

Regenerators

Defects that occur within the Section Layer

  • dLOS – Loss of Signal
  • dSEF – Severely Erred Frame
  • dLOF – Loss of Frame

I briefly define and describe the Line Overhead Bytes (within a SONET Signal) in another blog post.

I also describe the Envelope Capacity and Synchronous Payload Envelope (SPE) in yet another blog post.

What is the SONET Reference Model?

This blog post defines the SONET Reference Model. It also describes some of the equipment that would support each of the Layers within the SONET Reference Model.

The SONET Reference Model

In the OSI (Open System International) Reference Model, we attempted to describe and understand a communications network via a seven (7) layer model.  This model consists of the following layers.

  • The Application Layer
  • The Presentation Layer
  • The Session Layer
  • The Transport Layer
  • The Network Layer
  • The Data Link Layer
  • The Physical Layer

In SONET, we attempt to describe and understand communication networks via a four (4) layer model (which we call the SONET Reference Model). 

In order of decreasing complexity, we have the following layers.

We will briefly describe each of these layers below.

In Figure 1, I show a drawing with some pieces of Optical Transmission Equipment.  I also show where each of these four SONET Layers fit in between these pieces of equipment.

SONET Reference Model - Section, Line and Path Layers

Figure 1, Illustration of the SONET Layers and Some Optical Equipment

We will now briefly describe some of these layers.

The Physical Layer

In SONET, the Physical Layer deals with the transport of bits across the transmission medium. 

There are no overhead bytes associated with the Physical Layer.

The main function of this layer is in the conversion between an STS-N digital data stream and either external optical or electrical SONET signals. 

Design issues associated with this layer typically include the following parameters:

  • Pulse Shape
  • Power Levels
  • Line Code
  • Timing
  • Connectivity

NOTE:  Optical Modules communicate at this layer.

The Section Layer

The Section Layer involves transporting an STS-N data stream across the physical medium (e.g., copper or optical fiber) in a point-to-point manner (e.g., between any two adjacent pieces of equipment). 

This layer aims to ensure that the STS-N data stream, transported over a given link, coaxial cable, or optical fiber, is properly received. 

Figure 2 presents a simple illustration of a Section.

Illustration of the Section and STE

Figure 2, Simple Illustration of a Section (a link between any two adjacent pieces of Equipment)

Functions within this layer include:

  • Framing
  • Scrambling
  • Error detection
  • Section-Level Communications Overhead, such as the local orderwire.
  • Data Communication Channels (DCC) to carry information for OAM & P (Operation, Administration, Maintenance, and Performance). 

What is Section Terminating Equipment (STE)

We refer to any piece of equipment that manages the transmission and reception of STS-N data over a single link of optical fiber or coaxial cable as an STE (Section Terminating Equipment).

An STE will manage the transmission and reception of STS-N data via the Section Overhead (SOH) bytes

The SOH bytes reside in (and are a subset of) what we refer to as the “Transport Overhead” (TOH) bytes. 

Figure 3 presents another look at the SONET Frame, with the TOH bytes field identified.

STS-1 Frame with the TOH (Transport Overhead) Shown

Figure 3, Another Look at the SONET Frame – TOH Bytes Highlighted.

I show (once again) that the TOH can be further divided into the SOH (Section Overhead) and Line Overhead (LOH) in Figure 4 below.

STS-1 Frame with the SOH (Section Overhead) and the LOH (Line Overhead) Shown

Figure 4 illustration the TOH being further divided into the SOH and LOH.

More about the SOH (Section Overhead Bytes)

As I mentioned earlier, we use the SOH (Section Overhead Bytes) to manage the transport of an STS-N signal across a Section.

Figure 5 presents a simple illustration of the 9 SOH bytes

Illustration of the SOH (Section Overhead) Bytes

Figure 5, Illustration of the Nine (9) SOH bytes

We discuss the function/role of the SOH bytes in another blog post.

The Line Layer

The Line Layer is the second highest layer within the SONET Reference Model.

The purpose of the Line Layer is to support the transmission of data between the Source and Sink Terminal of a given STS-N signal. 

The Line Layer is different from the Section Layer in that it (the Line Layer) will involve multiple pieces of electrical or optical transmission equipment. The Line Layer begins when we create a specific STS-N signal and ends when we terminate this STS-N signal.

The Section Layer only involves two adjacent pieces of electrical or optical transmission equipment.

Figure 6 presents an illustration of some STS-1 and STS-3 circuitry that helps to define the Line.

Illustration of a SONET Line. Also shows Sections, STEs and LTEs

Figure 6, Definition of an STS-N Line (or STS-3 Line)

In Figure 6, we define a “Line” as the circuitry and communication media from the point where we multiplex three STS-1 signals into an STS-3 to the point where we terminate the STS-3 signal and de-multiplex them back into the 3 STS-1 signals.

What is Line Terminating Equipment (LTE)

Any piece of equipment that manages the transmission and reception of an STS-N data-stream, from the point that we create this (STS-N) signal to the point where we terminate this (STS-N) signal.

An LTE will manage the transmission and reception of STS-N data via the Line Overhead (LOH) bytes.

The LOH bytes reside in (and are a subset of) what we often refer to as the “Transport Overhead” (TOH) bytes.

All LTEs are also STEs.

Therefore, all LTEs will manage the transmission and reception of STS-N data via both the “SOH” and “LOH” bytes. 

Figure 7 illustrates the LOH (Line Overhead) bytes within an STS-1 Frame.

Illustration of the LOH (Line Overhead) Bytes within an STS-1 Frame

Figure 7, Illustration of the LOH (Line Overhead) Bytes within an STS-1 Frame.

We discuss the function/role of the LOH (Line Overhead) bytes in another blog post.

The Path Layer

The purpose of the Path Layer is to support and manage the transport of “non-SONET” client data from the point where we map this client signal into the SONET network to the point where it exits (or is de-mapped) from the SONET network.

Examples of non-SONET data being mapped into and transported via a SONET Network are DS1, E1, DS3, ATM, Ethernet, etc.

Each STS-N SPE consists of nine (9) Path Overhead bytes.

Figure 8 illustrates the Location of the Path Layer within our drawing of Optical Equipment.

Identifcation of the Path Layer within our SONET Reference Model.

Figure 8, Location/Identification of the Path Layer, within our drawing of Optical Equipment

What is Path Terminating Equipment – PTE

Any piece of equipment that manages the transmission and reception of non-SONET data, or client signal, from the point that it enters the SONET network to the point that the SONET Network is terminated (and the client signal is de-mapped from the SONET signal) is referred to as a PTE (Path Terminating Equipment).

A PTE will manage the transmission and reception of non-SONET client data (through the SONET network) via the “Path Overhead” (POH) bytes.

The POH bytes reside within the first column in the SPE. 

Figure 9 illustrates the Synchronous Payload Envelope (SPE) with the Path Overhead (POH) Bytes.

Synchronous Payload Envelope (SPE) with the Path Overhead (POH) bytes

Figure 9, Illustration of the Synchronous Payload Envelope (SPE) with the Path Overhead (POH) Bytes.

NOTE:  All PTEs are also LTEs and STEs.

Therefore, all PTEs will manage the transmission and reception of STS-N data via both the “SOH,” “LOH,” and “POH” bytes.

I discuss the function/role of the Path Overhead (POH) bytes in another blog post.

Where is the Synchronous Payload Envelope?

In each of the figures above (e.g., Figures 3, 4, 5, and 7), I do not refer to the Synchronous Payload Envelope (SPE). I only refer to the Envelope Capacity (within the SONET Frame). I discuss the relationship between the Envelope Capacity and the SPE in another blog post.

What is SONET?

This blog post introduces the term SONET and briefly defines the Basic STS-1 frame in its most simplist of terms.

SONET is short for “Synchronous Optical NETwork.”

SONET is primarily a North American Standard.  The International (or the “Rest of the World”) version of SONET is called SDH, or Synchronous Digital Hierarchy.

SONET is an Optical Transport Standard that preceded OTN.  Just like OTN supports multiple data rates (e.g., OTU1, OTU2, etc.).  SONET supports a variety of rates, as I show below.

Table 1, List of Standard SONET and SDH Bit-Rates

SONET and SDH Bit Rate Table

Table 1 shows that the SONET/SDH Standards define bit rates up to almost 40Gbps.

This table also includes a column labeled STS-N Rates, where N can be integer numbers 1, 3, 12, 48, 192, and 768. We will talk a little bit about the STS-1 frame in this blog post. We will discuss STS-N frames and data rates in other blog posts.

What is the STS-1 Signal and Frame?

We will start this blog post by looking at the basic STS-1 Frame I show in Figure 1.

A Simple SONET STS-1 Frame with the Transport Overhead and Envelope Capacity shown

Figure 1, Illustration of the Basic STS-1 Frame (Simplified Drawing).

NOTE: STS stands for Synchronous Transport Signal.

The STS-1 frame consists of 9 rows and 90-byte columns (for a total of 810 bytes).

The frame repetition rate is 8000 frames/s.

Hence: 

90 bytes/row x 9 rows/frame x 8000 = 51.84Mbps (which matches the STS-1 data rate in Table 1).

Of these 810 bytes, we refer to 27 bytes as the Transport Overhead (TOH) bytes

We call the remaining 783 bytes the “Envelope Capacity.” 

NOTE: The Envelope Capacity (for an STS-1 frame) is large enough to carry the following:

  • 1 DS3 Signal
  • 28 DS1 Signals
  • 21 E1 Signals

Whenever we transport an STS-1 signal over a copper medium (such as a coaxial cable), we sometimes call this signal an EC-1 (Electrical Carrier – 1) signal. Likewise, whenever we transport an STS-1 signal over optical fiber, we can call it an OC-1 (Optical Carrier 1) signal

In other blog posts, we will show that we can further subdivide the TOH (Transport Overhead) within the STS-1 frame into the Section Overhead (SOH) and the Line Overhead (LOH).

Figure 2 shows that the basic STS-1 frame consists of 3 basic portions.

Basic Structure of a SONET STS-1 Frame with Section Overhead (SOH) and Line Overhead (LOH)

Figure 2, The SOH (Section Overhead), LOH (Line Overhead), and the Envelope Capacity within an STS-1 Frame.

In other blog posts, I will discuss the SOH, LOH, and Envelope Capacity in greater detail. 

I also present the SONET Reference Model in another blog post.

What is Ring Switching?

This post briefly describes and defined Ring-Switching within a Shared-Ring Protection-Switching system.


What is Ring-Switching within a Shared-Ring Protection-Switching System?

COMMENT:  Throughout this post, I will use the terms, Ring-Switching and Ring Protection-Switching interchangeably.

A Shared-Ring Protection-Switching system, whether a 2-Fibre/2-Lambda or a 4-Fibre/4-Lambda system, will support Ring Switching.

NOTE:  A 4-Fibre/4-Lambda Shared-Ring Protection-Switching system will also support Span Switching.  However, the 2-Fibre/2-Lambda Protection-Switching System does not support Span-Switching.

Ring-Switching is a Protection-Switching scheme that involves the entire Ring.

Example of Ring-Switching

Just like what I said in the Span-Switching post, the best way to describe Ring-Switching is to show an example of how it works.

Let’s suppose that we are using a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system.  I present an illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system below in Figure 1.

4-Fibre/4-Lambda Shared-Ring Protection-Switching System

Figure 1, Illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching

This 4-Fibre/4-Lambda Shared-Ring Protection-Switching system consists of four optical rings (or loops).

  • One Optical Loop is a Working Transport entity in which the data flows in the Clockwise direction.  (e.g., the Blue-Shaded Loop that I’ve labeled W(a)).
  • Another Optical Loop is a Protection Transport entity in which the data flows in the Clockwise Direction (e.g., the Pink-Shaded Loop, which I’ve labeled P(b)).
  • A 3rd Optical Loop is a Protection Transport entity in which the data flows in the Counter-Clockwise Direction.  (e.g., the Pink-Shaded Loop, that I’ve labeled P(a)).
  • And finally, the fourth Optical Loop is a Working Transport entity in which the data flows in the Counter-Clockwise Direction (e.g., the Blue-Shaded Loop, which I’ve labeled W(b)).

Now that we’ve introduced our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, let’s move on to Ring Protection-Switching.

Defects in the Fiber

Let’s assume that we are experiencing service-affecting defects within both of the Clockwise-Direction fibers (Working and Protection), between Nodes B and C, as I show below in Figure 2.

Defects in Both Working and Protection Transport Entity - Ring Protection Switching

Figure 2, Illustration of Service-Affecting Defects within both the Working and Protection Transport fibers that were carrying data from Node B to Node C

When this event occurs, Node C will declare the SF defect for the Working Transport entity (SF-W) and the Protection Transport entity (SF-P).  Anytime the Tail-End circuitry (within Node C) declares both the SF-W and the SF-P defect simultaneously, it will also declare the SF-R (Signal Fail-Ring) defect.

Whenever Node C declares the SF-R condition, it will respond to this event by issuing a Ring-Switching request between it and Node B.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!

Corporate Discounts Available!!!

Implementing Ring-Switching

Nodes B and C will exchange APS command information with each other through a protocol (that we call the Shared-Ring Protection-Switching system APS/PCC protocol).

Since the defects (within this example) affect both the Working and Protection Transport entities (in the Span, going from Nodes B and C), these nodes will have to communicate via both Short- and Long-Paths.

If Nodes B and C only respond and perform Ring Protection-Switching, directly in response to the SF-R defect condition (that Node C has declared), then we get the Ring Protection-Switching results we show below.

Ring-Switching in the Defect Direction

Figure 3, Illustration of Ring Protection-Switching Results (in the Defect Direction)

If you were to study Figure 3, you would see that Ring-Switching works by routing all of the traffic, such that the following is true.

  • That we are routing traffic away from the locations of the defects, and
  • We are still routing traffic through each of the nodes within the Ring.

However, we are not done yet.

ITU-T G.808.2 states that all protection-switching on a Shared-Ring Protection-Switching system must be bidirectional.   Therefore, we must also implement Ring Protection-Switching in the Opposite Direction.  I show this “Opposite-Direction” Ring Protection-Switching below in Figure 4.

Ring-Switching in the Opposite Direction - Opposite from Defect-Direction

Figure 4, Opposite-Direction Ring Protection-Switching

If I were to combine the Ring Protection-Switching Paths of the Defect-Direction and the Opposite Direction into a single figure, I would get the drawing I present below in Figure 5.

Ring-Switching in Both Directions

Figure 5, Bidirectional Ring Protection-Switching

Can the User Implement Ring-Switching at other locations in the Shared-Ring Protection-Switching System?

In general, the answer is No.

In our example, Nodes B and C use the Protection-Transport entity resources within much of the Shared-Ring Protection-Switching system.  This fact makes supporting an additional Ring-Switching path very difficult.

That being said, there might be strange scenarios that one can dream up that (temporarily) create two separate ring protection loops.

Why can’t we use Span-Switching whenever we have defects within the Working and Protection Transport entity within a Span?

In the Span-Switching post, we considered a single defect occurring only in the Working-Transport entity (in the span going from Node B to Node C).  Consequently, Node C declared the SF-W (and, in turn) the SF-S (Signal Fail – Span) condition.

In this case, we could use Span-Switching, because we still had a Protection-Transport entity fiber (transmitting data in the same direction as the broken Working Transport entity fiber).  Therefore, we were able to by-pass the single defect by using Span-Switching.

In this post, we have defects in both the Working and Transport entity fibers (in the span going from Node B and Node C).  Since we now have a defect within the Protection-Transport entity, that path (of by-passing the defect in the Working Transport entity) is unavailable to us in this scenario.

Therefore, we have to use a different protection-switching approach.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You to Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...

What is Span-Switching?

This post defines and describes the term: Span-Switching


What is Span-Switching within a Shared-Ring Protection-Switching System?

A 4-Fibre/4-Lambda Shared-Ring Protection-Switching system will support the two types of Protection-Switching.

NOTE:  A 2-Fibre/2-Lambda Shared-Ring Protection-Switching system will NOT support Span-Switching.  It will only support Ring-Switching.

Span-Switching is a Protection-Switching scheme that only involves a single-Span.

Example of Span-Switching

The best way to describe Span-Switching is to show an example of how it works.

Let’s suppose that we are using a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system.  Additionally, I will focus on the Span between Nodes B and C in this case.

Therefore, in Figure 1, I highlight a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system with the span between Nodes B and C.

Span between Nodes B and C

Figure 1, Illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, with the span (between Nodes B and C) highlighted.

If you look closely at the span between Nodes B and C, you will notice that this span contains the following four optical signals.

  • The Clockwise Optical Signal – Working Transport entity (the blue-shaded fiber – with the signal passing through it in the clockwise direction),
  • The Clockwise Optical Signal – Protection Transport entity (the pink-shaded fiber – with the signal moving through it in the clockwise direction),
  • The Counter-Clockwise Optical Signal – Working Transport entity (the blue-shaded fiber – with the signal passing through it in the counter-clockwise direction),
  • The Counter-Clockwise Optical Signal – Protection Transport entity (the pink shaded fiber – with the signal passing through it in the counter-clockwise direction).

Now that we’ve introduced our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, let’s see some protection-switching.

A Defect in the Fiber

Let’s further assume that we are experiencing a service-affecting defect within the Clockwise-Direction Working Transport entity fiber, as I show below in Figure 2.

SF-S Defect in Span between Nodes B and C - Span Switching

Figure 2, Illustration of a Service-Affecting Defect within the Clockwise Direction Working Transport entity fiber (between Nodes B and C)

Whenever this service-affecting defect occurs (within the Span between Nodes B and C), Node C will declare the SF-S (Signal Fail – Span) defect condition.  Node C will respond to this SF-S defect condition by issuing a Span-Switching request between it and Node B.

Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!

Corporate Discounts Available!!!

Implementing Span-Switching

Nodes B and C will exchange information with each other via a communications protocol (that we called the Shared-Ring Protection-Switching system APS/PCC protocol).

After Nodes B and C have completed this exchange of information (via the APS/PCC protocol), each of these nodes will have executed some protection-switching, such that both Nodes will now be exchanging regular ODUk traffic via the Protection Transport entities (in both directions), rather than using the Defective Working Transport entity (in the Clockwise Direction).

I show the results of this Protection-Switching effort below in Figure 3.

Span-Switching between Nodes B and C

Figure 3, Illustration of Span-Switching, between Nodes B and C

Span-Switching works (in this scenario) because we can use the Protection-Transport entity fiber.  This Protection Transport entity fiber carries traffic in the same direction as the broken Working Transport entity (within the Span, going from Nodes B to C).

Therefore, we can use it to bypass the defect within the Working Transport entity fiber.

NOTE:  All Shared-Ring Protection-Switching will use a 1:1 Protection-Switching Architecture.

Why is this Span-Switching Bidirectional?

Question:

Our 4-Fibre/4-Lambda Shared-Ring Protection-Switching system experienced a single Service-Affecting Defect (within the Working Transport entity of the Clockwise Optical Loop).

Why did we perform Span-Switching in both directions (even for the Counter-Clockwise Optical Loops)?

Answer:

ITU-T G.808.2 states that all Shared-Ring Protection-Switching MUST be Bidirectional.

Therefore, if we are required to perform protection-switching in one direction (to avert a defect condition), we must also complete a similar protection switch in the opposite direction – to make it bidirectional.

Can the User Implement Span-Switching at other locations in the Shared-Ring Protection-Switching System?

In a word, Yes.

In our example, Nodes B and C only use the Protection-Transport entity resources between these two nodes.  We have not taken up any other Protection-Transport entity resources along any remaining spans within the ring.

Therefore, the user can have multiple instances of Span-Switching within a Single Ring.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...

What is a Span (for SRP)?

This post briefly defines and describes the term: Span within a Shared-Ring Protection-Switching system.


What is a Span within a Shared-Ring Protection-Switching System?

In short, a Span is the set of fiber-optic connections between two adjacent nodes within a Shared-Ring Protection-Switching system.

In another post, we defined a Shared-Ring Protection-Switching system as a protection-switching system that contains at least three (3) nodes.

We further stated that each node (within this Shared-Ring Protection-Switching system) is connected to two neighboring nodes.

A span is a set of fiber-optic media that exists between and connects any two neighboring nodes.

I illustrate a Shared-Ring Protection-Switching system, with the Span (between Nodes B and C) highlighted below in Figure 1.

Span between Nodes B and C

Figure 1, Illustration of a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, with the Span (between Nodes B and C) highlighted.  

What kind of Signals does a Span Transport?

In most Shared-Ring Protection-Switching systems, a span will consist of two or four fibers transporting the following optical signals.

  • Clockwise Direction – Working Transport Entity
  • Clockwise Direction – Protection Transport Entity
  • Counter-Clockwise Direction – Working Transport Entity
  • Counter-Clockwise Direction – Protection Transport Entity

Can a System-Designer implement any sort of Protection-Switching across a Span?

Yes, with a 4-Fibre/4-Lambda Shared-Ring Protection-Switching system, the user can implement Span-Switching as a form of Protection-Switching.

Please see the post on Span-Switching for more information on this topic.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You Become an Expert on OTN!! Click on the Banner Below to Learn More!!

Discounts Available for a Short Time!!

Click on the Image Below to see more Protection-Switching related content on this Blog:

Protection-Switching Related Blog

Protection-Switching Related Blog Posts

Protection-Switching Related Blog Posts Basic Protection-Switching Terms Head-End (Source Node) Hold-Off Timer Protection-Group Protection-Transport entity Selector Switch Tail-End (Sink Node) ...