Technical Committee


2.4 Gbps Physical Layer Specification


AF-PHY-0133.000



October, 1999

(c) 1999 by The ATM Forum. This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution. Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution. All other rights reserved. Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum.

The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication.

The receipt or any use of this document or its contents does not in any way create by implication or otherwise:

•	Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor
•	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
•	Any form of relationship between any ATM Forum member companies and the recipient or user of this document.

Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM Forum.

The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.

NOTE: The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others. By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights. ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. For additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Suite 304
Mountain View, CA 94040-1313
Tel:	+1-650-949-6700
Fax:	+1-650-949-6705

Table of Contents

1.	2488.32 MBPS PHYSICAL LAYER SPECIFICATION	5
2.	PHYSICAL MEDIUM DEPENDENT (PMD) SUBLAYER	5
2.1	FIBER INTERFACE	5
2.1.1	Single Mode Fiber Interface	5
2.1.1.1	Jitter	5
2.2	TIMING REQUIREMENTS	5
3.	TRANSMISSION CONVERGENCE (TC) SUBLAYER	6
3.1	SONET/SDH OVERHEAD FUNCTIONS	6
3.2	CELLS MAPPING	7
3.3	HEC FUNCTIONS	8
3.3.1	HEC Generation	8
3.3.2	HEC Verification	8
3.3.3	Cell Delineation	9
3.4	CELL PAYLOAD SCRAMBLING	9
3.5	CELL RATE DECOUPLING	9
4.	MAINTENANCE	9
4.1	LOSS-OF-SIGNAL (LOS)	10
4.2	LOSS-OF-FRAME (LOF)	10
4.3	SECTION BIP-8 ERROR	10
4.4	LOSS-OF-POINTER (LOP)	10
4.5	LINE BIP-384 ERROR	10
4.6	LINE AIS	10
4.7	LINE REI	10
4.8	LINE RDI	11
4.9	PATH BIP-8 ERROR	11
4.10	PATH REI	11
4.11	PATH AIS	11
4.12	PATH RDI	11
4.13	LOSS-OF-CELL-DELINEATION (LCD)	11
5.	ACRONYM LIST	11
6.	REFERENCES	13
A	INTRODUCTION TO APPENDIX A	14
A.1	SECTION OVERHEAD	14
A.1.1	Framing Bytes: A1, A2	14
A.1.2	Section BIP-8 Byte: B1	14
A.1.3	Section Trace Byte: J0	14
A.1.4	Section Growth: Z0	14
A.1.5	Section Data Communication Channel: D1-D3	15
A.1.6	Orderwire: E1	15
A.1.7	Section User Channel: F1	15
A.2	LINE OVERHEAD	15
A.2.1	Line BIP-8: B2	15
A.2.2	Pointer: H1, H2	15
A.2.3	Pointer Action Byte: H3	16
A.2.4	APS Channel: K1, K2	16
A.2.5	AIS-L and RDI-L: K2 bits 6-8	16
A.2.6	Synchronization Messaging: S1	16
A.2.7	STS-N line REI: M1	16
A.2.8	AIS-P: H1, H2	16
A.2.9	Line Data Communication Channel: D4-D12	16
A.2.10	Orderwire: E2	17
A.2.11	Growth: Z1	17
A.2.12	Growth: Z2	17
A.3	PATH OVERHEAD	17
A.3.1	STS Path Trace: J1	17
A.3.2	Path BIP-8: B3	18
A.3.3	STS Path Signal Label: C2	18
A.3.4	Path Status: G1	18
A.3.5	Tandem Connection: N1	18
A.3.6	Multiframe Indicator: H4	18
A.3.7	Path User Channel: F2	19
A.3.8	F3, K3	19


List of Figures

Figure 3-1: SONET/SDH Frame Structure for 2488.32 Mbps	6
Figure 3-2: ATM Cells Mapping in STS-48c SPE or VC-4-16c	8


List of Tables

Table 3-1: SONET/SDH Overhead Functions	7
Table 3-2: Header Pattern for Idle Cell Identification	9

1. 2488.32 Mbps Physical Layer Specification
The 2488.32 Mbps physical layer specification is based on the Synchronous Optical Network (SONET) and the Synchronous Digital Hierarchy (SDH) standards. These standards provide, through a framing structure, the payload envelope necessary for the transport of ATM cells as well as overhead bytes for the carriage of OAM information. The SONET/SDH OAM functions residing in the physical layer management (M-plane) are covered in section 4. The functions of the physical layer (U-plane) are grouped into the physical media dependent (PMD) sublayer (covered in section 2) and the transmission convergence (TC) sublayer (covered in section 3).
This specification shall apply for 2488.32 Mbps interfaces at the public UNI, the private UNI and the private NNI.
2. Physical Medium Dependent (PMD) Sublayer
2.1 Fiber Interface
Currently, six fiber-based PMDs are defined for the 2488.32 Mbps interface. Other PMD types are for further study.
2.1.1 Single Mode Fiber Interface
Recommendation G.957 [1] defines six single mode fiber interfaces at 2488.32 Mbps for different network applications. They are 
* one short-reach interface (2 km target distance, 0-7 dB span loss, 1310 nm region on single mode fiber);
* two intermediate reach interfaces (15 km target distance, 0-12 dB span loss, 1310 or 1550 nm region on single mode fiber);
* three long reach interfaces (40-80 km target distance, 10-24 dB span loss, 1310/1550 nm region on single mode fiber, 1550 nm region on dispersion shifted single mode fiber).
(R) For single mode interfaces, refer to [1] for applicable specifications. (Note: There are six interface specifications defined for different reach applications.)
2.1.1.1 Jitter
Refer to Recommendation G.958 [2] for the following jitter performance parameters for a 2488.32 Mbps interface: jitter generation, jitter transfer (for regenerators only), and jitter tolerance.
2.2  Timing Requirements
The bit rate for this interface shall be 2488.32 Mbps. Refer to Recommendation G.813 [3] Sections 5 and 6 for the frequency accuracy, pull-in, hold-in, and pull-out ranges for this interface. This Recommendation outlines minimum requirements for timing devices used in synchronizing network equipment that operate according to the principles governed by the Synchronous Digital Hierarchy (SDH). ANSI T1.105.09-1996 [4] provides timing and synchronization specifications for SONET interfaces.
3. Transmission Convergence (TC) Sublayer
A SONET/SDH based TC is specified for the 2488.32 Mbps interface. The SONET STS-48c as specified in ANSI T1.105-1995 [5] and SDH VC-4-16c as specified in Recommendation G.707 [6] frame formats are used to transport ATM cells. These two frame formats (SONET and SDH) are largely identical except for the usage of certain overhead bytes. These differences are summarized in Section 3.1.

Mapping of ATM cells into the SONET/SDH frame is accomplished by scrambling the ATM cell payload and placing the resulting cell stream into a synchronous payload envelope (SPE) or equivalently a VC-4-16c, aligning the SPE into the SONET/SDH frame using the H1-H2 pointer, and finally applying the SONET/SDH frame synchronous scrambler to the resulting frame. The following provides high level description on how to build STM-16 frame with ATM cells in SDH terminology: ATM cells scrambled ® map to VC-4-16c ® add VC-4-16c Path Overhead ® add H1-H2 pointers ® add Section Overhead ® Frame synchronous scrambler). Figure 3-1 shows the frame structure for mapping ATM Cells into the SONET STS-48c SPE or equivalently the SDH VC-4-16c.

ATM cell extraction operates in the analogous reverse procedure, i.e. by descrambling the SONET/SDH frame, reading the H1-H2 pointer to locate the SPE, performing cell delineation, and finally descrambling the ATM cell payload.


Figure 3-1: SONET/SDH Frame Structure for 2488.32 Mbps
3.1 SONET/SDH Overhead Functions
Table 3-1 summarizes the status for the overhead functions for the OC-48/STM-16 interface.
Table 3-1: SONET/SDH Overhead Functions
Overhead
Status
A1, A2
R
B1
R
D1, D2, D3
O
J0 
O
Z0
N/A
E1
O
F1
O
B2
R
D4 - D12
O
E2
O
H1, H2, H3
R
K1, K2 (APS)
O
K2 (6-8) AIS-L
R
K2 (6-8) RDI-L
R
S1 (sync msg)
R
M1 Line REI
R
H1, H2 (AIS-P)
R
Z1, Z2
N/A
J1
R
B3
R
C2
R
G1
R
H4
N/A
F2
O
N1
O
F3, K3
N/A

The support of certain overhead bytes is required (R), optional (O), or not applicable (N/A) at the OC-48/STM-16 interface as shown in the status column of Table 3-1.

(R) The required and optional overhead bytes (i.e., R and O) identified in Table 3-1 shall be implemented as specified in references [5,6]. For more information regarding Automatic Protection Switching (APS), refer to ANSI T1.105.01-1995 [7].

Unassigned overhead bytes (i.e., N/A) identified in Table 3-1 are not defined and are beyond the scope of this specification. Even though these bytes are beyond the scope of this specification, there may be applications in which the use of these bytes may be beneficial. For definition of these bytes refer to references [5,6].

Refer to Appendix A for more information on the required and optional overhead functions identified in Table 3-1.
3.2 Cells Mapping
ATM cell mapping is performed by aligning by row, the byte structure of every cell with the byte structure of the SPE. The bit rate available for user information cells, signaling cells and OAM cells (excluding unassigned bytes and physical layer related maintenance information transported in SONET/SDH overhead bytes) is nominally 2396.16 Mbps (refer to "ATM Cells " depicted in Figure 3-2.
(R) ATM cells shall be mapped into the STS-48c SPE, or equivalently the VC-4-16c, in accordance with ANSI T1.105.02 [8 ] and [6].

Figure 3-2: ATM Cells Mapping in STS-48c SPE or VC-4-16c
3.3 HEC Functions
The entire cell header is protected by the Header Error Control (HEC) sequence. This sequence is used by the receiver to determine cell boundaries (cell delineation), and to provide header error detection and error correction functionality.
3.3.1 HEC Generation
(R) The HEC byte shall be generated as specified in Recommendation I.432 [9], including the recommended modulo 2 addition (XOR) of the pattern 01010101 to the HEC bits.
3.3.2 HEC Verification
(R) HEC sequence error detection shall be performed as specified in [9].
(O) In addition to HEC error detection, single bit HEC error correction may also be implemented. In this case, the two modes of operation shall interact as specified in [9].
3.3.3 Cell Delineation
(R) Cell delineation shall be performed in accordance with the HEC-based algorithm specified in [9].
3.4 Cell Payload Scrambling
Cell payload scrambling permits the randomization of the cell payload to avoid continuous non-variable bit patterns and improves the efficiency of the cell delineation algorithm.
(R) The self synchronizing scrambler polynomial (X43 + 1) shall be used to scramble and descramble the cell payloads in accordance with the procedure defined in [9].
3.5 Cell Rate Decoupling
(R) The physical layer shall adapt the cell rate arriving from the ATM layer to the payload capacity of the SPE by inserting idle cells when assigned cells are not available from the ATM layer. 
Idle cells are identified by the cell header pattern shown in Table 2. The cell payload content of an idle cell is "01101010" repeated 48 times. Note, however, that cell rate decoupling may be performed at the ATM layer, in which case "unassigned" cells are used and not idle cells. See ANSI T1.627 [10] for further information regarding unassigned and assigned cells. The idle cell as defined in this document is identified as having an "invalid" cell header pattern in [10]. When used for cell rate decoupling, however, the idle cells are not passed to the ATM layer and are, therefore, not detected as invalid.
Table 3-2: Header Pattern for Idle Cell Identification

Octet 1
Octet 2
Octet 3
Octet 4
Octet 5
Header Pattern
00000000
00000000
00000000
00000001
Correct HEC
4. Maintenance
Physical layer maintenance is accomplished by monitoring the SONET signal for failures and degradation of service. Maintenance activities are based on indications of Near-End (NE) events occurring on the received signal path, and Far-End (FE) reports of the transmitted signal status. Physical layer status is reported, by network elements, to the management layer, in terms of anomalies, defects and failures. Network operators' use the management layer status indications for failure isolation and network performance monitoring.

SONET/SDH interfaces terminate at three hierarchical levels: Section, Line, and Path. Failure and performance reports are generated independently for each of the hierarchical levels.

Error detection and far end reporting functions are performed by equipment contained within network elements, and are made possible by protocols and maintenance tools built into the overhead fields of the framing structure. Further information can be found in ANSI T1.231-1993 [11] and ITU G.783 [12].

(R) Performance monitoring functionality shall be as specified in [11] and [12].

(R) Failure alarm monitoring functionality shall be as specified in [115] and [12].

The required performance monitoring and failure alarm monitoring functionality is specified in sections 4.1 - 4.13.
4.1 Loss-Of-Signal (LOS)
(R) Equipment shall detect and report to layer management the LOS defect as specified in [11] and [12].
4.2 Loss-Of-Frame (LOF)
(R) Equipment shall detect and report to layer management the LOF defect as specified in [11] and [12].
4.3 Section BIP-8 Error
(R) Equipment shall monitor and report to layer management section BIP-8 error counts.
4.4 Loss-Of-Pointer (LOP)
(R) Equipment shall detect and report to layer management the LOP defect as specified in [11] and [12].
4.5 Line BIP-384 Error 
(R) Equipment shall monitor and report to layer management line BIP-384 error count as specified in [11] and [12].
4.6 Line AIS
(R) Equipment shall detect and report to layer management the line AIS defect as specified in [11] and [12].
4.7 Line REI 
(R) Equipment shall monitor and report to layer management line REI counts as specified in [11] and [12].
4.8 Line RDI
(R) Equipment shall detect and report to layer management the line RDI defect as specified in [11] and [12].
4.9 Path BIP-8 Error
(R) Equipment shall monitor and report to layer management path BIP-8 errors as specified in [11] and [12].
4.10 Path REI
(R) Equipment shall monitor and report to layer management path REI error counts as specified in [11] and [12].
4.11 Path AIS
(R) Equipment shall detect and report to layer management the Path AIS defects as specified in [11] and [12].
4.12 Path RDI
(R) Equipment shall detect and report to layer management Path RDI defects as specified in [11] and [12].
4.13 Loss-Of-Cell-Delineation (LCD)
(R) Equipment shall detect the LCD defect.
5. Acronym List
AIS	Alarm Indication Signal
APS	Automatic Protection Switching
ATM	Asynchronous Transfer Mode
BIP	Bit Interleaved Parity
HEC	Header Error Check
LCD	Loss of Cell Deliniation
LOF	Loss of Frame
LOP	Loss of Pointer
LOS	Loss of Signal
NNI	Network Node Interface
OAM	Operation, Administration, Maintenance
OC-48	Optical Carrier Level 48
PDI	Payload Defect Indicator
PMD	Physical Media Dependent
RDI	Remote Defect Indicator
REI	Remote Error Indication
SDH	Synchronous Digital Hierarchy
SONET	Synchronous Optical NETwork
SPE	Synchronous Payload Envelope
STM-16	Synchronous Transport Module Level 16
STS-48c	Concatenated Synchronous Transport Signal Level 48
TC	Transmission Convergence
UNI	User to Network Interface
VC-4-16c	Concatenated Virtual Container - 4 Level 16


6. References
Appendix A
A Introduction to Appendix A
This annex provides more information on the purpose and function of the overhead bytes identified in Table 3-1. For overhead functions where there are known differences in the implementation between SONET and SDH, these differences are stated below. Not all differences may be stated. Not all information is provided on the overhead bytes. Refer to references [5,6] for more information on these bytes. Each alpha-numeric combination identify a specific function and represent 8 bits in the overhead (e.g., A1 and A2 are two framing bytes). The description of overhead is based on SONET and, as such, it makes use of SONET terms.
A.1 Section Overhead
A.1.1 Framing Bytes: A1, A2
The A1 byte shall be set to "11110110" and the A2 byte shall be set to ""00101000" in all STS-1s in STS-48c. 
A.1.2 Section BIP-8 Byte: B1
One byte is allocated for a Section error monitoring function. This function shall be a bit interleaved parity 8 code using even parity. The Section BIP-8 is calculated over all bits of the previous STS-N frame after scrambling. The computed BIP-8 is placed in the B1 byte of STS-1 number 1 before scrambling. This byte is defined only for STS-1 number 1 of an STS-N signal.
A.1.3 Section Trace Byte: J0
One byte is allocated to be used for a section trace function. This byte is defined only for STS-1 number 1 of an STS-N signal. This byte, J0 (formerly C1 of STS-1 number 1) is used to repetitively transmit a one byte fixed length string so that a receiving terminal in a section can verify its continued connection to the intended transmitter. The content of this message is not to be constrained by this standard since it is assumed to be user programmable at both the transmit and receive ends. This will provide up to 256 possible values for section trace. When the Section Trace function is not supported or if no value has been programmed, then 01 Hex shall be transmitted. SDH also uses this byte as Section Trace, but prefers a 16 byte trace message. (Note: Some standards groups are considering specifying a 64 byte trace message.)
A.1.4 Section Growth: Z0
One byte is defined in each STS-1 for future growth except for STS-1 number 1 (which is defined as J0). For interworking with older equipment at rates at or below STS-48, the Z0 bytes (formerly C1 timeslots 2 through N) shall be capable of being set consistent with the previous STS-1 ID definition (C1). i.e. For STS-3c place code "00000010" in first Z0 and place code "00000011" in second Z0.
A.1.5 Section Data Communication Channel: D1-D3
Three bytes are allocated for Section data communication and should be considered one 192-kbit/s message-based channel for alarms, maintenance, control, monitor, administration, and other communication needs between Section Terminating Equipment. This channel is available for internally generated, externally generated, and manufacturer-specific messages. These bytes are defined only for STS-1 number 1 of an STS-N signal. SDH uses these bytes for the same purpose.
A.1.6 Orderwire: E1
One byte is allocated to be used as a local orderwire channel that shall be used as a voice communication channel. It is reserved for communication between Section Terminating Equipments, hubs, and remote terminal locations and it is only defined for STS-1 number 1 of an STS-N signal. Signaling on the E1 byte is for further study. The use of this function is optional. SDH uses this byte for the same purpose.
A.1.7 Section User Channel: F1
One byte is set aside for the user's purposes. This byte shall be passed from Section to Section within a Line and shall be readable, writable, or both at each Section Terminating Equipment in that line. The use of this function is optional. The F1 byte is defined only for STS-1 number 1 of an STS-N signal. SDH uses this byte for the same purpose.
A.2 Line Overhead
A.2.1 Line BIP-8: B2
One byte is allocated in each STS-1 for a line error monitoring function. This function shall be a bit-interleaved parity-8 code using even parity. The Line BIP-8 is calculated over all bits of the Line Overhead and STS-1 Envelope Capacity of the previous STS-1 frame before scrambling. The computed BIP-8 is placed in the B2 byte of the STS-1 before scrambling. This byte shall be provided in all STS-1 signals within an STS-N signal. The N Line BIP-8 bytes in an STS-N signal are intended to form a single-error monitoring facility capable of measuring error rates up to 10-3 independent of the value of N. The parity errors detected by the N BIP-8 detectors, or equivalently the single BIP-8N detector, should be accumulated into a single-error count for the STS-N line. 
A.2.2 Pointer: H1, H2
Two bytes per STS-1 are allocated to a pointer that indicates the offset in bytes between the pointer action byte (H3) and the first byte of the STS SPE. It shall be used to align the STS-1 Transport Overheads in an STS-N signal as well as perform frequency justification. Refer to reference [4] for pointer operation. SDH calls bytes H1, H2 and H3 the AU-4 Pointer. The bits 5-6 (ss bits) are set differently for SDH.
A.2.3 Pointer Action Byte: H3
The pointer action byte is allocated for frequency justification purposes. Depending on the pointer value, this byte is used to adjust the fill of input buffers. In the event of a negative justification, it carries valid information. This byte shall be provided in all STS-1 signals within an STS-N signal. The value contained in this byte when not used to carry valid payload information is not defined and shall be ignored by a receiver.
A.2.4 APS Channel: K1, K2
Two bytes are allocated for Automatic Protection Switching (APS) signaling between Line level entities. These bytes are defined only for STS-1 # 1 of an STS-N signal. For more information regarding Automatic Protection Switching, refer to [7].
A.2.5 AIS-L and RDI-L: K2 bits 6-8
Line AIS (AIS-L) and Remote Line Defect Indication (RDI-L) shall be supported.
A.2.6 Synchronization Messaging: S1
One byte is allocated for transporting synchronization status messages. This byte is defined only for STS-1 number 1 of an STS-N signal. Currently only bits 5-8 of Byte S1 are used to transport synchronization status messages. These messages provide an indication of the quality level of the synchronization source of the SONET signal. Bits 1-4 of Byte S1 are reserved for future use. 
A.2.7 STS-N line REI: M1
In a SONET signal at rates at or above STS-3, one byte, the M1 byte, is allocated for a line REI function. (This byte was previously called the third Z2 byte.) The entire M1 byte is used to convey the count of errors detected by the Line BIP-8 (B2) bytes. This count has (8 Times N) + 1 legal values, namely 0 to 8N errors.
A.2.8 AIS-P: H1, H2
Path AIS (AIS-P) shall be generated by an LTE upon detection of an LOS, LOF, AIS-L or LOP-P defect. AIS-P shall be removed when the LTE detects termination of the defect. AIS-P is specified as all 1s in the STS SPE as well as the H1, H2, and H3 bytes. STS Pointer Processors detect AIS-P as all 1s in bytes H1 and H2 in three consecutive frames. Removal of AIS-P is detected as a valid STS Pointer and 0110 new data flag in three consecutive frames.
A.2.9 Line Data Communication Channel: D4-D12
Nine bytes are allocated for Line data communication and should be considered as one 576-kbit/s message-based channel for alarms, maintenance, control, monitor, administration, and other communication needs between Line-terminating entities. This is available for internally generated, externally generated, and manufacturer-specific messages. These bytes are defined only for STS-1 number 1 of an STS-N signal. SDH uses these bytes for the same purpose.
A.2.10 Orderwire: E2
One byte is allocated in this layer for an express orderwire between Line entities. This byte is defined only for STS-1 number 1 of an STS-N signal and its use is optional. Signaling on the E2 byte is for further study. SDH uses this byte for the same purpose.
A.2.11 Growth: Z1
In SONET signals at rates above STS-1 and below STS-192, one Z1 byte is defined in each STS-1 except STS-1 number 1 for future growth.  (In STS-1 number 1, this byte is defined as S1.)  For an OC-192 signal, Z1 bytes are defined for STS-1 numbers 2 through 48, and the corresponding byte locations in STS-1 numbers 49 through 192 are undefined.  (STS-1 numbers 2 through 48 are the second through 16th, 65th through 80th, and the 129th through 144th STS-1s in order of appearance in the byte interleaved STS-192 frame.)  The receiver is required to ignore the value contained in these bytes. SDH uses this byte for growth.
A.2.12 Growth: Z2
In SONET signals at rates above STS-1 and below STS-192, one Z2 byte is defined in each STS-1 except the third STS-1 for future growth.  (In the third STS-1, this byte location is defined as M1.)  For an OC-192 signal, Z2 bytes are defined for STS-1 numbers 1 through 6 and 8 through 48, and the corresponding byte locations in STS-1 numbers 49 through 192 are undefined.  (STS-1 numbers 1 through 6 and 8 through 48 are the first, second, fourth through 16th, 65th through 80th, and 129th through 144th STS-1s in order of appearance in the byte interleaved STS-192 frame.)  The receiver is required to ignore the value contained in these bytes. SDH uses this byte for growth.
A.3 Path Overhead
A.3.1 STS Path Trace: J1
This byte is used to repetitively transmit a 64-byte, fixed-length string so that a receiving terminal in a path can verify its continued connection to the intended transmitter. The content of the message is not constrained by T1.105, since it is assumed to be user programmable at both the transmit and receive ends. However, it is suggested that a 8-bit ASCII string, padded with NULL characters and terminated with CR/LF, would be a suitable 64 byte trace message. If no message has been loaded, then 64 NULL characters (Hex 00) shall be transmitted. SDH uses this byte for an access point identifier and prefers a 16 byte string.
A.3.2 Path BIP-8: B3
One byte is allocated for a path error monitoring function. This function shall be a bit-interleaved parity-8 code using even parity. The path BIP-8 is calculated over all bits of the previous STS SPE before scrambling. SDH uses this byte for the same purpose, but excludes the fixed stuff bytes in the calculation.
A.3.3 STS Path Signal Label: C2
One byte is allocated to identify the construction and content of the STS-level SPE, and for STS PDI (PDI-P). PDI-P is an application specific code that indicates to downstream equipment that there is a defect in one or more directly mapped embedded payloads in the STS SPE. SDH does not define codes for PDI-P. For ATM cell mapped STS-48c frame the C2 byte shall contain the code "00010011".
A.3.4 Path Status: G1
One byte is allocated to convey back to an originating STS PTE the path-terminating status and performance. This feature permits the status and performance of the complete duplex path to be monitored at either end or at any point along that path. Bits 1 through 4 convey the count of interleaved bit blocks that have been detected in error by the Path BIP-8 code (B3). This count has nine legal values, namely 0 to 8 errors. The remaining seven possible values represented by these four bits can only result from some condition unrelated to the forward path and shall be interpreted as zero errors. Bits 5, 6 and 7 provide codes to indicate both an old version (compliant with earlier versions of T1.105 standard) and an enhanced version of the STS Path remote defect indication (RDI-P). The enhanced version of RDI-P allows differentiation between payload, connectivity, and server defects. Bit 7 is set to the inverse of bit 6 to distinguish the enhanced version of RDI-P from the old version. Refer to T1.105 for more details. Bit 8 is unassigned at this time. 
A.3.5 Tandem Connection: N1
One byte is allocated to support Tandem Connection Maintenance and the Path Data Channel. Bits 1-4 of N1 are used to provide the Tandem Connection Incoming Error Count (IEC). Bits 5-8 of N1 are used to provide the Path Data Channel. SDH uses this byte for a similar purpose, but allows for either a bit-oriented TC maintenance channel or a LAPD Tandem Connection maintenance channel.
A.3.6 Multiframe Indicator: H4 
This byte provides a generalized multiframe indicator for payloads. Currently, this indicator is only used for VT-structured payloads. SDH uses this byte for the same purpose.
A.3.7 Path User Channel: F2
One byte is allocated for user communication purposes between Path elements. SDH uses this byte for the same purpose.
A.3.8 F3, K3
These bytes are not defined in SONET but are defined in SDH.
1 	ITU-T, Recommendation G.957, "Optical Interfaces for Equipments and Systems Relating to the Synchronous Digital Hierarchy," July 1995.
2 	ITU-T, Recommendation G.958, "Digital Line Systems Based on the Synchronous Digital Hierarchy for Use on Optical Fibre Cables," November 1994.
3 	ITU-T, Recommendation G.813, "Timing characteristics of SDH equipment slave clocks (SEC)," August 1996.
4 	ANSI T1.105.09-1996, "Synchronous Optical Network (SONET) - Network Element Timing and Synchronization," 1996.
5 	ANSI T1.105-1995, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats," 1995.
6 	ITU-T G.707, "Network node interface for the synchronous digital hierarchy (SDH)," March 1996.
7 	ANSI T1.105.01-1995, "Synchronous Optical Network (SONET) - Automatic Protection" 1995.
8 	ANSI T1.105.02-1995, "Synchronous Optical Network (SONET) - Payload Mappings" 1995.
9 	ITU-T, Recommendation I.432.1, "B-ISDN User-Network Interface - Physical Layer Specification: General Characteristics," February 1999.
10	ANSI T1.627-1993, "B-ISDN-ATM Layer Functionality and Specification," 1993.
11	ANSI T1.231-1993, "Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring," 1993.
12 ITU-T G.783, "Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks," January 1994
2.4 Gbps Physical Layer Specification 	AF-PHY-0133.000
	September 1999

2.4 Gbps Physical Layer Specification	AF-PHY-0133.000
October 1999

Page ii	ATM Forum Technical Committee

ATM Forum Technical Committee	Page 14 of 19