Shared-Ring Protection Switching

This post briefly defines the term: Shared-Ring Protection-Switching


What is Shared-Ring Protection Switching?

A Shared-Ring Protection Switching system is a Protection System that contains at least three (3) Nodes.

Each Node within this Shared-Ring Protection-Switching System (or Ring) is connected to two neighboring nodes.

I show an illustration of a Shared-Ring Protection-Switching System below in Figure 1.

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

Figure 1, Illustration of a Shared-Ring Protection-Switching System

Figure 1 presents a shared-ring protection-switching system that consists of six (6) nodes that are each connected to a shared ring that contains four (4) Optical loops (or rings).

Some optical rings carry traffic that flows in the clockwise direction (through each node).  Other rings carry traffic that flows in the counter-clockwise direction.

In Figure 1, I have labeled some of these optical loops as “Working” or Working Transport Entity loops and others as “Protect” or Protection Transport Entity loops.

What are the Nodes within a Shared-Ring Protection-Switching System?

Each node (on the Shared-Ring Protection-Switching system) is an electrical/optical system that functions similarly to an Add-Drop-MUX.

Some data traveling on an optical loop (within the ring) will pass through these nodes.  These Nodes also can add in and drop-out some of the data traveling on these loops.

I show the Add-, Drop- and Pass-Through capability of these Nodes below in Figure 2.

Add-Drop MUX features of Nodes in Shared-Ring Protection-Switching

Figure 2, Illustration of the Add-, Drop- and Pass-Through capabilities of a given node, sitting on the shared-ring.  

It is also important to note that each Node can function as either a Source (or Head-End) Node, a Sink (or Tail-End) Node, or both.

Types of Shared-Ring Protection-Switching Systems

ITU-T G.873.2 defines the following two types of Shared-Ring Protection-Switching systems.

  • The 2-Fibre/2-Lambda Shared-Ring Protection-Switching system, and
  • The 4-Fibre/4-Lambda Shared-Ring Protection-Switching system.

Please click on the links above to learn more about these Shared-Ring Protection-Switching systems.

Types of Protection-Switching within a Shared-Ring Protection-Switching System

The Shared-Ring Protection-Switching system can support both the following kinds of Protection-Switching.

Click on the above links to learn more about these types of Protection-Switching within a Shared-Ring Protection-Switching system.

Design Variations for Shared-Ring Protection-Switching Systems

Shared-Ring Protection-Switching systems are available in a wide variety of features.  I’ve listed some of these features and their possible variations below.

Shared-Ring Protection-Switching Types

  • 2-Fibre/2-Lambda Shared-Ring Protection-Switching systems
  • 4-Fibre/4-Lambda Shared-Ring Protection-Switching systems.

Architecture Type

All Shared-Ring Protection-Switching is of the 1:N Protection-Switching Architecture.

Switching Type

All Shared-Ring Protection-Switching is Bidirectional.

Operation Type

All Shared-Ring Protection-Switching systems use Revertive Operation.

APS Protocol – Using the APS/PCC Channel

All Shared-Ring Protection-Switching systems use the APS Protocol.

What about other types of Protection-Switching?

Other types of Protection-Switching Systems are not Shared-Ring, such as Linear or Shared-Mesh Protection-Switching.

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

Discounts Available for a Short Time!!!

Please Click on the Image below to See More Protection-Switching posts within this Blog.

OTN Related Blog

OTN Related Topics within this Blog

OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...

What is 1+1 Protection Switching (APS)

This post defines and describes the term 1+1 Protection Switching.


What is 1+1 Protection Switching?

ITU-T G.808 Defines 1+1 (Protection) Architecture as:
A 1+1 protection architecture has one normal traffic signal, one working transport entity, one protection transport entity, and a permanent bridge.
At the source end, the normal traffic signal is permanently bridged to both the working and the protection transport entities.  

At the sink end, the normal traffic signal is selected from the better of the two transport entities.

Due to the permanent bridging, the 1+1 (protection) architecture does not allow an unprotected extra traffic signal to be provided.  

What Does All This Mean?

As for all Protection Groups, a 1+1 Protection Architecture consists of the following elements.

Figure 1 presents an illustration of a 1+1 Protection Switching Architecture.

1+1 Protection Switching Architecture - Normal Operation

Figure 1, Illustration of a 1+1 Protection Switching Architecture – Normal (No Defect) Condition

How to Know if You’re Working with a 1+1 Protection Architecture?

This figure shows that a Permanent Bridge realizes the Head-End (of this Protection Group) and that a Selector Switch realizes the Tail-end.  This is a crucial characteristic of the 1+1 Protection Architecture.  

As we defined earlier (from the excerpts of ITU-T G.808), the Permanent Bridge means that there is a hardwired connection between the Normal Traffic Signal and both the Working and Protection Transport entities at the Head-End circuitry.  This fact helps you to identify a 1+1 Protection Architecture quickly.  This is not the case for a 1:N Protection Architecture.  

You can see all of this in Figure 1.  

No-Defect Operation of the Normal Traffic Signal in a 1+1 Protection Architecture

The Normal Traffic Signal will travel through the Working Transport entity for normal conditions, as shown in Figure 1.

Although the Normal Traffic signal is bridged (or connected) to both the Working and Protect Transport entities, it only flows through the Working Transport entity because we connected the Selector switch to the Working Transport entity.

Whereas the Selector Switch leaves the connection between the Protection Transport entity and the Tail-End circuitry, OPEN.

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

Corporate Discounts Available!!!

A Service-Affecting Defect occurs.

Now, let us look and see what happens if “bad things” occur.

Figure 2 presents an illustration in which an impairment now exists within the Working Transport entity; this impairment causes the Protection Controller (not shown but sitting behind the Tail-end circuitry) to declare a Service-Affecting defect (e.g., SF) or SD.

1+1 Protection Switching Architecture - Defect Condition

Figure 2, Illustration of a Service-Affecting Defect within the Working Transport entity

In this case, the Normal Traffic signal can no longer travel through the Working Transport entity.

If our circuitry did not have any protection switching capability, then all the customers (and end-users) of the Normal Traffic Signal would lose their service.

This would be very bad, especially for the service provider and their financial future.

Protection Switching Occurs

Fortunately, this system does offer protection switching.

In this case, since the Protection Controller has detected and declared a service-affecting defect condition within the Working Transport entity signal, it will then switch the Selector such that it is now connected to the Protect Transport entity, as we show in Figure 3.

1+1 Protection Switching - Protection Switching Condition

Figure 3, Illustration of Normal Traffic signal flow – following Protection Switching

Once the Selector switches over and connects to the Protection Transport entity, the Normal Traffic signal will flow through the Protection Transport entity.

This is an excellent thing for all parties involved.

The users (of the Normal Traffic signal) will get their data or have their service still available.  And the service provider will have fewer irate customers and nasty phone calls.

Other Considerations for 1+1 Protection Switching

The 1+1 Protection Switching Architecture is quite simple.

We usually implement the head-end with a Permanent Bridge and realize the tail-end with a Selector switch.

However, there are some variations that we need to consider for the 1+1 Protection Switching architecture.

Unidirectional or Bidirectional Switching

The user can design their 1+1 Protection Switching architecture to be either a Unidirectional or Bidirectional type.

Please see the Unidirectional and Bidirectional Protection Switching posts for more details on these terms.

NOTE:  If you intend to use Bidirectional Protection Switching, then you will need to use some form of APS communication link/protocol to coordinate the switching of both ends of the protection group.

Protection Ratio:

The protection ratio for a 1+1 Protection Switching system is not very good.  This situation is not good because the user must design twice (2X) the bandwidth of the Normal Traffic signal.

We have to allocate 1X of the bandwidth for the Working Transport entity and 1X for the Protection Transport entity.

To Revert or Not-Revert

If a Protection Switching architecture supports “revert” (or reverting), then this means that the Selector switch will automatically switch back to the Working Transport entity once the service-affecting defect (which caused the switching event) has cleared.

Please see the post on revert for more details about this option.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Help You Become an Expert on OTN and Protection-Switching!! 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 the Tail-End for Protection Switching?

This post defines and describes the term Tail-End for (APS) Automatic Protection Switching applications.


What is the Tail-End within an APS (Automatic Protection Switching) System?

ITU-T G.808 Defines the Tail-End as:

The tail-end of a protection group is the end where the selector process is located.  In the case where traffic is protected in both directions of transmission, the tail-end process is present at every end of the protection group.

NOTE:  Whenever people discuss the tail-end of an APS system, they will sometimes use the term sink node.

ITU-T G.808 Defines the Sink Node (within a Protection Group) as:

The node at the egress of a protected domain, where a normal traffic signal may be selected from either the working transport entity or the protection transport entity.

So What Does All This Mean?

In Figure 1, we present an illustration of a Protection Group.

If we were to look closely at the Normal Traffic Signal (in Figure 1), we would see that the Tail-End is the last component that the Normal Traffic signal passes through as it exits the Protection Group.

Protection Group - 1:N

Figure 1, Illustration of a Protection Group

The Tail-End (or Sink Node) circuitry is responsible for declaring and clearing defects and asserting (or de-asserting) the SF (Signal Fail) and SD (Signal Degrade) indicators.

The Sink Node (or Tail-End) will use these SF and SD indicators to select either the Working or Protect Transport entity as its source for the Normal Traffic Signal.

Figure 2 illustrates a simplified schematic within the Tail-End Circuitry (including the Protection-Switching Controller).  

Tail End Circuitry - Protection-Switching Controller for a 1+1 Protection Architecture

Figure 2, Illustration of the Tail-End Circuitry

Additionally, Figure 2 shows that the Tail-End Circuitry contains circuitry that detects and declares defect conditions and asserts the SF or SD indicators.   This circuitry also includes the Protection-Switching Controller.  I will describe how this circuitry works in another post.  

Another post discusses the SF (Signal Fail) and SD (Signal Degrade) indicators.

As I show in Figure 2, the Tail-End will often use a Selector Switch that connects to the Working or Protection Transport entity.

If the Selector Switch is connected to the Working Transport entity, then the Tail-End circuitry will be using it (the Working Transport entity) as its source of the Normal Traffic signal.

The Normal Traffic signal will then propagate through the Tail-End circuitry as it exits the Protection Group.

But, if the Selector (Switch) is connected to the Protect Transport entity, then the Tail-End circuitry will be using the Protect Transport entity as its source of the Normal Traffic signal.

USING THE SELECTOR IN A 1+1 AND 1:N PROTECTION SWITCHING ARCHITECTURE

Figures 3 and 4 show drawings of the Protection Group using a Selector (Switch) in a 1+1 and 1:2 Protection Switching scheme, respectively

Selector in a 1+1 Protection Switching System

Figure 3, Illustration of a Selector within a 1+1 Protection Switching Scheme

Selector in a 1:2 Protection Switching System

Figure 4, Illustration of a Selector within a 1:2 (1:N) Protection Switching Scheme

In the case of the 1+1 Protection Switching scheme, the Working and Protect Transport entities always carry the Normal Traffic Signal.

However, the Protection Switching controller function within the Tail-End circuitry (not shown in Figure 3) will determine whether to select the Normal Traffic signal from the Working or the Protect Transport entity.

Suppose the Protection Switching controller function was to declare (for example) the SF (Signal Fail) or SD (Signal Degrade) defect condition within the Normal Traffic signal passing through the Working Transport entity.  In that case, it will command the Selector Switch to switch over and connect to the Protect Transport entity.

Whenever the Selector Switch switches from the Working to the Protect Transport entities, we call this action protection switching.

Some Protection Groups support a revert feature, where the Selector Switch automatically switches back to connecting to the Working Transport entity after the SF or SD defect has cleared.

Other Protection Groups are non-reverting systems and do not support this feature.

In other blog posts, we discuss the Protection Switching controller function and the revert operation.

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

Corporate Discounts Available!!!

THE NEED FOR COMMUNICATION BETWEEN THE TAIL-END AND HEAD-END COMPONENTS OF A PROTECTION GROUP

The Selector Switch will connect to either the Working or Protect Transport entity, depending upon whether the Protection Switching controller circuitry declares the SF or SD defect within the Normal Traffic signal traveling through these transport entities.

The circuitry that detects and declares these defects (and commands the Selector to switch) resides on the Tail-End side of the Working/Protect Transport entities.

Therefore, in many Protection Switching architectures (e.g., 1:1, 1:n, and Bidirectional 1+1), the Tail-End will need to communicate and coordinate its protection-switching actions with the Head-End circuitry (within the Protection Group) via a communication link.

We discuss this APS communication link (or protocol) in another blog post.

Summary

The Tail-End (called the Sink Node) is usually the last component that a Normal Traffic Signal will pass through as it leaves the Protection Group.

The Tail-End (or Sink Node) contains circuitry that will determine if it should declare any service-affecting defects with the Working and Protect Transport entities and assert the SF (Signal Fail) signal as appropriate.

This Tail-End circuitry will also check the Working and Protect Transport entities for excessive errors (within the OTUk/ODUk signal) and assert the appropriate SD (Signal Degrade) signal.

The Sink Node (or Tail-End) circuitry will use these SF and SD signals to decide whether the Selector Switch should select the Normal Traffic Signal from the Working or the Protect Transport entities.

For normal (no defect) conditions, the Selector Switch will connect to and accept the Normal Traffic Signal from the Working Transport entity.

In this case, the Normal Traffic signal will travel from the Working Transport entity to and through the Tail-end circuitry as it leaves the Protection Group.

However, suppose the Protection-Switching controller determines that the Normal Traffic signal, when passing through the Working Transport entity, contains service-affecting defects, such as SF or SD.  In that case, it will command the Selector Switch to switch over and connect to the Protect Transport entity.

In this case, the Selector will now obtain the Normal Traffic signal from the Protect Transport entity (instead of the Working Transport entity).

Whenever the Selector switches from the Working to the Protect Transport entity, we call this action Protection Switching.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and Become an Expert on OTN and Protection-Switching!! 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 the Head-End for Protection Switching?

This post defines and describes the term head-end for APS (Automatic Protection Switching) applications.


What is the Head-End, within an APS (Automatic Protection Switching) System?

ITU-T G.808 Defines the Head-end as:

The head-end of a protection group is the end where the bridge process is located.  If traffic is protected in both directions of transmission, the head-end process is present at every end of the protection group.  

NOTE:  Whenever people discuss the head-end of an APS system, they sometimes use the alternative term source-node.

ITU-T G.808 Defines the Source-Node as:

The node at the Ingress to a protected domain, where a normal traffic signal may be bridged to the protection transport entity.  

So What Does All This Mean?

In Figure 1, we show a drawing of a Protection Group.

If we were to look closely at the Normal Traffic Signal (within Figure 1), we would see that the Head-end is the first component that the Normal Traffic Signal passes through as it enters the Protection Group.

Protection Group - 1:N

Figure 1, Illustration of a Protection Group

The Head-end (or Source Node) is responsible for connecting the Normal and Extra Traffic Signals to the Working and Protect Transport entities, as appropriate for APS applications.

The Head-end will typically use a Bridge to connect the Normal Traffic signals and the Extra Traffic Signal (if available) to the Working and/or Protect Transport entities.

Automatic Protection Switching typically uses one of two types of Bridges.

  • The Permanent Bridge and
  • The Broadcast Bridge

We will discuss each of these bridges below.

The Permanent Bridge – (for the 1+1 Protection Switching Architecture)

If you use the 1+1 Protection Switching Architecture, you will typically use the Permanent Bridge.

The Permanent Bridge (as its name implies) permanently bridges (e.g., connects) the Normal Traffic Signal to both the Working and Protect Transport Entities.

Figure 2 presents an illustration of a Permanent Bridge.

Permanent Bridge

Figure 2, Illustration of a Permanent Bridge

This means that, for the 1+1 Protection Switching Architecture, the Working and Protect Transport entities always carry the Normal Traffic Signal.

In this case, the Bridge also acts as a “splitter” that transmits the Normal Traffic signal via the Working Transport entity and a replica of the Normal Traffic signal via the Protect Transport entity.

Figure 3 shows a drawing of a Protection Group that uses the 1+1 Protection Switching Architecture.

Protection Group - 1+1

Figure 3, Illustration of a Protection Group that uses the 1+1 Protection Switching Architecture

The Broadcast Bridge – (for the 1:1 and 1:n Protection Switching Architecture)

If you are using the 1:1 or 1:n Protection Switching Architecture, you will typically use the Broadcast Bridge.

For the one or n Working Transport entities (for the 1:1 or 1:n protection switching architectures, respectively), the Broadcast Bridge will permanently connect the Normal Traffic Signal to the Working Transport entity.

The Broadcast Bridge will (upon protection-switching controller command or configuration) also connect its corresponding Normal Traffic signal to the Protect Transport Entity.

We discuss the protection-switching controller in another blog post.

The 1:1 or 1:n Protection Switching Architecture may also include an Extra Traffic signal, which travels through the Protect Transport entity whenever none of the Working Transport entities declare service-affecting or signal degrade defect conditions.

Below, Figure 4 presents an illustration of the Broadcast Bridge.

Broadcast Bridge

Figure 4, Illustration of a Broadcast Bridge (for 1:1 and 1:n Protection Switching schemes)

Additionally, Figure 5 presents an illustration of a Protection Group that uses the 1:2 Protection Switching Architecture and (thus) uses Broadcast Bridges within its Head-End circuitry.

1:2 Protection Switching System

Figure 5, Illustration of a Protection Group that uses the 1:2 Protection Switching Architecture

Summary

The Head-End (called the “Source Node”) is usually the first component that a Normal Traffic Signal will pass through as it enters a Protection Group.

The Head-End (or Source Node) performs a Bridging Function between the Normal Traffic Signal and the Working and Protect Transport Entities.

We use two basic types of bridging functions in Protection Switching applications.

The Permanent Bridge permanently connects the Normal Traffic signal to the Working and Protect Transport entities.

A Broadcast Bridge permanently connects the Normal Traffic signal to the Working Transport entities.

Finally, the Broadcast Bridge will (upon user command or configuration) also connect the corresponding Normal Traffic signal to the Protect Transport entity.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and 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 Protection Group (APS)

This post defines the term Protection Group, for Automatic Protection Switching (APS) purposes.


What is a Protection Group for APS (Automatic Protection Switching) Purposes?

ITU-T G.808 Defines the Protection Group as:  

The collection of head-end and tail-end functions, 1 to n normal traffic signals, optionally an extra traffic signal, 1 to n working transport entities, and a single protection transport entity used to provide extra reliability for the transport of normal traffic signals.

What does all that mean?

The Protection Group comprises components and connections that work together to enhance the reliability of a transmission/network system for a Normal Traffic Signal by implementing Automatic Protection Switching.

Further, the Protection Group for a transmission/networking system consists of all the following items/entities.

The Protection Group enhances the reliability and protects 1 to N numbers of Normal Traffic Signals.

The Protection Group can either support Unidirectional or Bidirectional protection switching.

Figure 1 presents the Illustration of a 1+1 Protection scheme that I have modified to show the various elements within a Protection Group.

Protection Group - 1+1

Figure 1, Illustration of a 1+1 Protection Scheme that also identifies the Protection Group.

Likewise, Figure 2 illustrates a 1:2 Protection scheme that I have modified to show the various elements within the Protection Group.

Protection Group - 1:N

Figure 2, Illustration of a 1:2 Protection Scheme that also identifies the Protection Group.

In both cases, Figures 1 and 2 show numerous components within a shaded box.

All the items within the shaded box (in each figure) make up the Protection Group.

I discuss the individual components that make up the Protection Group in other posts within this post.

In Summary:

A Protection Group is a system that consists of the following items/entities:

Each of these components works together, using Automatic Protection Switching to enhance the transport path’s reliability for a given Normal Traffic Signal.

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 the Normal Traffic Signal (APS)

This post presents the definition for the term, Normal Traffic Signal, for APS (Automatic Protection Switching) applications.


What is the Normal Traffic Signal for APS (Automatic Protection Switching) Purposes?

ITU-T G.808 Defines the Normal Traffic Signal as:  
A traffic signal that is protected by two alternative transport entities called working and protection transport entities.  

What does all that mean?

In many applications, some traffic signals are critical to the Networking Service provider (and their financial bottom-line) and the end customers themselves.

Hence, these signals warrant a certain amount of protection in the form of some system redundancy.

In the APS (Automatic Protection Switching) World, we call this critical traffic signal the Normal Traffic Signal.

I recognize the apparent silliness in calling a critical traffic signal worthy of system-level protection a mundane name, such as the Normal Traffic Signal.

But that is the language used by the Standards Committee and the Industry (as a whole).

So who are we to buck the trend?

A Normal Traffic Signal becomes protected (in a system design) whenever the signal path between two Network Elements (that reside at the opposite ends of this particular protection group) provides both a Working and Protection Transport Entity (path) for that Normal Traffic Signal.

Figure 1 illustrates two Network Elements that form a protection group and are connected.

In this figure, we have connected these two Network Elements through two separate paths.

We will call one of these paths the Working Transport Entity and the other path the Protect Transport Entity.

Normal Traffic Signal - No Defect Case

Figure 1, Illustration of Two Adjacent Network Elements connected via a Protection Group (e.g., the Working and Protection Transport Entity).

So How Does All of This Work?

In most network system designs, the Network Elements will (by default) transmit the Normal Traffic Signal over the Working Transport Entity.

This Normal Traffic signal can be of any type (e.g., SONET/SDH, OTN, Ethernet, etc.).

Now, let’s suppose that some impairment were to occur within the traffic signal (that is, traveling from Network Element West to Network Element East).

The Network Element East will likely respond to this event by detecting and declaring a service-affecting or signal degrade defect with this traffic signal (e.g., SD, SF, etc.).

The overall system (consisting of both Network Element West and Network Element East) will respond to this event by redirecting the Normal Traffic Signal through the Protect Transport Entity instead of the (now defective) Working Transport Entity, as we show in Figure 2.

In other words, if the Working Transport entity (path) fails, then we can (and will) use the Protect Transport entity (path) as a Backup.

Normal Traffic Signal - Defect Condition

Figure 2, Illustration of Network Element East declaring a defect (with the traffic it receives from Network Element West) and (in response) invoking Protection Switching.

NOTE:  Figure 2 shows the two Network Elements invoking Bidirectional Protection Switching in response to Network Element East declaring a service-affecting defect condition.

The Network Elements could have also responded to this defect condition by using Unidirectional Protection Switching instead.

Please see Unidirectional and Bidirectional Protection Switching posts to learn more about these protection switching schemes/options.

In Summary

A Normal Traffic Signal is a protected signal.  It is an important signal that we will bear some expense to ensure that it gets from Point A to Point B, even with service-affecting or signal degrade defect conditions in the network.  

This means that as a given Network Element (at one end of a protection group) transmits the Normal Traffic signal to the other Network Element (at the other end of the protection group), it can do so by sending this Normal Traffic signal over one of two possible signal paths:

  • The Working Transport entity, and
  • The Protect Transport entity.

The Network Element will (by default) transmit the Normal Traffic signal over the Working Transport entity.

However, suppose the Network detects and declares a service-affecting or signal degrade defect within this Working Transport entity.  In that case, the Network System will redirect the Normal Traffic Signal through the Protection Transport entity (e.g., the backup signal path) instead.

Has Inflation got You Down? Our Price Discounts Can Help You Beat Inflation and 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) ...

Bidirectional Protection Switching

This post defines the term Bidirectional Protection Switching for APS (Automatic Protection Switching) applications.


What is Bidirectional Protection Switching (and How is it Different from Unidirectional Protection Switching)?

The Definition of Bidirectional Protection Switching

ITU-T G.780 defines Bidirectional Protection Switching as follows:

A protection switching architecture in which, for a unidirectional failure (i.e., a failure affecting only one direction of transmission), both directions (of the “trail,” “subnetwork connection,” etc.), including the affected direction and the unaffected direction, are switched to protection.  

What does All That Mean?

I will explain all this through three (3) illustrations/cases.

  • The Normal/No Defect Case
  • The Defect/Bidirectional Protection Switching Case and
  • The Defect/Unidirectional Protection Switching Case

The Normal/No Defect Case

Figure 1 illustrates a “Normal” (e.g., No Defect) condition.

This illustration shows two network elements transmitting and receiving traffic to and from each other.

We will call one of these network elements Network Element West and the other network element Network Element East.

Normal Traffic/No Defect Condition - Protection Switching

Figure 1, Illustration of two Network Elements exchanging traffic during Normal/No-defect conditions.

Figure 1 also shows Protection Switching support for the traffic flow between these two Network Elements.

This figure shows a Bidirectional Working Transport Entity between these two Network Elements.

The figure also shows that there is a Bidirectional Protection Transport Entity between these two Network Elements, as well.

In this case, neither Network Element declares any defect within the Working Transport Entity, and Good/Normal Bi-directional traffic flows between these two Network Elements.

Finally, this figure also shows that all the traffic flows through the Working Transport Entities and that none of the traffic flows through the Protect Transport Entities.

Next, we will consider what happens whenever one Network Elements declares a service-affecting defect within the Working Transport Entity.

Bidirectional Protection Switching Case

Figure 2 presents an illustration of a Defect condition.

In this case, some impairment exists within the West-to-East Working Transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Bidirectional Protection Switching

Figure 2, Illustration of Bidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport connection (in the West-to-East direction), this protection switching scheme will route all West-to-East traffic through the Protect Transport Entity instead.

Yet, this protection scheme does not stop there.  It will also route all East-to-West traffic through the Protect Transport entity.

In other words, if we detect a defect within the Working Transport Entity (at all), we will route traffic for BOTH directions from the Working Transport entity to the Protect Transport entity.

We call this particular protection scheme Bidirectional Protection Switching because, in this case, we are performing protection switching in BOTH directions, even if we only declare a service-affecting defect in one direction.

NOTE:  Since we perform protection switching in BOTH directions (for bidirectional protection switching), this kind of protection scheme requires that the protection group uses an APS or PCC (Protection Communications Channel).

Both ends of the protection group will need to communicate and coordinate with each other during protection switching events.

We will clarify the difference between Bidirectional and Unidirectional Protection Switching by showing the Unidirectional Protection Switching Case.

Unidirectional Protection Switching Case

Figure 3 presents another illustration of a Defect condition.

In this case, there is (once again) some impairment that exists within the West-to-East Working transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Unidirectional Protection Switching

Figure 3, Illustration of Unidirectional Protection Switching – responds to a Service-Affecting Defect in one direction on traffic.

Since this defect exists within the Working Transport Entity, this protection scheme will route all West-to-East traffic through the Protect Transport entity.

Yet, in contrast to the Bidirectional Protection Switching scheme, it will continue to route all East-to-West traffic through the Working Transport entity; since there are no defects in that particular direction.

In other words, the Unidirectional Protection Switching scheme only routes the traffic directions (the Network Element has determined to be defective) through the Protect Transport Entity.

If it detects no defects within a given Working Transport entity (in the other direction), it will continue to route that traffic through the Working Transport entity.

We call this particular protection scheme Unidirectional Protection Switching because, in this case, we are performing protection switching in ONE direction if we only detect a service-affecting defect in ONE direction.

Please see the Unidirectional Protection Switching post for more detailed information on this protection switching scheme.

Summary

In summary, the main difference between Unidirectional and Bidirectional Protection switching is as follows.

For Bidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), the protection scheme will still switch BOTH directions of traffic from the Working to the Protect Transport entity.

In the case of Unidirectional Protection Switching, if the Network Elements declare a service-affect defect in ONLY one direction (of traffic), then the protection scheme will only switch the defective direction from the Working Transport entity to the Protect Transport entity.

The other (non-defective) direction of traffic will continue to use the Working Transport Entity.

Has Inflation got You Down? With Our Pricing Special, You Can Beat Inflation and 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) ...

Unidirectional Protection Switching

This post defines the term Unidirectional Protection Switching for APS (Automatic Protection Switching) applications.


What is Unidirectional Protection Switching (and How is it Different from Bidirectional Protection Switching)?

The Definition of Unidirectional Protection Switching

ITU-T G.780 defines Unidirectional Protection Switching as follows:

A protection switching architecture in which, for a unidirectional failure (i.e., a failure affecting only one direction of transmission), only the affected direction (of the “trail,” or “subnetwork connection,” etc.) is switched to protection.  

What does ALL that Mean?

I will explain all this through three illustrations/cases

  • The Normal/No Defect Case
  • The Defect/Unidirectional Protection Switching Case and
  • The Defect/Bidirectional Protection Switching Case

The Normal/No Defect Case

Figure 1 illustrates a “Normal” (e.g., No Defect) condition.

This illustration shows two network elements transmitting and receiving traffic to and from each other.

We will call one of these Network Elements Network Element West and the other Network Element Network Element East.

Normal Traffic/No Defect Condition - Protection Switching

Figure 1, Illustration of two Network Elements exchanging traffic during Normal/No-defect conditions.  

Figure 1 also shows Protection Switching support for the traffic flow between these two Network Elements.

This figure shows a Bidirectional Working Transport Entity between these two Network Elements.

The figure also shows that there is a Bidirectional Protect Transport Entity between these two Network Elements, as well.

In this case, neither Network Element declares any defect within the Working Transport Entity, and Good/Normal Bi-directional traffic flows between these two Network Elements.

Finally, this figure also shows that all the traffic flows through the Working Transport Entities and that none of the traffic flows through the Protect Transport Entities.

Next, we will consider what happens whenever one Network Elements declares a service-affecting defect within the Working Transport Entity.

Unidirectional Protection Switching Case

Figure 2 presents an illustration of a “Defect” condition.

In this case, some impairment exists within the West to East Working Transport entity, and Network Element East is declaring some service-affecting defect with this traffic signal.

Unidirectional Protection Switching

 

Figure 2, Illustration of Unidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport entity (in the West-to-East direction), this protection switching scheme will route all West-to-East traffic through the Protect Transport Entity instead.

Please note this protection switching event only applies to the traffic within the West-to-East Direction.

Since Network Element West is not declaring any defects within the East-to-West Working Transport Entity, the East-to-West traffic will continue to travel via the Working Transport Entity (even though the West-to-East traffic has been switched over to the Protect Transport Entity.

We call this particular protection scheme Unidirectional Protection Switching because, in this case, we only perform protection switching in the ONE direction that has the service-affecting defect.

We will clarify the difference between Unidirectional and Bidirectional Protection Switching by showing the Bidirectional Switching Case.

Bidirectional Protection Switching Case

Figure 3 presents another illustration of a Defect condition.

In this case, there is (once again) some impairment that exists within the West-to-East Working transport connection, and Network Element East is declaring some service-affecting defect with this traffic signal.

Bidirectional Protection Switching

Figure 3, Illustration of Bidirectional Protection Switching – in response to a Service-Affecting Defect in one direction of traffic

Since this defect exists within the Working Transport connection, this protection switching scheme will route all “West-to-East” traffic through the Protect Transport entity instead.

Yet, this protection switching scheme does not stop there.  It will also route all East-to-West traffic through the Protect Transport entity.

In other words, if we detect a defect within the Working Transport Entity (at all), we will route the traffic for BOTH Directions from the Working Transport entity to the Protect Transport entity.

We call this particular protection scheme Bidirectional Protection Switching because, in this case, we are performing protection switching in BOTH directions, even if we only detect a service-affecting defect in one direction.

Please see the Bidirectional Protection Switching post for more detailed information on this protection switching scheme.

Summary

In summary, the main difference between Unidirectional and Bidirectional protection switching is as follows.

For Unidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), then the protection scheme will only switch the defected traffic direction from the Working Transport Entity to the Protect Transport Entity.  The other (non-defective) traffic direction will continue to use the Working Transport Entity.

In the case of Bidirectional Protection Switching, if the Network Elements declare a service-affecting defect in ONLY one direction (of traffic), then the protection scheme will switch BOTH directions of traffic from the Working Transport Entity to the Protect Transport Entity.

Has Inflation Got You Down? With Our Special Pricing, You Can Beat Inflation, and You Can Be 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 the RDI (Remote Defect Indicator)?

This post presents a generic definition of the term: RDI (Remote Defect Indicator) signal. It also describes how and when Network Equipment will transmit this type of signal.


What is the RDI (Remote Defect Indicator) Signal?

What does RDI Mean?

RDI is an acronym for Remote Defect Indicator.

Where is the RDI Signal Used?

RDI is a particular type of alarm signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (back towards upstream Network Equipment) anytime it detects a servicing-affect defect within the signal from that same upstream Network Equipment.

Stated differently, the Network Element (NE) will transmit the RDI indicator (upstream) at the same time (and under the same conditions) that it will send the AIS signal downstream.

For example:  If an NE were to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal, then it will respond to this defect condition by transmitting the RDI signal (back) upstream towards the source of the defective signal.

Whenever the Network Element transmits this RDI signal upstream, it notifies the upstream NE that there are problems with its data.

What EXACTLY is an RDI Signal?

The method we use to transmit the RDI signal depends upon the telecom/datacom standard and network layer we use.

However, in most cases, the Network Element will transmit the RDI signal by setting a certain overhead bit-field (within the signal it is transmitting back to the remote or upstream NE) to “1”.

The Network Element will continue to set this bit-field to “1” within each data frame (transmitting back to the remote NE) for as long as it declares the defect within its incoming data stream.

Likewise, once the Network Element clears the service-affecting defect, it will stop sending the RDI signal by clearing that same overhead bit-field to “0”.

For OTN applications, we call the RDI signal the BDI (or Backward Defect Indicator) signal.

I have included posts that describe the BDI signal for both the OTUk and ODUk frames.

For example, SONET Line-Terminating Equipment will transmit the RDI-L indicator, and SONET Path-Terminating Equipment will send the RDI-P indicator.

In the case of PDH signals (e.g., T1/E1 or T3/E3), we call the RDI signal by other synonymous names such as FERF (Far-End Receive Failure) or the “Yellow Alarm.

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

Discounts Available for a Short Time!!!

When do we transmit the RDI Signal?

We will use a couple of examples to illustrate how and when we transmit the RDI signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a simple illustration of a portion of a 3R Repeater/Regenerator, which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West and E – East)
  • Two (2) Transmit Line Interface blocks (W – West and E – East)
  • Two (2) Transmit Framer blocks (W – West and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator)
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West and E – East)

In this figure, our 3R Repeater/Regenerator receives a good (error-free) signal from the West Terminal.

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

If the Receive Line Interface (W) and Receive Framer (W) blocks were to declare no problems within this signal.  The 3R Repeater/Regenerator would allow this signal to pass through both the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

The Receive Line Interface (W) and the Receive Framer (W) blocks would also do nothing to alter the data that the Near-End Transmitter circuitry (e.g., the Transmit Line Interface (W) and Transmit Framer (W) blocks) is transmitting back out to the West Terminal.

Figure 1 presents an illustration of this Normal (No Defect) Condition.

3R Repeater/Regenerator during Normal Conditions

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1 to focus our discussion on this Defect Declaration to the RDI Generation mechanism on the West-side of the 3R Repeater/Regenerator circuit.

Let’s discuss the case where we will transmit the RDI indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another simple illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that a backhoe or some other mishap severed this signal.

Nonetheless, this means that our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

In this case, the 3R Repeater/Regenerator will respond by doing all the following:

  • The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.
  • The Transmit Framer (E) and the Transmit Line Interface (E) (which sit directly behind the Receive Line Interface and Framer blocks – that are declaring the dLOS condition) will now transmit the AIS indicator (to the East Terminal) as we discussed in the AIS post of this blog.
  • Additionally, the Receive Line Interface (W) and/or the Receiver Framer (W) blocks will also command its “near-end” transmitting circuitry [e.g., the Transmit Framer (W) and Transmit Line Interface (W) blocks] to start sending the RDI signal, back out to the West Terminal.

Figure 2 illustrates the dLOS/RDI Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator when transmitting RDI

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition

The Transmit Framer (W) and Transmit Line Interface (W) blocks will send the RDI indicator to the West Terminal for as long as the Receive Line Interface (W) and the Receive Framer (W) blocks declare the dLOS defect within the signal they are receiving from the West Terminal.

The Transmit Framer (W) and Transmit Line Interface (W) blocks will stop sending the RDI indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and starts to receive good/normal data from the West Terminal.

In addition to the dLOS defect, the Network Element will transmit the RDI Indicator (upstream) in response to any other service-affecting defects, such as:

  • OTN Applications (Sending the SM-BDI or PM-BDI Indicator)
    • dLOF – Loss of Frame defect
    • dLOM – Loss of Multi-Frame defect
    • dLOFLANE – Loss of Frame defect for Logical Lane (for OTL3.4 or OTL4.4 applications)
    • dLOL – Loss of Lane Alignment defect (for OTL3.4 or OTL4.4 applications)
    • dLOFLOM – Loss of Frame and Multi-Frame defect (for Multiplexed Applications)
    • dLOOMFI – Loss of OMFI defect (for Multiplexed Applications using an ODU4 server signal)
    • dPLM – Payload Type Mismatch (for Multiplexed Applications)
    • dTIM – Trail Trace Identifier Mismatch defect

Please check out the appropriate blog posts to learn more about the SM-BDI or PM-BDI indicators for OTN applications.

Why do we bother to transmit the RDI Signal?

The main reason we send the RDI signal (back to upstream equipment) in response to service-affecting defects is to alert that NE that there is a service-affecting defect within its output signal between its location and that of the next downstream NE.

This notification aids in troubleshooting and system debugging of fault conditions in the network.

Inflation’s Got You Down? Our Discounts Can Help You Beat Inflation and Make You an Expert on OTN!! Click on the Banner Below to Learn More!!!

Discounts Available for a Short Time!!!

What is AIS (Alarm Indication Signal)?

This post defines and describes the AIS (Alarm Indication Signal). It also describes how and when Network Equipment will transmit this type of signal.


What is an AIS (Alarm Indication Signal)?

What does the term AIS Mean?

AIS is an acronym for Alarm Indication Signal.

Where is the AIS Signal Used?

The AIS signal is a particular type of alarm (or maintenance) signal that a Network Element (within a Telecom/Datacom application) will generate and transmit (in its downstream path) anytime it detects some service-affecting defect upstream.

For example:

Suppose a Network Element (NE) was to declare the LOS (Loss of Signal) or the LOF (Loss of Frame) defect within its incoming telecom/datacom signal. In that case, it will respond to this defect condition by transmitting the AIS signal downstream.

Whenever the Network Element transmits this AIS signal downstream, it is (in effect) replacing its defective incoming signal with the AIS signal.

What EXACTLY is an AIS signal?

The exact pattern/signature of an AIS signal depends upon the telecom/datacom standard and network layer we use.

For some datacom/telecom standards, the AIS signal is transmitted (and received) as an Unframed All One’s pattern.

In other standards, we will transmit the AIS indicator as a Framed All One’s pattern (e.g., where the framing alignment fields still use typical values, but the payload fields are filled with an All One’s pattern).

Finally, the OTUk AIS pattern is an Unframed PN-11 (PRBS11) pattern.

In all cases, the NE will generate and transmit the AIS signal at the nominal line rate (of the customarily transmitted signal).

The frequency accuracy requirements for this AIS signal also depend on the governing standards for the Telecom/Datacom system.

I have included posts that define the AIS patterns for OTUk and ODUk types of signals (for OTN applications).

When do we transmit the AIS pattern?

We will go through a couple of examples to illustrate how and when we will transmit the AIS signal.

Example # 1 – The Unerred/Normal Condition

Figure 1 presents a straightforward illustration of a portion of a 3R Repeater/Regenerator, which consists of the following components:

  • Two (2) Receive Line Interface blocks (one block is labeled W for West, and the other block is labeled E for East)
  • Two (2) Receive Framer blocks (W – West and E – East)
  • Two (2) Transmit Line Interface blocks (W – West and E – East)
  • Two (2) Transmit Framer blocks (W – West and E – East)
  • CS (Clock Smoothing/Jitter Attenuation) PLL (Phase-Locked Loop)
  • AIS OSC (Stand-Alone Oscillator).
  • FIFO/Buffer
  • Two (2) Defect Decoder blocks (W – West and E – East)

In this figure, our 3R Repeater/Regenerator receives a good (error-free) signal from the “West Terminal.”

The 3R Repeater/Regenerator will first receive this signal through its Receive Line Interface (W) block.

Afterward, this signal passes through to the Receive Framer (W) block.

Suppose the Receive Line Interface (W) and the Receive Framer (W) blocks were to detect no problems within this signal. In that case, the 3R Repeater/Regenerator will allow this signal to pass through the Transmit Framer (E) and Transmit Line Interface (E) blocks as is.

Our 3R Repeater/Regenerator will transmit this same data to the East Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the outbound data (towards the East Terminal) based upon the Recovered Clock signal (which originated from the West Terminal and has been routed through the Clock Smoothing PLL for Jitter Attenuation purposes).

Figure 1 presents an illustration of this Normal (No Defect) Condition.

Portion of 3R Repeater/Regenerator during Normal Operation

Figure 1, Illustration of the 3R Repeater/Regenerator – during Good/Normal Conditions.

Please note that I have grayed out the non-relevant portions of Figure 1 so we can focus our discussion on this Defect Declaration to AIS Generation mechanism in the West-to-East Terminal Path.

Now we will illustrate the case where we will transmit the AIS indicator.

Example # 2 – The dLOS/Abnormal Condition

Figure 2 presents another straightforward illustration of a 3R Repeater/Regenerator.

However, in this figure, there is an impairment in the signal that originates from the West Terminal such that our Network Element is now declaring the dLOS (Loss of Signal) defect with this signal.

It is possible that a backhoe or some other mishap severed this signal.

Nonetheless, our 3R Repeater/Regenerator is no longer receiving its signal from the West Terminal.

This also means that our 3R Repeater/Regenerator has no data to send to the East Terminal.

In this situation, our 3R Repeater/Regenerator will respond by doing the following things.

The Receive Line Interface (W) or the Receive Framer (W) blocks will declare the dLOS (Loss of Signal) defect with the signal that it is receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) (which resides directly behind the Receiving Line Interface and Framer blocks – that are declaring the dLOS condition) will proceed to transmit the AIS indicator (to the East Terminal) as a replacement signal for the signal that we are no longer receiving from the West Terminal.

Additionally, the Transmit Framer (E) and Transmit Line Interface (E) blocks would transmit the AIS pattern (towards the East Terminal) based upon the output frequency of the AIS Oscillator (which is a stand-alone oscillator – that operates at the specified line-rate/clock frequency).

Figure 2 illustrates the dLOS/AIS Transmission Condition for our 3R Regenerator/Repeater.

3R Repeater/Regenerator declaring dLOS and transmitting AIS

Figure 2, Illustration of the 3R Repeater/Regenerator – during the dLOS/Abnormal Condition.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will continue to transmit the AIS indicator to the East Terminal for the duration that the Receive Line Interface (W) and the Receive Framer (W) blocks are declaring the dLOS defect with the signal that they are receiving from the West Terminal.

The Transmit Framer (E) and Transmit Line Interface (E) blocks will cease to transmit the AIS indicator once the Receive Line Interface (W) and the Receive Framer (W) blocks clear the dLOS defect and start to receive good/normal data from the West Terminal.

At this point, the Transmit Framer (E) and Transmit Line Interface (E) blocks will transmit good/normal data to the East Terminal.

In addition to the dLOS defect, the Network Element will typically transmit the AIS indicator (downstream) in response to the following other defects.

  • dLOF (Loss of Frame Defect)
  • dLOM (Loss of Multi-Frame Defect)
  • dLOFLANE (Loss of Frame of Logical Lane) – for OTL3.4 or OTL4.4 applications (*)
  • dLOL (Loss of Lane Alignment) – for OTL3.4 or  OTL4.4 applications (*)
  • dTIM (Trail Trace Identifier Mismatch)

(*) – Need to be a member of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! to access these links.

Why do we bother to transmit the AIS signal as a replacement signal?

We transmit the AIS indicator downstream in response to service-affecting defects for several reasons.

I will list some of those reasons below.

  • Alerts downstream equipment that we have detected and declared a service-affect defect upstream.
  • To suppress (or prevent) the downstream equipment from declaring their service-affecting defect.
  • Aids in troubleshooting and system debugging. It is easier to isolate the causes of defect conditions if we know exactly which NE is declaring the defect and not the whole chain of NEs downstream.
  • The downstream Receive Circuitry provides a much-needed clock signal at the correct bit rate. Clock Recovery PLLs (Phase-Locked-Loops) and Bias Controllers (for Optical Receive circuitry) all need upstream NEs to provide them with a line signal with the appropriate timing (bit-rate).

The AIS signal accomplishes these goals.

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

Discount Available Temporarily