In an earlier blog post, I showed a simple drawing of an STS-1 Frame.  In this drawing, I show the SOH (Section Overhead) and the LOH (Line Overhead).  I show this simple drawing again below in Figure 1.

Figure 1, Simplified Drawing of the STS-1 Frame. 

I have also briefly defined and discussed these byte fields in other posts. 

This blog post will briefly discuss the STS-1 Envelope Capacity and the Synchronous Payload Envelope. 

In Figure 1, you clearly see the Envelope Capacity within the STS-1 Frame.  It is clearly marked and takes up much of the STS-1 Frame. 

Where is the Synchronous Payload Envelope (SPE)?

Figure 1 also shows the SPE, but you don’t see it labeled in the Figure. 

What is the Purpose of the Envelope Capacity within the STS-1 Frame?

The purpose of the Envelope Capacity is to transport the client (or user) data. 

What is the Purpose of the SPE within the STS-1 Frame?

The purpose of the SPE is to transport the client (or user) data. 

So, the Envelope Capacity and the SPE have the exact same purpose.

Where is the SPE?

So, Where is the SPE?

The SPE and the Envelope Capacity are (sort of) one and the same.  The SPE has the same role/function as the Envelope Capacity. 

Further, the SPE is located within the Envelope Capacity.  And you can argue that the Envelope Capacity is located within the SPE. 

Location of the Envelope Capacity (within the STS-1 Frame)

The Envelope Capacity begins with the byte just to the right of the C1/J0 Byte (within the SOH).  I show the location of the first byte within the Envelope Capacity in Figure 2.

Figure 2, Illustration of the Very First Byte within the Envelope Capacity

Figure 2 also shows that Byte 1 (the 2nd byte within the Envelope Capacity) is located just to the right of Byte 1, and so on. 

I show the Byte Numbering scheme for the Envelope Capacity below in Figure 3.

Figure 3, Byte-Numbering Scheme within the Envelope Capacity, within an STS-1 Frame (from Bytes 0 to Byte 782).

So, Where is the SPE?

The SPE is located in the exact same space as the Envelope Capacity.  However, its Byte Numbering Scheme is different. 

I show a drawing of the SPE below in Figure 4.

Figure 4, The SPE (Synchronous Payload Envelope)

Figure 4 shows the SPE (e.g., the Payload or User Data) along with the Nine Path Overhead (POH) bytes located in the left-most column (of the SPE).  This figure also shows that the STS-1 SPE is a 9 Row x 87 Byte Column Structure (the same size as the Envelope Capacity).

I discuss the role/function of the Path Overhead (or POH) bytes in another blog post. 

Figure 4 also shows that the very first byte of the SPE is the J1 byte (located in the upper left-hand corner of the SPE).  

What is the Byte-Numbering Scheme of the SPE within an STS-1 Frame

So, What is the Byte-Numbering Scheme of the SPE within an STS-1 Frame

The Byte-Numbering scheme differs for the STS-1 SPE from what we showed for the Envelope Capacity. 

In the case of the Envelope Capacity, Byte 0 is located just to the right of the C1/J0 byte (within the SOH), as I stated earlier.  Further, Byte 0 (within the Envelope Capacity is always in that same location (just East of the C1/J0 byte). 

In the case of the SPE, Byte 0 (e.g., the J1 byte) is located wherever the Pointer Bytes (H1 and H2) say that it is.  The H1 and H2 bytes permit the SONET Receiver to locate the SPE within the STS-1 frame.

The main difference between the SPE and the Envelope Capacity is that the location of the Envelope Capacity is fixed (Byte 0 is always located just East of the C1/J0 Byte). 

In the case of the SPE, Byte 0 (the J1 byte within the POH) can “float” anywhere within the Envelope Capacity. 

The Envelope Capacity and the SPE have the same roles and are of the same size (e.g., 783 bytes).  However, the location of the Envelope Capacity is fixed and aligned with the SOH and LOH bytes within the STS-1 Frame. 

The location of the SPE is not fixed (with respect to the SOH and LOH bytes) and can float. This means that the SPE can begin within any of the 783 bytes within the Envelope Capacity. 

I discuss the roles of the H1, H2, and H3 bytes and the location of the SPE (within the Envelope Capacity) in another blog post. 

However, in Figures 5, 6, 7, and 8, I show a couple of possible locations of the SPE (within the Envelope Capacity).

Figure 5, Illustration of the SPE, located at Byte 0 (just to the right of the H3 byte) – STS-1 Frame N.

Figure 6, Illustration of the SPE (again located at Byte 0) – STS-1 Frame N+1.

In Figures 5 and 6, I also show that the pointer’s value (within the H1 and H2 bytes) is 0.  In this case, the SPE begins at Byte 0 (the Byte just to the right of the H3 byte).

Please note that the SPE will often straddle across two consecutive STS-1 frames. Figure 5 shows the location of the SPE within STS-1 Frame N. Further, Figure 6 shows the location of the same SPE within the next frame (STS-1 Frame N+1).

Figure 7, Illustration of the SPE, located at Byte 522 (just to the right of the C1/J0 byte). 

In Figure 7, I show that the value of the H1 and H2 bytes are 522 (0x020A).  In this case, the SPE happens to be (accidentally) aligned with the SOH and LOF of the STS-1 Frame and located just to the right of the C1/J0 byte.

What Do the Pointer Values (within the H1 and H2 Bytes) Mean?

Finally, I show the Byte Numbering Scheme for SPEs in Figure 8.

Figure 8, What the Values of the H1 and H2 Bytes Mean – for the location of the J1 Byte within the SPE. 

In other words, Figure 8 presents the relationship between the value of the Pointers (within the H1 and H2 byte) and the location of the J1 Byte (within the SPE) within the STS-1 Frame.

Figure 8 shows that a Pointer Value of 0 corresponds with the STS-1 SPE starting at the byte, just to the right of the H3 Byte. I show an example of an SPE at this location in Figures 5 and 6.

This same figure also shows that a Pointer Value of 522 corresponds with the STS-1 SPE starting at the byte, just to the right of the C1/J0 byte. I show an example of an SPE at this location in Figure 7.

Why Don’t We Fix the Location of the SPE within the STS-1 Frame?

One important difference that the SPE has (from that of the Envelope Capacity) is that the location of the SPE can move from time to time. We refer to events (in which the SPE changes its location within the STS-1 Frame) as Pointer Adjustment events.

Whenever these Pointer Adjustment events occur, the values within the Pointer Bytes (e.g., the H1 and H2 bytes) will change. The SONET Network uses pointer adjustment to accommodate timing differences throughout the network.

I will discuss the H1, H2, H3 bytes, and Pointer Adjustments in another blog post.

The Line Layer

The Line Layer is the second highest layer within the SONET Reference Model.

The purpose of the Line Layer is to support the transmission of data between the Source and Sink Terminal of a given STS-N signal. 

Figure 1 presents an illustration of some STS-1 and STS-3 circuitry that helps to define the Line.

Figure 1, Definition of an STS-N Line

In Figure 1, I show that an STS-3 Line Signal begins and ends at the STS-1 to the STS-3 MUX/DeMUX block (which originates and terminates the STS-3 signal).

What is an LTE – Line Terminating Equipment

Any piece of equipment that manages the transmission and reception of an STS-N data stream, from the point that we create this signal to the point where we terminate this signal.

An LTE will manage the transmission and reception of STS-N data via the Line Overhead (LOH) bytes.

The LOH bytes reside in (and are a subset of) what we often refer to as the “Transport Overhead” (TOH) bytes. Figure 2 illustrates the Line Overhead Bytes within an STS-1 Signal.

Figure 2, Illustration of the Line Overhead Bytes within an STS-1 Signal.

All LTEs are also STEs

Therefore, all LTEs will manage the transmission and reception of STS-N data via both the “SOH” and “LOH” bytes. 

We briefly define the SOH bytes (within an STS-1 frame) in another blog post.

Description of the Line Overhead (LOH) Bytes

H1 and H2 Pointer Bytes

Figure 3 highlights the location of the H1 and H2 bytes within the LOH.

Figure 3, The Location of the H1 and H2 bytes within the LOH

The contents of the H1 and H2 bytes are used to indicate the offset between the location of these bytes and the first byte within the STS-1 Synchronous Payload Envelope (SPE).

An STS-1 Transmitter will compute a 10-bit pointer value and will insert this data into the H1 and H2 bytes within a given “outbound” STS-1 frame. 

An STS-1 Receiver will use this 10-bit pointer to locate the SPE within the incoming STS-1 data stream.

I present a more detailed discussion of the H1 and H2 bytes in another blog post.

H3 Pointer Action Byte

Figure 4 highlights the location of the H3 byte within the LOH.

Figure 4, The Location of the H3 byte within the LOH.

We typically use the H3 byte for “Frequency” or “Pointer Justification” purposes.

I present a more detailed discussion of the H3 byte in another blog post.

The B2 Byte

Figure 5 presents the location of the B2 byte within the LOH.

Figure 5, The Location of the B2 Byte within the LOH.

The Role of the Transmit STS-1 Terminal

A Transmitting STS-1 Terminal will computer the contents of the B2 byte by performing a BIP-8 calculation over all bits within the LOH and the Envelope Capacity within a given “outbound” STS-1 frame (after scrambling). 

This byte value is inserted into the B2 Byte field (within the very next outbound STS-1 frame) before scrambling (of the current STS-1 frame).

The Role of the Receive STS-1 Terminal

• As a Receiving STS-1 Terminal receives the LOH and the Envelope Capacity data (within a given STS-1 frame), it will compute its own BIP-8 value. 
• Afterwards, the Receive STS-1 Terminal will compare the value of its “locally” computed BIP-8 value with the value residing within the B2 byte-field of the very next STS-1 frame.
• If the two values are the same, then the Receive STS-1 Terminal will “conclude” that it has received the LOH and Envelope Capacity data in an un-erred manner.
• If the two values are different, then the Receive STS-1 Terminal will “conclude” that it received the LOH and Envelope Capacity in an erred manner. 
• We will discuss how SONET STEs should flag the occurrence of B2 byte errors in a future blog post.

NOTES:

1. The B2 byte (in SONET) is analogous to the Section BIP within an OTU Frame. 
2. We will discuss how the Transmit STS-1 Terminal computes the B2 byte and how the Receive STS-1 Terminal verifies the B2 byte in another blog post. 

The K1 and K2 (Automatic Protection Switching) Bytes

Figure 6 highlights the location of the K1 and K2 bytes within the LOH.

Figure 6, The Location of the K1 and K2 Bytes within the LOH.

The SONET Protocol uses the K1 and K2 bytes for the following purposes:

• To transport the APS signaling protocol (Used in BLSR and Linear APS schemes).
• A given LTE will use the K1 and K2 bytes to detect/clear the following defect conditions within a SONET signal.
  • AIS-L (Line AIS) Defect
  • RDI-L (Line – Remote Defect Inidicator).

We will discuss the APS Protocol in another blog post. 

We will also discuss how the SONET Terminal transmits and declares the AIS-L and RDI-L defect conditions in another post. 

The Line Data Communication Channel (D4 through D12) Bytes

Figure 7 highlights the location of the Line Data Communication Channel Bytes within the LOH

Figure 7, The Location of the Line DCC (Data Communication Channel) Bytes – D4 through D12 within the LOH

The D4 through D12 bytes are located in the first STS-1 of an STS-N and are considered as one 576kbps message-based channel for alarms, maintenance, control, monitoring and administering, and other communication needs. 

This channel is available for internally generated, externally generated, and supplier-specific messages.

I will discuss what I mean by the expression: “the first STS-1 of an STS-N” in another blog post. 

The S1 – Synchronization Status Byte

Figure 8 presents the location of the S1 Byte within the LOH.

Figure 8, Illustration of the LOH with the S1 Byte Highlighted

We use this byte to transport the Synchronization Status Message (SSM). 

I will discuss how we use the S1 byte in another blog post.

The M0 Byte – STS REI-L (Remote Error Indicator – Line)

Figure 9 presents the location of the M0 Byte within the LOH.

Figure 9, Location of the M0 Byte within the LOH.

The purpose of the M0 byte is to transmit the REI-L (Line – Remote Error Indicator) to a remote LTE. 

REI-L conveys the error count detected by the LTE (within the B2 byte) back to its peer LTE.

We will discuss the REI-L indicator and how we use it in another blog post. 

E2 Byte – Undefined

Figure 10 presents the location of the E2 byte within the LOH.

Figure 10, Location of the E2 Byte within the LOH.

The Section Layer and the Section Overhead (SOH) Bytes

The Section Layer involves transporting an STS-N data stream across the physical medium (e.g., copper or optical fiber) in a point-to-point manner (e.g., between any two adjacent pieces of equipment). 

The purpose of the Section Layer is to ensure that the STS-N data stream, which is being transported over a given link or coaxial cable or optical fiber, is properly received. 

Functions within this layer include:

• Framing
• Scrambling
• Error detection
• Section-Level Communications Overhead, such as the local orderwire.
• Data Communication Channels (DCC) to carry information for OAM & P (Operation, Administration, Maintenance, and Performance). 

The Section Terminating Equipment (STE)

We refer to any piece of equipment that manages the transmission and reception of STS-N data over a single link of optical fiber or coaxial cable as an STE (Section Terminating Equipment).

An STE will manage the transmission and reception of STS-N data via the Section Overhead (SOH) bytes. 

The Section Overhead (SOH) Bytes

The SOH bytes reside in (and are a subset of) what we refer to as the “Transport Overhead” (TOH) bytes. 

Figure 1 illustrates the SONET Frame, with the SOH and LOH bytes field identified.

Figure 1, Another Look at the SONET Frame – SOH and LOH Bytes Highlighted.

I show and identify the Section Overhead (SOH) bytes in Figure 2 below.

Figure 2, Illustration and Identification of the Section Overhead Bytes

I will briefly describe the SOH bytes below.

The A1 and A2 (Framing Alignment) Bytes

In Figure 3, I show the location of the A1 and A2 bytes within the SOH. 

Figure 3, Location of the A1 and A2 Bytes within the Section Overhead

The A1 and A2 bytes are the Framing Alignment bytes.

These two bytes are assigned the following values:

• A1 = 0xF6, and
• A2 = 0x28

NOTE:  These values are the same as the FA1 and FA2 bytes within the OTU frame. 

A given STS-1 Transmitter will always set the A1 and A2 bytes to these specific values. 

The STS-1 Receiver (receiving this STS-1 signal) will search for and locate the “A1” and “A2” bytes to acquire and maintain STS-1 Frame Synchronization within this incoming STS-1 data stream.

A given STS-1 (receiving an STS-1 signal) will declare either of the following defect conditions based on its success in receiving the A1 and A2 bytes.

• dSEF – Severely Erred Frame
• dLOF – Loss of Frame

The STE will declare/clear the SEF and LOF Defect by using the “SEF/LOF Defect Declaration/Clearance – State Machine” diagram, which I show in Figure 4.

Figure 4, Illustration of the SEF/LOF Declaration/Clearance State Machine Diagram

NOTE: We discuss the SEF/LOF Declaration/Clearance State Machine Diagram (and how the STE declares the dSEF or dLOF defect) in another blog post.

The C1 (STS-1 ID)/J0 (Section Trace Message) Byte

In Figure 5, I show the location of the C1 within the SOH. 

Figure 5, Location of the C1/J0 Byte, within the Section Overhead

This Byte-Field serves two possible roles:

The C1 Byte (STS-1 ID)

In earlier editions of GR-253-CORE, the C1 byte was allocated to function as an “STS-1 ID” function. 

The C1 byte is no longer used for this purpose.

However, to ensure interoperability with older SONET equipment, this byte must be capable of transmitting and receiving the “STS-1 ID” number.

The J0 Byte – Section Trace Byte

The STE uses this byte to repetitively transmit a 1, 16, or 64-byte message so that the receiving STE can verify its continued connection to the intended transmitting sTS-1 STE. 

NOTE:  This is similar to the Trail Trace Identifier fields within the OTU and ODU frames. 

The B1 (Section BIP-8) Byte

In Figure 6, I present the location of the B1 byte within the STS-1 SOH.

Figure 6, Location of the B1 Byte within the STS-1 SOH.

The Role of the Transmit STS-1 Terminal

A Transmitting STS-1 Terminal will computer the contents of the B1 byte by performing a BIP-8 calculation over all bits within a given “outbound” STS-1 frame (after scrambling). 

This byte value is inserted into the B1 Byte field (within the very next outbound STS-1 frame) before scrambling (of the current STS-1 frame).

The Role of the Receive STS-1 Terminal

• As a Receiving STS-1 Terminal receives this STS-1 signal, it will compute its own BIP-8 value. 
• Afterward, the Receive STS-1 Terminal will compare its “locally” computed BIP-8 value with the value residing within the B1 byte field of the next STS-1 frame.
• If the two values are the same, then the Receive STS-1 Terminal will “conclude” that it has received this STS-1 signal in an un-erred manner.
• If the two values are different, then the Receive STS-1 Terminal will “conclude” that it received this STS-1 signal in an erred manner. 
• We will discuss how SONET STEs should check for and flag the occurrence of B1 byte errors in a future blog post.

NOTE:  The B1 byte (in SONET) is analogous to the Section BIP within an OTU Frame. 

The E1 (Orderwire) Byte

Figure 7 presents the location of the E1 byte within the STS-1 SOH.

Figure 7, Location of the E1 Byte within the STS-1 SOH.

We refer to this byte as the Section Order-Wire Byte. 

The Standard Committee allocated this byte for use as a local order wire channel for voice communication between regenerators, hubs, and remote terminal locations.

The F1 (Section User Channel) Byte

Figure 8 presents the location of the F1 byte within the STS-1 SOH.

Figure 8, Location of the F1 Byte within the STS-1 SOH.

The Standard Committee set aside the F1 byte for the user’s purposes. 

This byte is passed from STE to STE over the STS-N transmission media. 

This byte can typically be written into/read from at any STE.

Use of this byte is optional.

The D1, D2 and D3 (Section Layer – Data Communication Channel) Bytes

Figure 9 presents the location of the Section Layer Data Communication Channel (DCC) bytes within the STS-1 SOH.

Figure 9, Location of the Section Layer DCC Bytes within the STS-1 SOH.

These three bytes form a 192kbps message channel that supports transmitting OAM & P (Operation, Administration, Maintenance, and Provisioning) messages between pieces of Section Terminating Equipment.

ANSI.105.04 defines the protocols that we use in the Section Layer DCC.

Examples of STE (Section Terminating Equipment

Regenerators

Defects that occur within the Section Layer

• dLOS – Loss of Signal
• dSEF – Severely Erred Frame
• dLOF – Loss of Frame

I briefly define and describe the Line Overhead Bytes (within a SONET Signal) in another blog post.

I also describe the Envelope Capacity and Synchronous Payload Envelope (SPE) in yet another blog post.

The SONET Reference Model

In the OSI (Open System International) Reference Model, we attempted to describe and understand a communications network via a seven (7) layer model.  This model consists of the following layers.

• The Application Layer
• The Presentation Layer
• The Session Layer
• The Transport Layer
• The Network Layer
• The Data Link Layer
• The Physical Layer

In SONET, we attempt to describe and understand communication networks via a four (4) layer model (which we call the SONET Reference Model). 

In order of decreasing complexity, we have the following layers.

• The Path Layer
• The Line Layer
• The Section Layer and
• The Physical Layer

We will briefly describe each of these layers below.

In Figure 1, I show a drawing with some pieces of Optical Transmission Equipment.  I also show where each of these four SONET Layers fit in between these pieces of equipment.

Figure 1, Illustration of the SONET Layers and Some Optical Equipment

We will now briefly describe some of these layers.

The Physical Layer

In SONET, the Physical Layer deals with the transport of bits across the transmission medium. 

There are no overhead bytes associated with the Physical Layer.

The main function of this layer is in the conversion between an STS-N digital data stream and either external optical or electrical SONET signals. 

Design issues associated with this layer typically include the following parameters:

• Pulse Shape
• Power Levels
• Line Code
• Timing
• Connectivity

NOTE:  Optical Modules communicate at this layer.

The Section Layer

The Section Layer involves transporting an STS-N data stream across the physical medium (e.g., copper or optical fiber) in a point-to-point manner (e.g., between any two adjacent pieces of equipment). 

This layer aims to ensure that the STS-N data stream, transported over a given link, coaxial cable, or optical fiber, is properly received. 

Figure 2 presents a simple illustration of a Section.

Figure 2, Simple Illustration of a Section (a link between any two adjacent pieces of Equipment)

Functions within this layer include:

• Framing
• Scrambling
• Error detection
• Section-Level Communications Overhead, such as the local orderwire.
• Data Communication Channels (DCC) to carry information for OAM & P (Operation, Administration, Maintenance, and Performance). 

What is Section Terminating Equipment (STE)

We refer to any piece of equipment that manages the transmission and reception of STS-N data over a single link of optical fiber or coaxial cable as an STE (Section Terminating Equipment).

An STE will manage the transmission and reception of STS-N data via the Section Overhead (SOH) bytes. 

The SOH bytes reside in (and are a subset of) what we refer to as the “Transport Overhead” (TOH) bytes. 

Figure 3 presents another look at the SONET Frame, with the TOH bytes field identified.

Figure 3, Another Look at the SONET Frame – TOH Bytes Highlighted.

I show (once again) that the TOH can be further divided into the SOH (Section Overhead) and Line Overhead (LOH) in Figure 4 below.

Figure 4 illustration the TOH being further divided into the SOH and LOH.

More about the SOH (Section Overhead Bytes)

As I mentioned earlier, we use the SOH (Section Overhead Bytes) to manage the transport of an STS-N signal across a Section.

Figure 5 presents a simple illustration of the 9 SOH bytes

Figure 5, Illustration of the Nine (9) SOH bytes

We discuss the function/role of the SOH bytes in another blog post.

The Line Layer

The Line Layer is the second highest layer within the SONET Reference Model.

The purpose of the Line Layer is to support the transmission of data between the Source and Sink Terminal of a given STS-N signal. 

The Line Layer is different from the Section Layer in that it (the Line Layer) will involve multiple pieces of electrical or optical transmission equipment. The Line Layer begins when we create a specific STS-N signal and ends when we terminate this STS-N signal.

The Section Layer only involves two adjacent pieces of electrical or optical transmission equipment.

Figure 6 presents an illustration of some STS-1 and STS-3 circuitry that helps to define the Line.

Figure 6, Definition of an STS-N Line (or STS-3 Line)

In Figure 6, we define a “Line” as the circuitry and communication media from the point where we multiplex three STS-1 signals into an STS-3 to the point where we terminate the STS-3 signal and de-multiplex them back into the 3 STS-1 signals.

What is Line Terminating Equipment (LTE)

Any piece of equipment that manages the transmission and reception of an STS-N data-stream, from the point that we create this (STS-N) signal to the point where we terminate this (STS-N) signal.

An LTE will manage the transmission and reception of STS-N data via the Line Overhead (LOH) bytes.

The LOH bytes reside in (and are a subset of) what we often refer to as the “Transport Overhead” (TOH) bytes.

All LTEs are also STEs.

Therefore, all LTEs will manage the transmission and reception of STS-N data via both the “SOH” and “LOH” bytes. 

Figure 7 illustrates the LOH (Line Overhead) bytes within an STS-1 Frame.

Figure 7, Illustration of the LOH (Line Overhead) Bytes within an STS-1 Frame.

We discuss the function/role of the LOH (Line Overhead) bytes in another blog post.

The Path Layer

The purpose of the Path Layer is to support and manage the transport of “non-SONET” client data from the point where we map this client signal into the SONET network to the point where it exits (or is de-mapped) from the SONET network.

Examples of non-SONET data being mapped into and transported via a SONET Network are DS1, E1, DS3, ATM, Ethernet, etc.

Each STS-N SPE consists of nine (9) Path Overhead bytes.

Figure 8 illustrates the Location of the Path Layer within our drawing of Optical Equipment.

Figure 8, Location/Identification of the Path Layer, within our drawing of Optical Equipment

What is Path Terminating Equipment – PTE

Any piece of equipment that manages the transmission and reception of non-SONET data, or client signal, from the point that it enters the SONET network to the point that the SONET Network is terminated (and the client signal is de-mapped from the SONET signal) is referred to as a PTE (Path Terminating Equipment).

A PTE will manage the transmission and reception of non-SONET client data (through the SONET network) via the “Path Overhead” (POH) bytes.

The POH bytes reside within the first column in the SPE. 

Figure 9 illustrates the Synchronous Payload Envelope (SPE) with the Path Overhead (POH) Bytes.

Figure 9, Illustration of the Synchronous Payload Envelope (SPE) with the Path Overhead (POH) Bytes.

NOTE:  All PTEs are also LTEs and STEs.

Therefore, all PTEs will manage the transmission and reception of STS-N data via both the “SOH,” “LOH,” and “POH” bytes.

I discuss the function/role of the Path Overhead (POH) bytes in another blog post.

Where is the Synchronous Payload Envelope?

In each of the figures above (e.g., Figures 3, 4, 5, and 7), I do not refer to the Synchronous Payload Envelope (SPE). I only refer to the Envelope Capacity (within the SONET Frame). I discuss the relationship between the Envelope Capacity and the SPE in another blog post.