What is Path Terminating Equipment (PTE) for OTN Applications?
Whenever we are discussing the OTN Digital Layers (e.g., the OPUk, ODUk, and OTUk layers), we can group Networking Circuits and Equipment into two broad categories.
I will be using these terms throughout various OTN-related posts within this blog. Thus, we must have a strong understanding of these terms.
I have devoted this blog post to discussing PTE (Path Terminating Equipment).
I have devoted another post to STE (Section Terminating Equipment).
You can also find a detailed discussion of both PTEs and STEs within Lesson 3 of THE BEST DARN OTN TRAINING PRESENTATION…PERIOD!!! This discussion also describes the differences between PTEs and STEs.
What is the Path?
Before we define the term Path Terminating Equipment (or PTE), we need first to explain the word Path, as it pertains to an Optical Transport Network (OTN).
For OTN applications, there are two different types of Paths.
- A Non-OTN Client Path and
- ODUj to OPUk/ODUk Mapping/Multiplexing Path
We will define each of these types of Paths below.
Non-OTN Client Path
Whenever we are transporting a single non-OTN client signal (such as 100GBASE-R) over OTN (e.g., an OTU4 signal in this case), the Path begins where the circuitry maps the 100GBASE-R signal into an OPU4 signal.
We can say that the 100GBASE-R signal officially enters the OTN at this point.
This Path ends at the location where the circuitry de-maps the 100GBASE-R signal from the OPU4 signal (and exits the OTN) at the other end of the network.
Figure 1 presents a simple illustration of an OTN that contains both some Path Terminating Equipment as well as some STEs.
Figure 1, Illustration of both PTE (Path Terminating Equipment) and STE (Section Terminating Equipment) within an Optical Transport Network
In Figure 1, we show that a Source PTE is mapping a 100GBASE-R signal into an OTU4 signal on the left-hand side of Figure 1.
The OTU4 signal transports this 100GBASE-R signal throughout this OTN and through various Section Terminating Equipment blocks labeled STE#1, STE#2, and STE#3.
Afterward, the OTU4 signal finally arrives at the Sink PTE on the right-hand side of Figure 1.
The Sink PTE then de-maps the 100GBASE-R signal from this OTU4 signal.
In the case of Figure 1, the Path (for the 100GBASE-R signal) is that portion of the OTN that exists between the Source PTE (on the left-hand side of Figure 1) and the Sink PTE (on the right-hand side of the same figure).
As this 100GBASE-R signal travels from the Source PTE to the Sink PTE, it will pass through multiple Sections and STEs (that we describe in another post). This route that the 100GBASE-R signal takes, (through the OTN, via the OTU4 signal), is the Path.
A Closer Look at the Non-OTN Client Path
Now that we have a basic understanding of what a Path is, let’s take a much closer look at the Path.
Figure 2 presents a more detailed illustration of the Non-OTN Client path within an OTN. This figure also indicates where this Path begins and ends within the OTN.
Figure 2, A Closer Look at the Non-OTN Client Path
Once again, Figure 2 shows that the Non-OTN Client Path begins at the point that we map the client signal into an OPU4 signal (and then an ODU4 and OTU4 signal).
In this case, we are mapping a 100GBASE-R client signal into an OPU4 signal at the OPU4 Mapper block.
This figure also shows that this same Path ends at the point where we de-map that same client signal from the OPU4 signal (at the OPU4 De-Mapper block on the lower-right-hand side of Figure 2).
Please note that the diagram in Figure 2 is functionally equivalent to that in Figure 1. In Figure 1, we referred to each of the signals (between the STE and PTE boxes) as being OTU signals. We did not discuss these signals down at the OPU4 or ODU4 layers, as we do in Figure 2.
Let’s now move on to the other type of Path.
Clueless about OTN? We Can Help!!! Click on the Banner Below to Learn More!!!
Corporate Discounts Available!!!
The ODUj to OPUk/ODUk Mapping/Multiplexing Path
Another type of OTN Path is the ODUj to OPUk/ODUk Mapping/Multiplexing Path.
In the ODUj to OPUk/ODUk Mapping/Multiplexing Path, we can map and multiplex numerous lower-speed ODUj signals into a Higher-Speed OPUk/ODUk signal (where k > j).
We describe the exact procedure for mapping/multiplexing lower-speed ODUj signals into a higher-speed OPUk signal in other posts.
Figure 3 presents an illustration of a Unidirectional Network that contains both a Non-OTN Client and the ODUj to OPUk/ODUk Mapping/Multiplexing set of paths.
Figure 3, A Closer Look at the ODUj to OPUk/ODUk Mapping/Multiplexing Path
NOTE: We have already described the Non-OTN Client path earlier in this post. Hence, the reader should now be familiar with this particular type of Path.
Handling the 1000BASE-X/OPU0/ODU0 Signals
In Figure 3, we have a 1000BASE-X (1GbE) signal that we first map into an OPU0 signal (at the Upper-Left-Hand corner of this figure).
We earlier stated that this point of mapping a non-OTN signal (such as a 1000BASE-X signal) into an OTN signal (e.g., an OPU0 in this case) is the beginning of the Non-OTN Client Path.
Once we’ve mapped this signal into an OPU0, then we will also, in turn, map this OPU0 signal into an ODU0 signal.
Afterward, this ODU0 signal goes through some additional processes (that we discuss in detail in other posts) before we map/multiplex this ODU0 signal into an OPU4 signal.
Once we’ve mapped the ODU0 signal (along with 79 other such signals) into an OPU4 signal, this point serves as the entry point for the ODU0 to OPU4/ODU4 Path.
In Figure 3, we labeled this point as the ODU0 to OPU4 Path Demarcation Line.
This is the location where this OPU4 signal begins (and serves as the starting point for this particular Path).
Handing the OPU4/ODU4 Signal
We then quickly map this OPU4 signal into an ODU4 signal and then (eventually) into an OTU4 signal.
Afterward, we convert this OTU4 signal into an optical signal and transmit this signal through three additional sets of STEs before it arrives at the XCVR and Optical I/F at the Remote Terminal.
The remote terminal converts this signal back into the electrical format, where it also terminates both the OTU4 and ODU4 signals.
Finally, the circuitry routes the resulting OPU4 signal to the OPU4 De-Mapper block. The OPU4 De-Mapper block then terminates this OPU4 signal.
This point serves as the OPU4 to the ODU0 Path Demarcation point. This point is the location where this OPU4 signal (and its Path) ends.
This circuitry will then de-map out the ODU0 signal (of interest) along with as many as 79 other such ODU0 signals, from this OPU4 signal.
Next, the ODU0 Terminator block will then terminate this ODU0 signal, extract out the OPU0 signal.
Afterward, it will transmit this data towards the OPU0 De-Mapper block.
The OPU0 De-Mapper block will then de-map out the 1000BASE-X (1GbE) client signal from its incoming OPU0 signal.
Once the OPU0 De-Mapper block de-maps the 1000BASE-X signal from the OPU0 signal, then this point serves as the Non-OTN Client Path Demarcation point.
In other words, this is the point at which this particular OPU0 signal (and its Path) ends.
How the PTE Operates in the Optical Transport Network
For OTN applications, the ODUk Layer is the protocol layer that is responsible for managing and monitoring the transmission/reception of data across a Path.
Path Termination Equipment will process data (in the electrical format) by doing many of the following functions:
In the Transmit Direction
- Mapping data (either Non-OTN client data or lower-speed ODUj data) into an OPUk signal and generating the new OPUk signal and overhead.
- Generating the ODUk overhead, or the ODUk-PMOH (Path Monitoring Overhead) and attaching the ODUk-PMOH to each outbound OPUk frame.
- Sending this data downstream where circuitry will either map this signal into another higher-speed ODUk signal, or it will map this signal into an OTUk frame and precondition it for transmission across the optical fiber.
NOTE: Throughout many of the postings on this blog, we will refer to this ODUk overhead data as the ODUk-PMOH (ODUk-Path Monitoring Overhead) data.
In the Receive Direction
- Receive ODUk data from the upstream OTUk Framer block
- Process and Terminate the ODUk overhead (or ODUk-PMOH). While the PTE is processing the ODUk-PMOH, it will check for the following errors and defects within the incoming ODUk signal.
- Defects or Failures (e.g., dTIM, dPLM, dDEG, dAIS, dOCI, dLCK and PM-BDI)
- Errors (e.g., PM-BIP-8, PM-BEI)
- Terminate the OPUk data-stream and de-map either the Non-Client OTN client or some number of lower-speed ODUj signals.
- Route the de-mapped data downstream for further processing.
Mapping Data (either Non-OTN client data or lower-speed ODUj data) into an OPUk/ODUk signal
Anytime the PTE maps data (be it non-OTN client data or lower-speed ODUj signals) into an OPUk signal, it will do so by using some of the following mapping procedures.
As the PTE uses one of these mapping procedures to load client-data into the OPUk payload, it will load its mapping parameters into the OPUk overhead.
The PTE will also alert the network of the type of traffic that it is transmitting via this OPUk signal by sending the appropriate PSI message via the PSI byte.
Please see the relevant posts for more information on this functionality.
Generating the ODUk Overhead (ODUk-PMOH)
As the PTE receives an OPUk data-stream from upstream circuitry, it will precondition all this data for transport through the Path, by computing and then attaching the ODUk overhead fields (or ODUk-PMOH) to each outbound OPUk frame.
In particular, the PTE will attach some ODUk-PMOH fields to the OPUk frame, which will help it to detect errors and declare and clear certain defect conditions.
Some of the other ODUk-PMOH fields support maintenance/monitoring features such as Tandem Connection Monitoring, the transport of APS (Automatic Protection Switching) Commands as well as other forms of Equipment to Equipment (non-client related) commands and information.
We will discuss each of these topics (e.g., Tandem Connection Monitoring and the APS Channel) in other posts.
The critical thing to note at this point is that the PTE will use the ODUk-PMOH to monitor the overall health of the entire Path (from the point where it creates the ODUk signal to the end where it terminates this signal).
Figure 4 presents an illustration of the ODUk-PMOH that the PTE will use to support the monitoring of this signal as it travels through the Path.
Figure 4, ODUk Overhead (ODUk-PMOH), and Payload fields
NOTE: Please see the ODUk Frame post for more inf0rmation on the ODUk frames and the PMOH fields.
Terminating the OPUk Overhead
After the OTUk signal has been converted into the optical format and has been received and converted back into the electrical domain (by the remote terminal), the remote terminal will then terminate the OTUk signal (because this piece of equipment is an STE).
Once the STE has terminated OTUk-SMOH, it will route the resulting ODUk signal towards down-stream circuitry for further processing.
At this point, the PTE will proceed to terminate the ODUk-PMOH.
As the PTE performs this task, it will check the ODUk-PMOH for the occurrence of bit-errors and defects.
The PTE will report the occurrences of such errors and defects to System Management.
Additionally, the PTE will also strip off and remove all ODUk-PMOH data from this incoming stream (which leaves us with just an OPUk data-stream now).
This OPUk data-stream is then routed to a De-Mapper block for further processing.
The critical takeaway on this is that the PTE will rely on the ODUk-PMOH data (as we show in Figure 4) to process, manage, and ultimately terminate the ODUk stream.
NOTE: Each ODUk signal (whether it is a lower-speed ODUj tributary signal, that we map/multiplex into a higher-speed ODUk server signal), or an ODUk signal, (that is carrying a single Non-OTN client signal) will have its ODUk-PMOH data.
This means that PTE (whether it is for transporting a single Non-OTN client signal or one of many lower-speed ODUj signals) will manage and monitor its own respective ODU signal.
I have redrawn Figure 2 to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the Non-OTN Client Path (of 100GBASE-R over OPU4/ODU4).
I have included this figure below in Figure 5.
Figure 5, Illustration of the 100GbE to ODU4 Path. (The Entire ODU4 Path is shaded).
NOTE: I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (Non-OTN Client ODU4).
This also means that the circuitry (that we show above in Figure 3) would require as many as 81 sets of PTE.
- 80 sets of PTE would be required to monitor each of the 80 ODU0 signals (that we are transporting via the OPU4/ODU4 signal), and
- One additional PTE would be required to monitor the more significant ODU4 signal.
I have also redrawn Figure 3 to show where the circuitry generates and terminates/monitors the ODU0-PMOH within the Non-OTN Client Path (of 1000BASE-X over OPU0/ODU0).
I have included this figure below in Figure 6.
Figure 6, Illustration of the 1GbE to ODU0 -> ODU4 Path. (The entire ODU0 Path is shaded).
NOTE: In Figure 6, I have highlighted the locations where the Path Circuitry Generates and Monitors/Terminates the ODU0-PMOH (Non-OTN Client ODU0).
Finally, I have redrawn Figure 3 (again) to show where the circuitry generates and terminates/monitors the ODU4-PMOH within the ODU0 mapped/multiplexed into OPU4/ODU4 Path.
I have included this figure below in Figure 7.
Figure 7, Illustration of the 1GbE to ODU0 -> ODU4 Path. (The Entire ODU4 Path is shaded).
NOTE: I have highlighted the Locations where the Path Circuitry Generates and Monitors/Terminates the ODU4-PMOH (ODU0 Mapped/Multiplexed into OPU4/ODU4).
De-Mapping the Client Signal from the OPUk Payload
Once the OPUk has reached the De-Mapper block, the De-Mapper block will de-map out the client data (be it non-OTN client data or lower-speed ODUj tributary signals) using the mapping parameters that the Source PTE loaded into the OPUk overhead bytes (when it was mapping these clients into the OPUk signal).
This point will be the “end of the line’ for the OPUk frame and overhead.
This circuitry will send the client data down-stream for further processing (either by non-OTN system-side circuitry, such as a MAC or to other PTE circuitry to handle the lower speed ODUj signals).
Examples of PTE
- Line Cards or Transceivers that take (for instance) 100GBASE-R data from a MAC and transports this data over an OTU4 connection (and vice-versa).
- Any equipment that performs ODUj switching and grooming
Some Final Comments about the ODUk-PMOH and PTE Equipment.
In this post, we discussed and introduced the concept of a Path, Path Terminating Equipment (PTE), and the ODUk-PMOH (Path Monitoring Overhead).
In another post, I discuss and describe the Section, Section Terminating Equipment (STE), and the OTUk-SMOH (Section Monitoring Overhead).
STEs will use the OTUk-Layer to manage the data transmission across Sections.
STEs will only generate and process OTUk-SMOH data. They do not process ODUk-PMOH data AT ALL.
Likewise, PTEs will use the ODUk-Layer to manage data transmission across a Path.
PTEs will only generate and process ODUk-PMOH data. They do not process OTUk-SMOH data AT ALL. In fact, in most cases, the PTE will not even see the OTUk-SMOH data.
Stuck at Home? You Can be an Expert on OTN Before You Return to Your Office!! Click on the Banner Below to Learn More!!!
Discounts Available for a Short Time!!
For More Information on OTN Posts in this Blog, click on the Image below
OTN Related Topics within this Blog General Topics Consequent Equations - What are they and How can you use them? ...Read More