g our examination of STS-1 overhead bytes, we will consider path overhead bytes. Those bytes are primarily designed to convey information for the payload user, which is normally a communications carrier but could be an organization that installs a SONET facility within a campus or industrial complex. As noted in Fig- ure 6.7, there are 9 bytes in an STS-1 path overhead signal. The first byte, which is labeled J1, represents an STS path trace byte. This byte conveys a repetitively transmitted string, which enables a receiving terminal to verify that it is connected to the transmitting terminal. The second path overhead byte is labeled B3. This byte provides a mechanism for path-level performance monitoring To do SO, the B3 byte contains a path BIP code. The B3 byte is followed by the C2 byte. This byte indicates the type of payload or content of the STS SPE and is referred to as the STS path signal label byte. The fourth path overhead byte is labeled H4. This byte functions as a multiframe indicator and is meaningful for certain pay- loads. The fifth byte, which is labeled G1, is a path status byte. The func- tion of this byte is to convey path error reporting back to the original path terminating equipment. The last three path overhead bytes are reserved for future use. As indicated in Figure 6.7, these bytes are labeled Z1 through Z3. Now that we have a general idea of the function of the three types of overhead bytes in an STS-1 frame, we will literally move up the SONET hierarchy and examine how higher SONET signals are Chapter Six created. Thus, let's study the format of an STS-N frame, where "N" refers to a multiplier of the 810 bytes of a basic STS-1 frame. THE STS-N FRAME The STS-N frame represents a specific sequence of N X 810 bytes formed by byte interleaving N STS-1 frames. Although the transport overhead bytes are aligned for each STS-1 frame before interleaving is performed, the associated SPEs do not have to be aligned. The rationale for this is the fact that the SPEs can float within an STS-1 frame