OTN – Lesson 12 – APS Features within Atomic Functions – Part 2

This blog post presents a video that discusses the APS features within some fo the Atomic Functions that we discussed in Lesson 11.

Lesson 12 – Video 13 – Detailed Implementation of APS within the Atomic Functions – Video 2

This blog post continues our discussion of the APS features within various Atomic Functions. In this case, we will present how to implement Automatic Protection Switching in great detail. In particular, we will describe the following:

  • APS Features within the ODUT/ODU_A_So and ODUT/ODU_A_Sk functions (ODUT/TCM Layer – SNC/S Monitoring)
    • How do we implement the APS features within these Atomic Functions to support TCM Layer i SNC/S Monitoring and Protection-Switching?
    • How do we implement a complete System-Level design (using these atomic functions along with the ODUT_TT_So and ODUT_TT_Sk Atomic Functions)?
      • NOTE: We discussed these atomic functions in Lesson 11. However, we did not discuss the APS features (within those functions) then.

More specifically, we discuss how our system should implement APS and the APS Communication Protocol whenever the upstream ODUT_TT_Sk Atomic Function declares either a Service-Affecting or the TCMi-dDEG defect.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – APS Features within Atomic Functions – Part 2”

OTN – Lesson 12 – APS Features within Atomic Functions – Part 1

This blog post presents a video that discusses the APS features within some of the Atomic Functions that we discussed in Lessons 9 and 10.

Lesson 12 – Video 12 – Detailed Implementation of APS within the Atomic Functions – Video 1

This blog post starts our discussion of the APS Features within various Atomic Functions. In this case, we will present how to implement Automatic Protection Switching in great detail. In particular, we will describe the following:

  • APS Features within the OTUk/ODUk_A_So and OTUk/ODUk_A_Sk functions (OTU-Layer/SNC/I Monitoring)
    • How do we implement the APS features within these Atomic Functions to support OTU-Layered SNC/I Monitoring and Protection-Switching?
    • How do we implement a complete System-Level design (using these atomic functions along with the OTUk_TT_So and OTUk_TT_Sk Atomic Functions)?
      • NOTE: We discussed these atomic functions in Lesson 9. However, we did not discuss the APS features (within those functions) then.
  • APS Features within the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (ODU-Layer/SNC/I Monitoring)
    • How do we implement the APS features within these Atomic Functions to support ODU-Layered SNC/I Monitoring and Protection-Switching?
    • How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
      • NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.
  • APS Features of the ODUkP/ODUj-21_A_So and ODUkP/ODUj-21_A_Sk functions (CL-SNCG/I Monitoring)
  • How do we implement the APS features within these Atomic Functions to support CL-SNCG/I Monitoring and Protection-Switching?
  • How do we implement a complete System-Level design (using these atomic functions along with the ODUk_TT_So and ODUk_TT_Sk Atomic Functions)?
    • NOTE: We discussed these atomic functions in Lesson 10. However, we did not discuss the APS features (within those functions) then.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – APS Features within Atomic Functions – Part 1”

OTN – Lesson 12 – Conclusion of Discussion of APS Commands for Protection Switching – Part IV

This blog post presents a video that concludes our discussion of APS Commands via the APS/PCC Communications Protocol

Lesson 12 – Video 11 – Detailed Discussion of APS Commands – Video 4

This blog post completes our discussion of APS Commands and the APS/PCC Communications Protocol. This video serves as Video 4 in this discussion. This blog post briefly discusses the SD, Manual Switch, Wait-to-Restore (WTR), Reverse-Request (RR), and Do-Not-Revert (DNR) APS Commands.

Additionally, this video defines and discusses the 1 Phase APS Communication, 2 Phase APS Communication and 3 Phase APS Communication Procedures.

Finally, this video will define APS Recovery Time. This video will also present the ITU-T G.873.1 APS Recovery Time Requirements.

More specifically, this video will cover the following topics:

Detailed Topics Discussed

  • APS Commands (Continued)
    • SD_W (Signal Degrade in the Working Transport Entity)
    • SD_P (Signal Degrade in the Protection Transport Entity)
    • WTR (Wait-to-Restore)
    • RR (Reverse Request)
    • DNR (Do Not Revert)
  • 1 Phase APS Communication
    • Advantages of 1 Phase
    • Disadvantages of 1 Phase
  • 2 Phase APS Communication
    • Advantages of 2 Phase
    • Disadvantages of 2 Phase
  • 3 Phase APS Communication
    • Advantages of 3 Phase
    • Disadvantages of 3 Phase
  • Definition of APS Recovery Time

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Conclusion of Discussion of APS Commands for Protection Switching – Part IV”

OTN – Lesson 12 – Continuation of Discussion of APS Commands for Protection Switching – Part III

This blog post contains a video that continues the discussion of the APS Commands. This video serves as Video 3 of this series of APS Command videos.

Lesson 12 – Video 10 – Detailed Discussion of APS Commands – Video 3

This blog post continues our discussion of APS Commands and the APS/PCC Communication Protocol. This video serves as Video 3 in this discussion. This blog post discusses completing the Force Switch Commands and the SF (Signal Fail) Commands using the APS/PCC Communication Protocol.

In particular, this video will discuss the following topics:

  • Executing the Force Switch – Normal Traffic Signal n to Protection (for the 1:N Protection Architecture) – Continued from Video 9
    • Implementing the Force Switch – NULL Test Signal to Protection Command – another way to resume Normal Operation.

Signal Fail APS Commands

  • Executing the Signal Fail – Working Transport Entity (SF_W) Command (for the 1+1 Protection Architecture)
    • How does a given Network Element invoke the SF_W Command?
    • The Protection Group’s operation during SF_W Command execution.
    • How do we recover from this Command (for a Reverting System)?
      • Use of the WTR (Wait-to-Restore) Command
  • Executing the Signal Fail – Protection Transport Entity (SF_P) Command (for the 1+1 Protection Architecture)
    • How does a given Network Element invoke the SF_P Command?
    • The Protection Group’s operation during SF_P Command execution.
    • How do we recover from this Command?
  • Executing the Signal Fail – Working Transport Entity (SF_W) Command (for the 1:N Protection Architecture)
    • How does a given Network Element invoke the SF_W Command?
    • The Protection Group’s operation during SF_W Command execution.
    • How do we recover from this Command (for a Reverting System)?
      • Use of the WTR (Wait-to-Restore) Command.
  • Executing the Signal Fail – Protection Transport Entity (SF_P) Command (for the 1:N Protection Architecture)
    • How does a given Network Element invoke the SF_P Command?
    • The Protection Group’s operation during the SF_P Command execution.
    • How do we recover from this Command?

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Continuation of Discussion of APS Commands for Protection Switching – Part III”

OTN – Lesson 12 – Continuation of Discussion of APS Commands for Protection Switching – Part II

This blog post presents a video that continues our discussion of APS Commands via the APS/PCC Communication Protocol. This video serves as Part 2 of this discussion.

Lesson 12 – Video 9 – Detailed Discussion of APS Commands – Video 2

This blog post continues our discussion of APS Commands and the APS/PCC Communication Protocol. This video serves as Video 2 in this discussion. This blog discussed implementing the LoP (Lock Out of Protection) and Force Switch Commands using the APS/PCC Communication Protocol.

In particular, this video will discuss the following topics:

  • Executing the LoP (Lock Out of Protection Command) – for both the 1+1 and 1:N Protection Architectures
    • What does the LoP Command do to the Protection Group?
    • How do we Implement this Command?
    • How do we Terminate this Command (to resume Normal Operation)
  • Executing the Force Switch – Normal Traffic Signal to Protection (for the 1+1 Protection Architecture)
    • How does this command’s execution affect the Protection Group’s operation?
    • How do we Implement this Command?
    • Implementing the Force Switch – NULL Test Signal to Protection Command – to resume Normal Operation.
  • Executing the Force Switch – Normal Traffic Signal n to Protection (for the 1:N Protection Architecture)
    • How does this command’s execution affect the Protection Group’s operation?
    • How do we Implement this Command?
    • Implementing the Force Switch – Extra Traffic Signal to Protection Command – to resume Normal Operation.

To Learn More About the LoP (Lock Out of Protection) and Force Switch Commands, Check Out the Video Below.

Continue reading “OTN – Lesson 12 – Continuation of Discussion of APS Commands for Protection Switching – Part II”

OTN – Lesson 12 – Introduction to APS and the APS Communication Protocol for Protection Switching

This blog post presents a video that shows how to implement APS (Automati Protection Switching) both with and without using an APS Communication Protocol.

Lesson 12 – Video 8 – Detailed Discussion of APS without and with the APS Communication Protocol – Video 1

This blog post describes how we can implement APS (Automatic Protection Switching) without using an APS Communication Protocol. Afterward, this blog introduces how to implement APS using the APS Communication Protocol. This video serves as the first of several videos on this topic.

In particular, this video will discuss the following topics:

  • Executing APS without using the APS Communication Protocol
    • Under what conditions can we implement APS without using an APS Communication Protocol?
    • Why can we implement APS (without an APS protocol) in this case?
    • When not supporting an APS Communication Protocol, the Architecture/Design of the Protection-Switching Controllers.
    • How to implement Automatic Protection Switching – without implementing an APS Communication Protocol.
  • Executing APS with an APS Communication Protocol
    • Under what conditions must we implement APS with an APS Communication Protocol?
    • Why do we need to use an APS Communication Protocol for these cases?
    • How to implement Automatic Protection Switching – while using an APS Communication Protocol
      • Introduction to the APS/PCC Field for OTN/Linear Protection Switching Applications (per ITU-T G.873.1).
      • The Architecture/Design of the Protection-Switching Controllers – 1+1 Protection Architecture
      • The Architecture/Design of the Protection Switching Controllers – 1:N Protection Architecture
      • The NR (No Request) Command

To Learn How to Implement APS, with and without an APS Communication Protocol, Check Out the Video Below.

Continue reading “OTN – Lesson 12 – Introduction to APS and the APS Communication Protocol for Protection Switching”

What is the Byte-Format of the APS/PCC Field for Linear Protection Switching Applications within the OTN

This blog post briefly defines and describes the Nibble and Byte fields of the APS/PCC field, for Linear-Protection-Switching and OTN Applications.

Introduction to the APS/PCC Field

This blog post aims to define and describe the byte format of the APS/PCC field within the ODU Overhead whenever we support Linear Protection Switching applications within the OTN. ITU-T G.873.1 specifies the byte/nibble format of the APS/PCC field that we use within the OTN for Linear Protection Switching.

Whenever the System Designer needs to support the following:

  • Linear Protection Switching within the Optical Transport Network (defined within ITU-T G.709)
  • An APS Communication Protocol (because the user is either using the 1:N Protection Architecture or Bidirectional Switching

Then the user will need to use the APS/PCC (Automatic Protection Switching/Protection Control Communications) channel (and field) to support the APS protocol.

The APS/PCC field resides within the ODU Overhead, as I show below in Figure 1.

Location of APS/PCC field within the ODU Overhead

Figure 1, Location of the APS/PCC Field within the ODU Overhead of an OTU Frame.

Figure 1 shows that the APS/PCC field resides within the fourth row and the fifth through eighth-byte position within an OTU frame. The length of the APS/PCC field is four bytes wide.

Whenever we are designing OTN networks to also support protection switching (and using the APS Communications Protocol) in the process, then we will use the APS/PCC field to transport APS Messages from one Network Element to another.

Byte/Nibble Format of the APS/PCC Field

I show the Byte/Nibble format of the APS/PCC field below in Figure 2.

APS/PCC Field Format for Linear Protection Switching Applications

Figure 2, Byte/Nibble format of the APS/PCC Field

Figure 2 shows that the APS/PCC field consists of the following Nibbles and Byte-fields:

Request/State Nibble (Bits 1-4)

The purpose of this Nibble-field is to either:

  • Transmit Protection-Switching commands or requests to the remote terminal of the Protection-Group, or
  • Transmit information about Defect Conditions or States.

Table 1 presents a list of values (within the Request/State Nibble field) and their corresponding Meaning.

Table 1, Standard Values within the Request/State Nibble field and their Corresponding Meaning.

Meaning of Request State Nibble field of APS/PCC Field - Linear Protection Applications

So, for example, if a given Protection Switching terminal needs to transmit the SF Command, it would set the Request/State Nibble (within its outbound APS Message) to [1, 1, 0, 0], as I show in Table 1.

Protection Type Nibble (Bits 5 – 8)

The Protection Type Nibble field occupies the second set of four bits of the APS/PCC field.

The purpose of this nibble-field is to communicate (to the remote end of the Protection Group) many of the governing parameters of our Protection-Switching scheme.

The following table presents a list of the bit-fields within the Protection-Type Nibble and their meaning/description.

Table 2, A List of the Bit-Fields, within the Protection-Type Nibble and their Meaning/Description

Protection Type Nibble of APS/PCC field
Bit A – APS Channel

This bit-field indicates if the Protection Group is either supporting an APS Communication Protocol or not, as I describe below.

  • 0 = No APS Channel (Not using the APS Communication Protocol)
  • 1 = APS Channel (We are using the APS Communication Protocol)
Bit B – Bridge (Permanent)

This bit-field indicates if the Protection Group supports the 1+1 or 1:N Protection Architecture, as I show below.

Bit D – Directional Switching

This bit-field indicates if the Protection Group supports Unidirectional or Bidirectional Switching, as shown below.

  • 0 = Unidirectional Switching
  • 1 = Bidirectional Switching
Bit R – Revertive Operation

This bit-field indicates if the Protection Group supports the Revertive or Non-Revertive Operation, as I show below.

  • 0 = Non-Revertive Operation
  • 1 = Revertive Operation

Requested Signal Byte – APS/PCC Field – Byte 2

The Requested Signal byte-field identifies the signal that the Near-End (e.g., the Requesting Terminal) requests to be carried over to the Protection Transport Entity.

Ultimately, we a request at the Far-End Terminal to place the Requested Signal on the Protection Transport Entity, following this Protection Command.

For the 1+1 Protection Architecture

For the 1+1 Protection Architecture, the Protection-Switching Terminal should set this byte-field to “0x01” (for most APS Commands) to denote Normal Traffic Signal # 1. Normal Traffic Signal # 1 is typically the ONLY Normal Traffic Signal in a given direction for a 1+1 Protection Switching Architecture.

For the 1:N Protection Architecture

If the Requesting Terminal wishes to command the remote end to bridge the NULL Test Signal to the Protection Transport entity, it should set this byte-field to 0x00 when issuing an APS command.

Likewise, suppose the Requesting Terminal wishes to command the remote end to bridge the Extra Traffic Signal to the Protection Transport entity. In that case, it should set this byte-field to 0xFF when issuing an APS command.

Finally, suppose the Requesting Terminal wishes to command the remote end to bridge a Normal Traffic Signal to the Protection Transport entity. During a Protection Switching event, it should set this byte-field to the appropriate number (corresponding with the defective Normal Traffic Signal). Valid Numbers for the Requested Byte value range from 0x01 to 0xFE, depending upon which Normal Traffic signal requires Protection-Switching.

Table 2 lists the appropriate Requested Signal Values for the 1:N Protection Architecture.

Table 2, List of Appropriate Requested Signal Values for the 1:N Protection Architecture

Requested Signal Byte Meaning - APS/PCC Field

Bridged Signal Byte – APS/PCC Field – Byte 3

For this field, the REQUESTING terminal will set this byte-field to the value that identifies which signal this terminal is currently bridging to the Protection Transport entity.

For the 1+1 Protection Architecture


When using the 1+1 Protection Architecture, the Protection-Switching Terminal should set this byte-field to “0x01” (for most APS Commands) to denote Normal Traffic Signal # 1. Normal Traffic Signal # 1 is typically the ONLY Normal Traffic Signal in a given direction for a 1+1 Protection Switching Architecture.

For the 1:N Protection Architecture

If the Requesting Terminal is bridging the NULL Test Signal to the Protection Transport entity, it must set this byte-field to 0x00 when issuing an APS command. The Requesting Terminal tells the remote terminal that it is bridging the NULL Test Signal to the Protection Transport entity.

Likewise, if the Requesting Terminal is bridging the Extra Traffic Signal to the Protection Transport entity, it must set this byte-field to 0xFF when issuing an APS command.

Finally, suppose the Requesting Terminal is currently implementing Protection Switching and is bridging one of the Normal Traffic Signals to the Protection Transport entity. In that case, it must identify that Normal Traffic Signal by setting this byte-field to the appropriate number (corresponding with the defective Normal Traffic Signal). Valid Numbers for the Requested Byte value range from 0x01 to 0xFE, depending upon which Normal Traffic signal requires Protection-Switching.

Table 3 presents a list of the appropriate Bridged Signal Values for the 1:N Protection Architecture.

Table 3, List of Appropriate Bridged Signal Values for the 1:N Protection Architecture

Bridged Signal Byte Meaning - APS/PCC Field

Reserved Byte – Byte 4

This byte-field is reserved for future use/standardization.,

Example of Using the APS/PCC Field for the 1+1 Protection Architecture

Let’s suppose we use the 1+1 Protection Architecture within our Protection Scheme. Further, let’s assume that one of the Network Elements declares the SF_W (Signal Fail within the Working Transport Entity) condition, as shown below in Figure 3.

SF Declared in Normal Traffic Signal # 2 - 1+1 Protection Architecture

Figure 3, Tail-End Circuit at NE Z declares the SF_W Condition.

NE Z Sends the SF_W APS Message to NE A

In this case, NE Z (the Network Element declaring the SF_W Condition) will need to send the SF_W APS Command to the remote terminal. I show this APS Command below in Figure 4.

NE Z sends SF_W APS Command to NE A - 1+1 Protection Architecture

Figure 4, NE Z sending the SF_W APS Command to NE Z.

Please note that (within this APS Command) NE Z is setting the Request Command to [1, 1, 0, 0] to denote that it is transmitting the SF Command.

Further, NE Z is also setting the Protection Type Nibble to information NE A, which is operating with the following Protection-Switching characteristics:

  • A = 1: We are using an APS Communication Protocol
  • B = 0: We are using a Permanent Bridge (for a 1+1 Protection Architecture)
  • D = 1: We are supporting Bidirectional Switching, and
  • R = 1: We are supporting Revertive Switching

Next, NE Z is setting the Requested Byte to “0x01”. This setting denotes two things:

  • First, we are declaring the SF condition within the Working Transport Entity. If we set the Requested Byte to “0x00”, this would denote that we are declaring the SF condition with the Protection Transport entity.
  • Second, we are requesting that the remote terminal (NE A, within Figure 4) should bridge the Normal Traffic Signal (Signal # 0x01) to the Protection Transport entity. (NOTE: Because this is the 1+1 Protection Architecture, we are already permanently bridging the Normal Traffic Signal (0x01) to the Protection Transport entity.

Finally, NE Z is setting the Bridged Byte to “0x01”. This setting denotes that we are already bridging the Normal Traffic Signal (0x01) to the Protection Transport Entity. The Permanent Bridge is inherent to the 1+1 Protection Architecture.

Subsequent APS Commands

NE A and NE Z will exchange more APS Commands to deal with this instance of the SF condition. I’m only showing the initial request from NE Z to NE A.

Example of Using the APS/PCC Field for the 1:N Protection Architecture

Let’s suppose we are using the 1:N Protection Architecture within our Protection Scheme. Further, let’s assume that one of the Network Elements declares the SF_W Condition with Working Transport Entity # 2, as I show below in Figure 5.

SF Declared in Normal Traffic Signal # 2 - 1:N Protection Architecture

Figure 5, Tail-End Circuit at NE Z declares the SF_W Condition for Working Transport Entity # 2.

NE Z Send the SF (within Normal Traffic Signal # 2) Message to NE A

In this case, NE Z (the Network Element declaring the SF_W Condition) will need to send the SF_W APS Command to the remote terminal. I show this APS Command below in Figure 6.

NE Z sends SF_W APS Command to NE A - 1:N Protection Architecture

Figure 6, NE Z sending the SF_W APS Command to NE Z.

Please note (again) that (within this APS Command) NE Z is setting the Request Command to [1, 1, 0, 0] to denote that it is transmitting the SF Command.

Further, NE Z is also setting the Protection Type Nibble to information NE A, which is operating with the following Protection-Switching characteristics:

  • A = 1: We are using an APS Communication Protocol
  • B = 1: We are using a Non-Permanent Bridge (for a 1:N Protection Architecture)
  • D = 1: We are supporting Bidirectional Switching, and
  • R = 1: We are supporting Revertive Switching

Next, NE Z is setting the Requested Byte to “0x02”. This setting denotes two things:

  • First, we are declaring the SF condition within the Working Transport Entity. If we set the Requested Byte to “0x00”, this would denote that we are declaring the SF condition with the Protection Transport entity.
  • Second, we are requesting that the remote terminal (NE A, within Figure 5) should bridge the Normal Traffic Signal # 2 (Signal # 0x02) to the Protection Transport entity. We are declaring the defect with Working Transport Entity # 2. We need to alert the remote terminal that we need to bypass this signal path.

Finally, NE Z is setting the Bridged Byte to “0x02”. This setting denotes that we are already bridging the Normal Traffic Signal # 2 (0x02) to the Protection Transport Entity.

Subsequent APS Commands

NE A and NE Z will exchange more APS Commands to deal with this instance of the SF condition. I’m only showing the initial request from NE Z to NE A.

More Information/Training

If you wish for more information/training on this topic, then check out the video on the APS Communication Protocol (*).

(*) – Requires membership to access.

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) ...
Read More

What is the pF_DS (Far-End Defect Second) Performance-Monitoring Parameter for the ODUk Layer?

This blog post breifly defines the pF_DS (Far-End Defect Second) Performance Monitoring paramteter that the OTN PTE will compute and generate.

This blog post aims to briefly define and describe the pF_DS (Far-End Defect Second) Performance Monitoring parameter that the OTN PTE (or ODUk_TT_Sk Atomic Function) will compute and generate.

The OTN PTE (or ODUk_TT_Sk function) will include information on pF_DS without each Performance Monitoring report that it sends to System Management.

Performance Monitoring Reports

NOTES:

  1. The OTN STE (OTUk_TT_Sk Atomic Function) also monitors and generates information on the pF_DS (Far-End Defect Second) parameter at the OTUk Layer. Please see the pF_DS at OTUk Layer Post for more details on this parameter.
  2. Throughout this post, I will be using the terms: OTN PTE and ODUk_TT_Sk Function interchangeably. In the context of this blog post, these two terms mean the same thing.

Introduction

At the ODUk Layer, the OTN (Sink) PTE is the entity that is responsible for detecting and reporting Far-End Defect Second events.

As the OTN PTE receives and monitors its incoming ODUk signal, it will check for many things. It will continuously check for the incoming ODUk signal for Service-Affecting Defect (e.g., dAIS, dOCI, dLCK, dTIM, etc.) as well as bit (or symbol) errors (e.g., PM-BIP-8 errors and PM-BEI errors).

Another thing that the OTN PTE will do (as it continuously monitors its incoming ODUk signal) is to divide each second of (monitoring) time into the following two categories:

  • Far-End Available (Working) Seconds, and
  • Far-End Defect Seconds

Anytime the OTN PTE detects and categorizes a given one-second period as being a Far-End Defect Second, it will increment the pF_DS parameter and report that information to System Management.

New Comprehensive OTN Training…. Available Now. Click on the Banner Below to Learn More!!

Discounts Available for a Short Term!!

So When does the OTN PTE detect and flag a given One-Second Period as being a “Far-End Defect Second”?

ITU-T G.798 presents the following Performance Monitoring Equation for the ODUk_TT_Sk function.

pF_DS <- dBDI

Where:

dBDI is the current state of the ODUk-BDI or the Backward Defect Indicator Defect (at the ODUk Layer).

The OTN PTE (or ODUk_TT_Sk function) will continuously evaluate the above equation as it monitors its incoming ODUk signal.

This equation states that the OTN PTE will declare a given one-second period as being a Far-End Defect Second if it has declared the dBDI defect condition during any portion of that one second.

A given OTN PTE will declare a one second period as a Far-End Defect Second if the remote OTN PTE declares any of the following defect conditions:

  • dAIS (ODU-AIS)
  • dOCI
  • dLCK
  • dTIM

In this case, the OTN PTE will increment the pF_DS parameter for each one-second period that it categorizes as a Far-End Defect Second.

Conversely, the OTN PTE will declare a one-second period as an Available Second, if the remote OTN PTE is not declaring any of the above-mentioned defects. The OTN PTE will NOT increment the pF_DS parameter in this case.

What Does This Mean in English?

Of course, if the OTN PTE declares the dBDI defect condition, then this also means that the remote PTE is declaring a service-affecting defect condition. In other words, the pF_DS parameter reflects the health of the remote (or Far-End) terminal.

If the remote terminal declares no service-affecting defects, then the near-end terminal will not increment the pF_DS parameter. On the other hand, if the remote terminal declares a service-affecting defect, then the near-end terminal will increment the pF_DS parameter.

So, if the ODUk_TT_Sk function has declared the dBDI defect condition for even a fraction of a given one-second period, it will declare it as a Far-End Defect Second. It will also set the parameter pF_DS to 1 and report that information to System Management.

Conversely, if the OTN PTE determines that the ODUk_TT_Sk function did not declare the dBDI defect condition at all during a given one-second period. In that case, it will declare that one-second period is a Far-End Available (Working) Second. In this case, the OTN STE will NOT set the parameter pF_DS to 1.

Hence the pF_DS parameter reflects the network’s health at the remote terminal (e.g., the other end of the ODUk Path).

Is there such a thing as a Near-End Defect Second?

Throughout this post, we have used the term: Far-End Defect Second. Does this mean that there is another parameter called Near-End Defect Second?

Answer: Yes, there is such a parameter. See the Near-End Defect Seconds (pN_DS) post at the ODUk Layer for more details.

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

Discounts Available for a Short Time!!

And Finally, Click on the Image Below to see More OTN-Related Topics in 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? ...
Read More

OTN – Lesson 12 – Detailed Discussion of SNC/S Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) SNC/S (Subnetwork Circuit Protection – Sublayer) Monitoring for Protection Switching.

Lesson 12 – Video 7 – Detailed Discussion of SNC/S (Subnetwork Circuit – Sublayer) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of SNC/S (Subnetwork Circuit – Sublayer) Monitoring for Protection Switching purposes at the ODU Layer.

In particular, this video will discuss the following topics:

  • A Detailed Review of SNC/S (Subnetwork Circuit Protection/Sublayer) Monitoring.
  • This video shows example locations/conditions of where we would use SNC/S Monitoring and why we would use this form of monitoring.
  • This video also highlights similarities of SNC/S with SNC/I Monitoring.
  • It also shows the differences between SNC/S and SNC/Ne or SNC/Ns monitoring.
  • Finally, this video reviews a Multi-Administrative Domain Network (and
    Tandem Connection Monitoring) and describes how SNC/S works within a given “Protect Domain.”

Check Out the Video Below.

Continue reading “OTN – Lesson 12 – Detailed Discussion of SNC/S Monitoring (Protection Switching)”

OTN – Lesson 12 – Detailed Discussion of SNC/N Monitoring (Protection Switching)

This blog post presents a video that describes (in detail) SNC/N (Subnetwork Protection – Non-Intrusive) Monitoring for Protection Switching.

Lesson 12 – Video 6 – Detailed Discussion of SNC/N (Subnetwork Circuit – Non-Intrusive) Monitoring for Protection Switching

This blog post contains a video that presents a detailed discussion of SNC/N (Subnetwork Circuit – Non-Intrusive Monitoring, for Protection-Switching purposes, at the ODU Layer.

In particular, this video will discuss the following topics:

  • A Detailed Review of SNC/Ne (Subnetwork Circuit Protection/Non-Intrusive End-to-End) Monitoring, and
  • A Detailed Review of SNC/Ns (Subnetwork Circuit Protection/Non-Intrusive Sublayer) Monitoring.
  • This video shows example locations/conditions of where we would use SNC/Ne or SNC/Ns Monitoring and why we would use this form of monitoring.
  • This video also highlights the similarities and differences between SNC/Ne and SNC/Ns Monitoring.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Detailed Discussion of SNC/N Monitoring (Protection Switching)”