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.

Clueless About OTN? We Can Help!! Click Below to Learn More!!

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.

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

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

OTN – Lesson 12 – Introduction to Linear Protection Switching – Part TWO

This blog post contains a Video that serves as the 2nd Introductory Video to Linear Protection-Switching. This video covers Hold-Off Timers, Wait-to-Restore Timers and reviews Trail Protection.

Lesson 12 – Video 2 – Introduction to Linear Protection Switching – Part TWO

This blog post contains a video that covers the second part of our Introduction to Linear Protection-Switching.

In particular, this video discusses and defines the following topics that pertain to Protection-Switching:

  • Nested Protection-Switching Domains
  • Hold-Off Timers – What are They and How are They Useful in a Protection-Switching Design?
  • Wait-to-Restore (WTR) Timers – What are WTR Timers, and why do We Use them?
  • A Review of Trail Protection – This video discusses what Trail Protection is and why it is not very popular in Protection-Switching Applications.

Check Out the Video Below

Continue reading “OTN – Lesson 12 – Introduction to Linear Protection Switching – Part TWO”

Linear Protection Switching

This post briefly defines the term: Linear Protection Switching. It also briefly defines 1+1, 1:N Protection Architectures.


What is Linear Protection Switching?

A Linear Protection-Switching System is a Protection System (or Protection Group) that contains two nodes:

Each of these two nodes is exchanging normal traffic signals, with each other, over a protected network that consists of both the Working Transport entity and the Protect Transport entity.

I show some simple pictures of Linear Protection Switching Systems below in Figures 1, 2, and 3.

The 1+1 Protection-Switching Architecture

1+1 Linear Protection-Switching System

Figure 1, Illustration of a Linear Protection Switching System (A 1+1 Protection-Switching System)

In Figure 1, I show a simple illustration of a 1+1 Protection-Switching system, which also presents the bidirectional traffic flow between the Head-End and Tail-End Nodes.

If you want to learn more about the 1+1 Protection-Switching Architecture, check out the post on this topic.

The 1:N Protection-Switching Architecture

Linear Protection Switching - 1:2 Protection Switching Architecture

Figure 2, Illustration of a Linear Protection Switching System (A 1:2 Protection-Switching System) – for the East to West Direction

Linear Protection Switching - 1:2 Protection-Switching Architecture

Figure 3, Illustration of a Linear Protection Switching System (A 1:2 Protection-Switching System) – for the West to East Direction

Figures 2 and 3 each present an illustration of a 1:2 (or 1:N) Protection-Switching System.

Please note that the 1:N Protection-Switching Architecture figures are more complicated than that for the 1+1 Protection-Switching Architecture.

Therefore, I needed to show this architecture in the form of two figures. 

One figure shows the traffic flowing from West to East, and the other illustrates the traffic flowing from East to West.

If you want to learn more about the 1:2 (or 1:N) Protection-Switching architecture, check out the post on that topic.

In summary, the 1+1 and the 1:N Protection-Switching schemes are Linear-Protection Protection-Switching systems.

Design Variations for Linear Protection-Switching Systems

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

Architecture

Switching Type

Operation Type

APS Protocol – Using the APS/PCC Channel

Click on any of the links above to learn more about these design variations within a Linear Protection-Switching System.

What about Other Protection-Switching Architectures?

There are other types of Protection Switching systems, which are not Linear, such as Shared-Ring Protection-Switching or Shared-Mesh Protection-Switching.

Please see the relevant posts for more information about those types of Protection-Switching Systems.

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

Discount 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) ...