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.
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.
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.
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
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.
- 0 = Permanent Bridge (1+1 Protection Architecture)
- 1 = No Permanent Bridge (1:N Protection Architecture)
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
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
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.
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.
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.
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.
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 Posts
