I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T G.997.1
TELECOMMUNICATION (09/2005)
STANDARDIZATION SECTOR
OF ITU

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Digital sections and digital line system – Access networks

Physical layer management for digital

subscriber line (DSL) transceivers

ITU-T Recommendation G.997.1

 ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER- G.200–G.299
TRANSMISSION SYSTEMS
INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.300–G.399
SYSTEMS ON METALLIC LINES
GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.400–G.449
SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH
METALLIC LINES
COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499
TRANSMISSION MEDIA CHARACTERISTICS G.600–G.699
DIGITAL TERMINAL EQUIPMENTS G.700–G.799
DIGITAL NETWORKS G.800–G.899
DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999
General G.900–G.909
Parameters for optical fibre cable systems G.910–G.919
Digital sections at hierarchical bit rates based on a bit rate of 2048 kbit/s G.920–G.929
Digital line transmission systems on cable at non-hierarchical bit rates G.930–G.939
Digital line systems provided by FDM transmission bearers G.940–G.949
Digital line systems G.950–G.959
Digital section and digital transmission systems for customer access to ISDN G.960–G.969
Optical fibre submarine cable systems G.970–G.979
Optical line systems for local and access networks G.980–G.989
Access networks G.990–G.999
QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER-RELATED G.1000–G.1999
ASPECTS
TRANSMISSION MEDIA CHARACTERISTICS G.6000–G.6999
DATA OVER TRANSPORT – GENERIC ASPECTS G.7000–G.7999
ETHERNET OVER TRANSPORT ASPECTS G.8000–G.8999
ACCESS NETWORKS G.9000–G.9999

For further details, please refer to the list of ITU-T Recommendations.

ITU-T Recommendation G.997.1

Physical layer management for digital subscriber line (DSL) transceivers

Summary
This Recommendation specifies the physical layer management for ADSL transmission systems. It
specifies means of communication on a transport transmission channel defined in the physical layer
ITU-T Recs G.992.1, G.992.2, G.992.3, G.992.4 and G.992.5. It specifies Network Elements content
and syntax for Configuration, Fault and Performance Management.

Source
ITU-T Recommendation G.997.1 was approved on 6 September 2005 by ITU-T Study Group 15
(2005-2008) under the ITU-T Recommendation A.8 procedure.

ITU-T Rec. G.997.1 (09/2005) i

 FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of
ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing
Recommendations on them with a view to standardizing telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.

NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementors
are cautioned that this may not represent the latest information and are therefore strongly urged to consult the
TSB patent database.

 ITU 2006
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.

ii ITU-T Rec. G.997.1 (09/2005)

 CONTENTS
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 2
4 Abbreviations................................................................................................................ 2
5 Overview ...................................................................................................................... 4
5.1 Physical layer management mechanisms ....................................................... 5
6 OAM communication channel...................................................................................... 7
6.1 Requirements on the PMD layer for the bit-oriented clear EOC ................... 8
6.2 Requirements on the PMD layer for the message-oriented clear EOC .......... 8
6.3 Data link layer ................................................................................................ 9
6.4 The SNMP protocol........................................................................................ 11
7 Management information base (MIB) elements ........................................................... 14
7.1 Failures ........................................................................................................... 16
7.2 Performance monitoring functions ................................................................. 18
7.3 Configuration functions.................................................................................. 28
7.4 Inventory information..................................................................................... 40
7.5 Test, diagnostic and status parameters ........................................................... 42
7.6 Network management elements partitioning.................................................. 48
Appendix I – Processing examples .......................................................................................... 71
I.1 Illustration of transmitter processing.............................................................. 71
I.2 Illustration of receiver processing .................................................................. 72
BIBLIOGRAPHY.................................................................................................................... 73

ITU-T Rec. G.997.1 (09/2005) iii

ITU-T Recommendation G.997.1

Physical layer management for digital subscriber line (DSL) transceivers

1 Scope
This Recommendation specifies the physical layer management for ADSL transmission systems
based on the usage of indicator bits and EOC messages defined in the G.992.x series of ITU-T
Recommendations and the clear embedded operation channel defined in this Recommendation.
It specifies Network Management elements content for configuration, fault and performance
management.
The mechanisms to provide OAM functions and to generate OAM flows F1, F2 and F3 will depend
on the transport mechanism of the physical layer transmission system as well as on the supervision
functions contained within the physical layer termination functions of equipment. This
Recommendation only specifies flow F3 – transmission path level.
For interrelationships of this Recommendation with other G.99x-series ITU-T Recommendations,
see ITU-T Rec. G.995.1.

2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[1] IETF RFC 1157 (1990), A Simple Network Management Protocol (SNMP).
[2] ITU-T Recommendation G.992.1 (1999), Asymmetric digital subscriber line (ADSL)
transceivers.
[3] ITU-T Recommendation G.992.2 (1999), Splitterless asymmetric digital subscriber line
(ADSL) transceivers.
[4] ITU-T Recommendation G.994.1 (2003), Handshake procedures for digital subscriber line
(DSL) transceivers.
[5] ITU-T Recommendation I.610 (1999), B-ISDN operation and maintenance principles and
functions.
[6] ITU-T I.432.x-series Recommendations, B-ISDN user-network interface – Physical layer
specification.
[7] ITU-T Recommendation T.35 (2000), Procedure for the allocation of ITU-T defined codes
for non-standard facilities.
[8] ITU-T Recommendation G.992.3 (2005), Asymmetric digital subscriber line transceivers 2
(ADSL2).
[9] ITU-T Recommendation G.992.4 (2002), Splitterless asymmetric digital subscriber line
transceivers 2 (ADSL2).
[10] ITU-T Recommendation G.992.5 (2005), Asymmetric digital subscriber line (ADSL)
transceivers – Extended bandwidth ADSL2 (ADSL2+).

ITU-T Rec. G.997.1 (09/2005) 1

3 Definitions
This Recommendation defines the following terms:
3.1 clear EOC: An octet-oriented data channel multiplexed in the physical layer transmission
frame structure.
3.2 anomaly: An anomaly is a discrepancy between the actual and desired characteristics of an
item.
The desired characteristic may be expressed in the form of a specification.
An anomaly may or may not affect the ability of an item to perform a required function.
3.3 defect: A defect is a limited interruption in the ability of an item to perform a required
function. It may or may not lead to maintenance action depending on the results of additional
analysis.
Successive anomalies causing a decrease in the ability of an item to perform a required function are
considered as a defect.
3.4 failure: A failure is the termination of the ability of an item to perform a required function.
NOTE – After failure, the item has a fault.
Analysis of successive anomalies or defects affecting the same item can lead to the item being
considered as "failed".
3.5 net data rate: Net data rate is defined in the G.992.x-series ITU-T Recommendations.

4 Abbreviations
This Recommendation uses the following abbreviations:
ADSL Asymmetric Digital Subscriber Line
AME ADSL Management Entity
AN Access Node
AS0 to AS3 Downstream simplex bearer channel designators
ATM Asynchronous Transfer Mode
ATU-C ADSL Transceiver Unit-Central office end (i.e., network operator)
ATU-R ADSL Transceiver Unit-Remote terminal end (i.e., CP)
CRC Cyclic Redundancy Check
CVF-L Code Violation-Line (Fast path)
CVI-L Code Violation-Line (Interleaved path)
DMT Discrete MultiTone
DSL Digital Subscriber Line
ECF-L Forward Error Correction Count Line (Fast path)
ECI-L Forward Error Correction Count Line (Interleaved path)
ECS-L Forward Error Correction second-Line
EOC Embedded Operations Channel
ES Errored Second
ES-L Errored Second-Line

2 ITU-T Rec. G.997.1 (09/2005)

FEBE-F Binary indication of Far-End Block Error count-Fast data
FEBE-I Binary indication of Far-End Block Error count-Interleaved data
FEC Forward Error Correction
FFEC-F Binary indication of Far-end Forward Error Correction count-Fast data
FFEC-I Binary indication of Far-end Forward Error Correction count-Interleaved data
HDLC High-level Data Link Control
HDSL High bit rate Digital Subscriber Line
HEC Header Error Control
ib0-23 Indicator bits
ID code Vendor identification code
ISDN Integrated Services Digital Network
kbit/s kilobits per second
LCD Loss of Cell Delineation
LOF Loss of Frame
LOS Loss of Signal
LOSS-L LOS Second-line
LS0-2 DUPLEX bearer channel designator
LSB Least Significant Bit
MIB Management Information Base
MSB Most Significant Bit
NCD No Cell Delineation
NE Network Element
NMS Network Management System
NT Network Termination
OAM Operations, Administration and Maintenance
POTS Plain Old Telephone Service (one of the services using the voiceband; sometimes
used as a descriptor for all voiceband services)
PSTN Public Switched Telephone Network
RDI Remote Defect Indication
RFI Remote Failure Indication
SEF Severely Errored Frame
SES-L Severely Errored Second-line
SNMP Simple Network Management Protocol
STM Synchronous Transfer Mode
T/S Interface(s) between ADSL network termination and Customer Installation or home
network
TC Transmission Convergence (layer)

ITU-T Rec. G.997.1 (09/2005) 3

TCM Time Compression Multiplex
TE Terminal Equipment
T-R Interface(s) between ATU-R and switching layer (ATM or STM)
TR Threshold Reports
UAS Unavailable Seconds
U-C Loop interface – Central Office end
U-R Loop interface – Remote Terminal end
V-C Logical interface between ATU-C and a digital network element such as one or
more switching systems

5 Overview
Figure 5-1 shows the system reference model for this Recommendation.

Figure 5-1/G.997.1 – System reference model

There are four management interfaces defined in this Recommendation.

The Q-interface at the AN for Network Management Systems (NMS). All the parameters specified
in this Recommendation apply at the Q-interface. The Q-interface provides the interface between
the Network Management Systems of the operator and the Management Entity in the Access Node.
The near-end parameters supported in the Management Entity are derived from ATU-C while the
far-end parameters (from the ATU-R) can be derived by either of two interfaces over the
U-interface:
• By use of the indicator bits and EOC message, which are provided at the PMD layer, can be
used to generate the required ATU-R parameters in the Management Entity of the AN.
• By use of the OAM channel and protocol (specified in clause 6) to retrieve the parameters
from the ATU-R, when requested by the Management Entity of the AN.
The definition of the transport of the management instrumentation over the Q-interface is outside
the scope of this Recommendation.

4 ITU-T Rec. G.997.1 (09/2005)

At the U-interface there are two management interfaces, one at the ATU-C and one at the ATU-R.
The main purposes are to provide:
• At the ATU-C: the ATU-C near-end parameters for the ATU-R to retrieve over the
U-interface.
• At the ATU-R: the ATU-R near-end parameters for the ATU-C to retrieve over the
U-interface.
This Recommendation defines (see clause 6) a method for the communication of the parameters
(as defined in clause 7) over the U-interface.
At the T-/S-interface a subset of the parameters specified in this Recommendation may apply. The
purpose is to indicate the ADSL link status to the TE. These parameters are maintained by the
Management Entity of the NT and are made available over the T-/S-interface.
The far-end parameters (from the ATU-C) can be derived by either of two interfaces over the
U-interface:
• By use of the indicator bits and EOC message, which are provided at the PMD layer, can be
used to generate the required ATU-C parameters in the Management Entity of the NT.
• By use of the OAM channel and protocol (specified in clause 6) to retrieve the parameters
from the ATU-C, when requested by the Management Entity of the NT.
The definition of the transport of this management information over the T-/S-interfaces is outside
the scope of this Recommendation.
Dependent on the transceiver Recommendation (e.g., ITU-T Recs G.992.1 or G.992.2), some of the
parameters may not apply (i.e., fast data stream parameters for ITU-T Rec. G.992.2).

5.1 Physical layer management mechanisms

The general definition of OAM for ATM networks is defined in ITU-T Rec. I.610. The physical
layer contains the three lowest OAM levels as outlined in Figure 5-2. The allocation of the
OAM flows is as follows:
– F1: regenerator section level;
– F2: digital section level;
– F3: transmission path level.

ITU-T Rec. G.997.1 (09/2005) 5

 Figure 5-2/G.997.1 – OAM hierarchical levels and their relationship with
the ATM layer and physical layer

The physical layer (F1-F3) in this Recommendation, is defined as the Physical Media Dependent
(PMD) layer and the ATM-TC layer. The Physical layer and the ATM layer are coupled from the
fault management perspective. When an F3 fault (e.g., LOS) is detected, it is reported to the NMS
but an F4/F5 fault, as defined in ITU-T Rec. I.610, is generated as well.
The ADSL LINE (see Figure 5-3) is characterized by a metallic transmission medium utilizing an
analogue coding algorithm, which provides both analogue and digital performance monitoring at
the line entity. The ADSL LINE is delimited by the two end points, known as line terminations.
ADSL LINE terminations are the point, where the analogue coding algorithms end, and the
subsequent digital signal is monitored for integrity. The ADSL LINE is defined between the V-D
and the T-D reference points.
The ADSL ATM PATH is defined between the V-C and T-R reference points.
The ADSL STM PATH is for further study.

Figure 5-3/G.997.1 – ADSL LINE and ADSL ATM PATH definition

6 ITU-T Rec. G.997.1 (09/2005)

The HDSL LINE (see Figure 5-4) is terminated in the HTU-C and HTU-R. It is also called an
Access Digital Section. Within the Access Digital Section a regenerator could be present.

Figure 5-4/G.997.1 – HDSL LINE and PATH definition

6 OAM communication channel

This clause specifies an optional OAM communication channel across the U-interface (see
Figure 6-1). If this channel is implemented, the ATU-C and the ATU-R may use it for transporting
physical layer OAM messages. If either the ATU-C or the ATU-R do not have the capability of this
OAM channel, the far-end parameters, defined in clause 7, at the ATU-C shall be derived from the
indicator bits and EOC messages defined in ITU-T Recs G.992.1, G.992.2, G.992.3 and G.992.4.
Support for the OAM communication channel defined in this clause will be indicated during
initialization by messages defined in ITU-T Rec. G.994.1 for G.992.1 and G.992.2.
NOTE – In those cases where neither the ATU-R nor ATU-C implements this communication channel, there
are some reduced physical layer OAM capabilities (see clause 7).
G.99x-series Recommendations may provide one of two mechanisms to transport physical layer
OAM messages either:
– through a bit-oriented clear EOC (e.g., ITU-T Recs G.992.1, G.992.2), then the channel
shall meet the requirements specified in 6.1. The data link layer shall be as specified in 6.3;
– or, through a message-oriented clear EOC (e.g., ITU-T Recs G.992.3, G.992.4, G.992.5),
then the channel shall meet the requirements specified in 6.2. The data link layer shall be as
specified in clauses 7.8.2.3, 7.8.2.4 and 9.4.1.8/G.992.3.

Figure 6-1/G.997.1 – OAM communication channel layers for bit-oriented clear EOC

ITU-T Rec. G.997.1 (09/2005) 7

 Figure 6-2/G.997.1 – OAM communication channel layers for message-oriented clear EOC

6.1 Requirements on the PMD layer for the bit-oriented clear EOC
In order to support the physical layer OAM protocols defined in this Recommendation, a physical
layer Recommendation shall provide a full duplex data channel for support of the data link layer
defined in 6.3.
The Clear EOC serves the function of a physical layer of the protocol stack defined in this
Recommendation for ITU-T Recs G.992.2 and G.992.1.
1) The Clear EOC shall be a part of the protocol overhead for the particular xDSL line coding.
2) The Clear EOC shall be available to carry traffic whenever the xDSL protocol is in a
normal transmission mode (e.g., "showtime").
3) The Clear EOC shall be available regardless of the specific configuration options or run
time adaptation of an ATU-C and ATU-R that are communicating.
4) The Clear EOC shall be terminated in the ATU-R and the ATU-C.
5) The Clear EOC shall support traffic of at least 4 kbit/s.
6) The Clear EOC shall support delineation of individual octets in order to support the link
level protocol defined in 7.1.
7) The Clear EOC should not support error correction or detection. Error correction and
detection is supported by use of the OAM stack defined in this Recommendation.
8) The Clear EOC should not guarantee the delivery of data carried over the channel.
9) The Clear EOC should not support retransmission of data upon error.
10) The Clear EOC should not acknowledge the receipt of data by the far end of the link.
11) The Clear EOC should not require a specific initialization procedure, it can be assumed to
be operational whenever the two modems are in synchronization for "showtime" transport
of data.

6.2 Requirements on the PMD layer for the message-oriented clear EOC
In order to support the physical layer OAM protocols defined in this Recommendation, a physical
layer Recommendation shall provide a full duplex data channel for support of SNMP protocol
defined in 6.4.
1) The Clear EOC shall be a part of the protocol overhead for the particular xDSL line coding.
2) The Clear EOC shall be available to carry traffic whenever the xDSL protocol is in a
normal transmission mode (e.g., "showtime").
3) The Clear EOC shall be available regardless of the specific configuration options or run
time adaptation of an ATU-C and ATU-R that are communicating.
4) The Clear EOC shall be terminated in the ATU-R and the ATU-C.

8 ITU-T Rec. G.997.1 (09/2005)

5) The Clear EOC shall support traffic of at least 4 kbit/s.
6) The Clear EOC shall support delineation of messages through HDLC in order to support
the link level protocol defined in 7.1.
7) The Clear EOC should not support retransmission of data upon error.
8) The Clear EOC should not require a specific initialization procedure, it can be assumed to
be operational whenever the two modems are in synchronization for "showtime" transport
of data.

6.3 Data link layer

For the transport mechanism, an HDLC-like mechanism is proposed with the characteristics
detailed in the following subclauses. The defined method is based on ISO/IEC 3309.
NOTE – For ITU-T Recs G.992.3, G.992.4 and G.992.5, the data link layer uses the clear EOC messages
embedded in the overhead channel as defined in clauses 7.8.2.3, 7.8.2.4 and 9.4.1.8/G.992.3. This
mechanism supersedes the characteristics presented in the following subclauses.
The main differences between 6.3/G.997.1 protocol and G.992.3 protocol are:
– The address field and control field shall be as defined in 7.8.2.4/G.992.3.
– The maximum payload length of G.992.3 is 1024 octets instead of 510 octets.
– The first byte of the payload is always 0116 to indicate a clear EOC command.
– Each G.992.3 clear EOC command is acknowledged by the remote side.
6.3.1 Format convention
The basic format convention used for messages is illustrated in Figure 6-3. Bits are grouped into
octets. The bits of each octet are shown horizontally and are numbered from 1 to 8. Octets are
displayed vertically and are numbered from 1 to N.
The octets are transmitted in ascending numerical order.
The Frame Check Sequence (FCS) field spans two octets: Bit 1 of the first octet is the MSB and
bit 8 of the second octet is the LSB (Figure 6-4).

8 7 6 5 4 3 2 1 Octet
1
2
...
N

Figure 6-3/G.997.1 – Format convention

8 7 6 5 4 3 2 1 Octet
28 215 1
20 27 2

Figure 6-4/G.997.1 – FCS mapping convention

ITU-T Rec. G.997.1 (09/2005) 9

6.3.2 OAM frame structure
The frame structure is as depicted in Figure 6-5.

7E16 Opening Flag

FF16 Address field
0316 Control field = UI frame
Information Payload Max 510 bytes
FCS Frame Check Sequence (First octet)
FCS Frame Check Sequence (Second octet)
7E16 Closing Flag

Figure 6-5/G.997.1 – OAM frame structure

The opening and closing flag sequence shall be the octet 7E16. The address and control field of the
frame shall be coded with FF16 and 0316, respectively.
Transparency of the information payload to the flag sequence and the frame check sequence are
described below.
6.3.3 Octet transparency
In this approach, any data that is equal to 7E16 (011111102) (the Flag Sequence) or 7D16 (the
Control Escape) are escaped as described below.
After Frame Check Sequence (FCS) computation, the transmitter examines the entire frame
between the two Flag Sequences. Any data octets which are equal to the Flag Sequence (7E16) or
the Control Escape (7D16D) are replaced by a two-octet sequence consisting of the Control Escape
octet followed by the original octet Exclusive-OR'ed with hexadecimal 0x20 (this is
bit 5 complemented, where the bit positions are numbered 76543210). In summary, the following
substitutions are made:
• a data octet of 7E16 is encoded as two octets 7D16, 5E16;
• a data octet of 7D16 is encoded as two octets 7D16, 5D16.
On reception, prior to FCS computation, each Control Escape octet (7D16) is removed, and the
following octet is exclusive-OR'ed with hexadecimal 2016 (unless the following octet is 7E16, which
is the flag, and indicates the end of frame, and therefore an abort has occurred). In summary, the
following substitutions are made:
• a sequence of 7D16, 5E16 is replaced by the data octet 7E16;
• a sequence of 7D16, 5D16 is replaced by the data octet 7D16;
• a sequence of 7D16, 7E16 aborts the frame.
Note that since octet stuffing is used, the data frame is guaranteed to have an integer number of
octets.
6.3.4 Frame check sequence
The FCS field is 16 bits (2 octets) in length. As defined in ISO/IEC 3309, it shall be the one's
complement of the sum (modulo 2) of:
a) the remainder of xk (x15 + x14 + x13 + x12 + x11 + x10 + x9 + x8 + x7 + x6 + x5 + x4 + x3 + x2 +
x + 1) divided (modulo 2) by the generator polynomial x16 + x12 + x5 + 1, where k is the
number of bits in the frame existing between, but not including, the last bit of the final
opening flag and the first bit of the FCS, excluding octets inserted for transparency; and

10 ITU-T Rec. G.997.1 (09/2005)

b) the remainder of the division (modulo 2) by the generator polynomial x16 + x12 + x5 + 1, of
16
the product of x by the content of the frame existing between, but not including, the last
bit of the final opening flag and the first bit of the FCS, excluding octets inserted for
transparency.
As a typical implementation at the transmitter, the initial content of the register of the device
computing the remainder of the division is preset to all binary ONEs and is then modified by
division by the generator polynomial (as described above) on the information field. The one's
complement of the resulting remainder is transmitted as the 16-bit FCS.
As a typical implementation at the receiver, the initial content of the register of the device
computing the remainder of the division is preset to all binary ONEs. The final remainder, after
multiplication by 16 and then division (modulo 2) by the generator polynomial x16 + x12 + x5 + 1 of
the serial incoming protected bits after removal of the transparency octets and the FCS, will be
00011101000011112 (x15 through x0, respectively) in the absence of transmission errors.
The FCS is calculated over all bits of the Address, Control, and Information payload fields of the
frame.
The register used to calculate the CRC shall be initialized to the value FFFF16, both at the
transmitter and the receiver.
The LSB of the FCS is sent first, followed by the MSB.
On the receiver a message received without errors results in a CRC calculation of F0B816.
6.3.5 Invalid frames
The following conditions result in an invalid frame:
• Frames which are too short (less than 4 octets inbetween flags not including transparency
octets).
• Frames which contain a Control Escape octet followed immediately by a Flag
(i.e., 7D16, 7E16).
• Frames which contain control escape sequences other than 7D16, 5E16 and 7D16, 5D16.
Invalid frames shall be discarded. The receiver shall immediately start looking for the beginning
flag of a subsequent frame.
6.3.6 Synchronism
The EOC frame structure transport is octet synchronous. Octet transport and synchronism for this
transport is defined in accordance with the TC layer.
6.3.7 Time fill
Inter-frame time fill is accomplished by inserting additional flag octets (7E16) between the closing
and the subsequent opening flag on the EOC transport channel. Inter-octet time fill is not supported.

6.4 The SNMP protocol

If implemented, SNMP messages shall be used as the message encoding over the HDLC data link
channel defined in 6.2 for ITU-T Recs G.992.1 and G.992.2; or over the clear EOC message
embedded in the overhead channel as defined in clauses 7.8.2.3, 7.8.2.4 and 9.4.1.8/G.992.3 for
ITU-T Recs G.992.3 and G.992.4.

ITU-T Rec. G.997.1 (09/2005) 11

6.4.1 SNMP message mapping in HDLC frames
This clause applies only to Recommendations defining a bit-oriented clear EOC (e.g., ITU-T
Recs G.992.1, G.992.2).
The SNMP messages are placed directly in the HDLC frame together with the protocol identifier
(see Figure 6-6). The protocol identifier is two bytes ahead of the SNMP message. The two bytes
contain the ethertype SNMP value 814C16 as defined in RFC 1700. A single HDLC frame is used to
transport each SNMP message.

Figure 6-6/G.997.1 – OAM communication channel protocol over the U-Interface

The length of an SNMP message shall be less than or equal to 508 bytes.
Due to the transparency mechanism described in 6.3.3, the number of bytes actually transmitted in
between opening and closing flag may be higher than 514.
6.4.2 SNMP message mapping in clear EOC messages
This clause applies only to Recommendations defining message-oriented clear EOC (e.g., ITU-T
Recs G.992.3, G.992.4).
The SNMP messages are placed directly in the clear EOC messages together with the protocol
identifier (see Figure 6-7). The protocol identifier is two bytes ahead of the SNMP message. The
two bytes contain the ethertype SNMP value 814C16 as defined in RFC 1700. A single HDLC frame
is used to transport each SNMP message.

Figure 6-7/G.997.1 – OAM communication channel protocol over the U-interface

12 ITU-T Rec. G.997.1 (09/2005)

The length of an SNMP message shall be less than or equal to 508 bytes.
Due to the transparency mechanism described in 6.3.3, the number of bytes actually transmitted
inbetween opening and closing flag may be greater than 515.
6.4.3 Protocol based on SNMP
The SNMP protocol as defined in [1] consists of four types of operations, which are used to
manipulate management information. These are:
Get Used to retrieve specific management information.
Get-Next Used to retrieve, via traversal of the MIB, management information.
Set Used to alter management information.
Trap Used to report extraordinary events.
These four operations are implemented using five types of PDUs:
GetRequest-PDU Used to request a Get operation.
GetNextRequest-PDU Used to request a Get-Next operation.
GetResponse-PDU Used to respond to a Get, Get-Next, or Set operation.
SetRequest-PDU Used to request a Set operation.
Trap-PDU Used to report a Trap operation.
If implemented, SNMP messages shall be used according to the following requirements.
6.4.3.1 Use of EOC channel
The ADSL OAM channel will be used for sending HDLC-encapsulated SNMP messages between
adjacent AMEs.
An AME-ADSL Management Entity residing in the ATU-R and ATU-C will send and interpret
these SNMP messages. This ADSL OAM channel is used for requests, responses, and traps,
differentiated according to the SNMP PDU type.
6.4.3.2 Message format
The message format specified in [1] shall be used. That is, messages shall be formatted according to
SNMP version 1.
All SNMP messages shall use the community name "ADSL", that is, the OCTET STRING value:
"4144534C16".
In all SNMP Traps, the agent-addr field (which has syntax NetworkAddress), shall always have the
IpAddress value: 0.0.0.0.
In all SNMP Traps, the time-stamp field in the Trap-PDU shall contain the value of an AME's
MIB object at the time of trap generation.
In any standard SNMP Trap, the enterprise field in the Trap-PDU shall contain the value of the
agent's sysObjectID MIB object (sysObjectID is defined in the system group of MIB-II).
6.4.3.3 Message sizes
All ADSL OAM implementations shall be able to support SNMP messages of size up to and
including 508 octets.
6.4.3.4 Message response time
Response time refers to the elapsed time from the submission of an SNMP message
(e.g., GetRequest, GetNextRequest or SetRequest message) by an AME across an ADSL Interface

ITU-T Rec. G.997.1 (09/2005) 13

to the receipt of the corresponding SNMP message (e.g., GetResponse message) from the adjacent
AME. An SNMP GetRequest, GetNextRequest, or SetRequest message is defined in this context as
a request concerning a single object.
The AME shall support maximum Response Times of 1 s for 95% of all SNMP GetRequests,
GetNextRequests or SetRequests containing a single object received from an adjacent
AME independent of the ADSL Interface's physical line rate.
6.4.3.5 Object value data correctness
Data correctness refers to the maximum elapsed time since an object value in the ADSL Interface
MIB was known to be current. The following specifies the requirements on the Data Correctness of
the ADSL OAM objects and the event notifications.
The ADSL Interface MIB objects shall have the Data Correctness of a maximum of 30 s.
The AME shall support event notifications (i.e., SNMP Traps) for generic SNMP events within 2 s
of the event detection by the AME.

7 Management information base (MIB) elements

The Management Information Base (MIB) contains six types of information:
• Fault monitoring – Failures (alarm indications);
• Fault monitoring – Threshold crossing (alert messages);
• Performance monitoring parameters (counters);
• Configuration parameters;
• Inventory parameters;
• Test, diagnostic and status parameters.
Figure 7-1 shows the In-service performance monitoring process. The primitives are specified in the
physical layer of G.992.x.-series ITU-T Recommendations.

Figure 7-1/G.997.1 – In-service performance monitoring process

As an Access Node can handle a large number of ATU-Cs (e.g., hundreds or perhaps thousands of
ADSL lines), provisioning every parameter on every ATU-C may become burdensome. In
response, two modes have been created to define ADSL equipment configuration data profiles, as

14 ITU-T Rec. G.997.1 (09/2005)

well as a mechanism to associate the equipment to these profiles. Profile tables may be
implemented in one of two ways, but not simultaneously:
• MODE-I: Dynamic Profiles – one profile shared by one or multiple ADSL lines.
Implementations using this mode will enable the operator of the system to dynamically
create and delete profiles as needed. One or more ADSL lines may be configured to share
parameters of a single profile (e.g., adslLineConfProfileName = 'silver') by setting its
adslLineConfProfile objects to the index value of this profile. If a change is made to the
profile, all lines that refer to it will be re-configured to the changed parameters. Before a
profile can be deleted or taken out of service, it shall be first unreferenced from all
associated lines.
• MODE-II: Static Profiles – one profile per ADSL physical line always.
Implementations with this mode will automatically create a profile one-for-one with each
ADSL line. The name of this profile is a system generated read-only object whose value is
equivalent to the index of the line. The management agent in the Access Node will not
allow the operator of the system to create/delete profiles in this mode.
NOTE – For more details on the use of profiles, refer to the IETF RFC 2662.
At the Q-interface, a line is configured by linking the following information to the line
(see Figure 7-2):
• One Line Configuration Profile (see Table 7-9) for the line;
• One Channel Configuration Profile (see Table 7-11) for each downstream and each
upstream bearer channel;
• One Data Path Configuration Profile (see Table 7-13) for each downstream and each
upstream bearer channel.

ITU-T Rec. G.997.1 (09/2005) 15

 Figure 7-2/G.997.1 – Overview of the MIB elements provided for each line

Some or all of the configuration parameters contained in the Line, Channel and Data Path
Configuration Profiles linked to the line, may be written and/or read, depending on the interface
under consideration:
– Q interface: Management interface towards the ATU-C, from the network side perspective.
– U-C interface: Management interface towards the ATU-C, from the ATU-R's perspective.
– U-R interface: Management interface towards the ATU-C, from the ATU-R's perspective.
– T/S interface: Management interface towards the ATU-R, from the premises side
perspective.
In 7.5, a detailed list is given of the management elements applying to each of these interfaces, with
indication whether they are mandatory or optional and whether they can be read, written or both.

7.1 Failures
Any failure defined in this clause shall be conveyed to the NMS by the ATU-C (over the
Q-interface) and should be conveyed to the NMS by the ATU-R (over the T-/S-interface) after it is
detected.
The near-end failure detections shall be provided at the ATU-C and shall be provided at the
ATU-R.

16 ITU-T Rec. G.997.1 (09/2005)

The far-end failure detections shall be provided at the ATU-C (ATU-R is at the far-end), and may
be provided at the ATU-R (ATU-C is at the far-end).
7.1.1 Line failures
7.1.1.1 Line near-end failures
7.1.1.1.1 Loss-of-signal (LOS) failure
An LOS failure is declared after 2.5 ± 0.5 s of contiguous LOS defect, or, if LOS defect is present
when the criteria for LOF failure declaration have been met (see LOF definition below). A
LOS failure is cleared after 10 ± 0.5 s of no LOS defect.
7.1.1.1.2 Loss-of-frame (LOF) failure
An LOF failure is declared after 2.5 ± 0.5 s of contiguous SEF defect, except when an LOS defect
or failure is present (see LOS definition above). A LOF failure is cleared when LOS failure is
declared, or after 10 ± 0.5 s of no SEF defect.
7.1.1.1.3 Loss-of-power (LPR) failure
An LPR failure is declared after 2.5 ± 0.5 s of contiguous near-end LPR primitive presence. An
LPR failure is cleared after 10 ± 0.5 s of no near-end LPR primitive presence.
7.1.1.2 Line far-end failures
7.1.1.2.1 Far-end loss-of-signal (LOS-FE) failure
A far-end loss-of-signal (LOS-FE) failure is declared after 2.5 ± 0.5 s of contiguous far-end
LOS defect, or, if far-end LOS defect is present when the criteria for LOF failure declaration have
been met (see LOF definition below). A far-end LOS failure is cleared after 10 ± 0.5 s of no far-end
LOS defect.
7.1.1.2.2 Far-end loss-of-frame (LOF-FE) failure
A far-end loss-of-frame (LOF-FE) failure is declared after 2.5 ± 0.5 s of contiguous RDI defect,
except when a far-end LOS defect or failure is present (see LOS definition above). A far-end
LOF failure is cleared when far-end LOS failure is declared, or after 10 ± 0.5 s of no RDI defect.
7.1.1.2.3 Far-end loss-of-power (LPR-FE) failure
A far-end loss-of-power (LPR-FE) failure is declared after the occurrence of a far-end
LPR primitive followed by 2.5 ± 0.5 s of contiguous near-end LOS defect. A far-end LPR failure is
cleared after 10 ± 0.5 s of no near-end LOS defect.
7.1.1.3 Line initialization (LINIT) failure
If the line is forced to the L0 state (or into loop diagnostics mode) and an attempt to reach the
L0 state (or to successfully complete the loop diagnostics procedures) fails (after a vendor
discretionary number of retries and/or within a vendor discretionary timeout), then an Initialization
Failure occurs. An Initialization Failure cause and Last Successful Transmitted State is given with
the Line Initialization Failure (see 7.5.1.3). A Line Initialization failure shall be conveyed to the
NMS by the ATU-C (over the Q-interface) and should be conveyed to the NMS by the
ATU-R (over the T-/S-interface) after it is detected.
7.1.2 Channel failures
No channel failures are defined.
7.1.3 STM data path failures
The STM data path failures are for further study.

ITU-T Rec. G.997.1 (09/2005) 17

7.1.4 ATM data path failures
7.1.4.1 ATM data path near-end failures
7.1.4.1.1 No cell delineation (NCD) failure
An NCD failure is declared when an NCD anomaly persists for more than 2.5 ± 0.5 s after the start
of SHOWTIME. An NCD failure terminates when no NCD anomaly is present for more than
10 ± 0.5 s.
7.1.4.1.2 Loss of cell delineation (LCD) failure
An LCD failure is declared when an LCD defect persists for more than 2.5 ± 0.5 s. An LCD failure
terminates when no LCD defect is present for more than 10 ± 0.5 s.
7.1.4.2 ATM data path far-end failures
7.1.4.2.1 Far-end no cell delineation (NCD-FE) failure
An NCD-FE failure is declared when an NCD-FE anomaly persists for more than 2.5 ± 0.5 s after
the start of SHOWTIME. An NCD-FE failure terminates when no NCD-FE anomaly is present for
more than 10 ± 0.5 s.
7.1.4.2.2 Far-end loss of cell delineation (LCD-FE) failure
An LCD-FE failure is declared when an LCD-FE defect persists for more than 2.5 ± 0.5 s. An
LCD-FE failure terminates when no LCD-FE defect is present for more than 10 ± 0.5 s.
7.1.5 PTM data path failures
7.1.5.1 PTM data path near-end failures
7.1.5.1.1 Out-of-Sync (OoS) failure
An OoS failure is declared when an oos-n anomaly persists for more than 2.5 + 0.5 s. An OoS
failure terminates when no oos-n anomaly is present for more than 10 + 0.5 s.
7.1.5.2 PTM data path far-end failures
7.1.5.2.1 Far-end out-of-sync (OoS-FE) failure
An OoS-FE failure is declared when an oos-f anomaly persists for more than 2.5 + 0.5 s. An
OoS-FE failure terminates when no oos-f anomaly is present for more than 10 + 0.5 s.

7.2 Performance monitoring functions

Near-end performance monitoring (PM) functions shall be provided at the ATU-C and at the
ATU-R. Far-end performance monitoring functions shall be provided at the ATU-C (ATU-R is at
the far-end) and are optional at the ATU-R (ATU-C is at the far-end).
If the line is forced to the L0 state (see 7.3.1.3), then Performance Monitoring counters are active,
irrespective of the actual Power management state of the line (see 7.5.1.2). If the line is forced to
the L3 state, then all Performance Monitoring counters are frozen, including the UAS counter.
7.2.1 Line performance monitoring parameters
This clause defines a set of Line performance monitoring parameters. Support of the performance
parameters in a network element is indicated as mandatory (M) or optional (O) in Table 7-1.

18 ITU-T Rec. G.997.1 (09/2005)

7.2.1.1 Near-end line performance monitoring parameters
7.2.1.1.1 Forward error correction second – line (FECS-L)
This parameter is a count of 1-second intervals with one or more FEC anomalies summed over all
received bearer channels.
7.2.1.1.2 Errored second – line (ES-L)
This parameter is a count of 1-second intervals with one or more CRC-8 anomalies summed over all
received bearer channels, or one or more LOS defects, or one or more SEF defects, or one or more
LPR defects.
7.2.1.1.3 Severely errored second – line (SES-L)
This parameter is a count of severely errored second (SES). An SES is declared if 18 or more
CRC-8 anomalies summed over all received bearer channels, or one or more LOS defects, or one or
more SEF defects, or one or more LPR defects, occur during a 1-second interval.
If the relevant Recommendation (e.g., ITU-T Rec. G.992.3) supports one-second normalized CRC
anomaly counter increment, the one-second counter used to declare SES shall increment with this
value instead of one for each CRC-8 anomaly.
If a common CRC is applied over multiple bearer channels, then each related CRC-8 anomaly shall
be counted only once for the whole set of bearer channels over which the CRC is applied.
7.2.1.1.4 LOS second – line (LOSS-L)
This parameter is a count of 1-second intervals containing one or more LOS defects.
7.2.1.1.5 Unavailable second – line (UAS-L)
This parameter is a count of 1-second intervals for which the ADSL line is unavailable. The
ADSL line becomes unavailable at the onset of 10 contiguous SES-Ls. The 10 SES-Ls are included
in unavailable time. Once unavailable, the ADSL line becomes available at the onset of
10 contiguous seconds with no SES-Ls. The 10 seconds with no SES-Ls are excluded from
unavailable time. Some parameter counts are inhibited during unavailability, see 7.2.7.13.
7.2.1.2 Far-end line performance monitoring parameters
7.2.1.2.1 Forward error correction second – line far-end (FECS-LFE)
This parameter is a count of 1-second intervals with one or more FFEC anomalies summed over all
transmitted bearer channels.
7.2.1.2.2 Errored second – line far-end (ES-LFE)
This parameter is a count of 1-second intervals with one or more FEBE anomalies summed over all
transmitted bearer channels, or one or more LOS-FE defects, or one or more RDI defects, or one or
more LPR-FE defects.
7.2.1.2.3 Severely errored second – line far-end (SES-LFE)
This parameter is a count of severely errored second (SES). An SES is declared if 18 or more FEBE
anomalies summed over all transmitted bearer channels, or one or more far-end LOS defects, or one
or more RDI defects, or one or more LPR-FE defects, occur during a 1 second-interval.
If the relevant Recommendation (e.g., ITU-T Rec. G.992.3) supports one-second normalized CRC
anomaly counter increment, the one-second counter used to declare SES shall increment with this
value instead of one for each FEBE anomaly.
If a CRC is applied over multiple bearer channels, then each related FEBE anomaly shall be
counted only once for the whole set of related bearer channels.

ITU-T Rec. G.997.1 (09/2005) 19

7.2.1.2.4 LOS second – line far-end (LOSS-LFE)
This parameter is a count of 1-second intervals containing one or more far-end LOS defects.
7.2.1.2.5 Unavailable seconds – line far-end (UAS-LFE)
This parameter is a count of 1-second intervals for which the far-end ADSL line is unavailable.
The far-end ADSL line becomes unavailable at the onset of 10 contiguous SES-LFEs. The
10 SES-LFEs are included in unavailable time. Once unavailable, the far-end ADSL line becomes
available at the onset of 10 contiguous seconds with no SES-LFEs. The 10 seconds with no
SES-LFEs are excluded from unavailable time. Some parameter counts are inhibited during
unavailability, see 7.2.7.13.
7.2.1.3 Line initialization performance monitoring parameters
7.2.1.3.1 Full initialization count
This parameter is a count of the total number of full initializations attempted on the line (successful
and failed) during the accumulation period. Parameter procedures shall be as defined in 7.2.7.
7.2.1.3.2 Failed full initialization count
This performance parameter is a count of the total number of failed full initializations during the
accumulation period. A failed full initialization is when showtime is not reached at the end of the
full initialization procedure, e.g., when:
• A CRC error is detected.
• A time-out occurs.
• Unexpected message content is received.
Parameter procedures shall be as defined in 7.2.7.
7.2.1.3.3 Short initialization count
This parameter is a count of the total number of fast retrains or short initializations attempted on the
line (successful and failed) during the accumulation period. Parameter procedures shall be as
defined in 7.2.7.
Fast Retrain is defined in ITU-T Rec. G.992.2.
Short Initialization is defined in ITU-T Recs G.992.3 and G.992.4.
7.2.1.3.4 Failed short initialization count
This performance parameter is a count of the total number of failed fast retrains or short
initializations during the accumulation period. A failed fast retrain or short initialization is when
showtime is not reached at the end of the fast retrain or short initialization procedure, e.g., when:
• A CRC error is detected.
• A time-out occurs.
• A fast retrain profile is unknown.
Parameter procedures shall be as defined in 7.2.7.
7.2.2 Channel performance monitoring parameters
This clause defines a set of Channel performance monitoring parameters. Support of the
performance parameters in a network element is indicated as mandatory (M) or optional (O) in
Table 7-2.

20 ITU-T Rec. G.997.1 (09/2005)

7.2.2.1 Channel near-end performance monitoring parameters
7.2.2.1.1 Code violation – channel (CV-C)
This parameter is a count of CRC-8 anomalies (the number of incorrect CRC) occurring in the
bearer channel during the accumulation period. This parameter is subject to inhibiting, see 7.2.7.13.
If the CRC is applied over multiple bearer channels, then each related CRC-8 anomaly shall
increment each of the counters related to the individual bearer channels.
7.2.2.1.2 Forward error correction – channel (FEC-C)
This parameter is a count of FEC anomalies (the number of corrected code words) occurring in the
bearer channel during the accumulation period. This parameter is subject to inhibiting, see 7.2.7.13.
If FEC is applied over multiple bearer channels, then each related FEC anomaly shall increment
each of the counters related to the individual bearer channels.
7.2.2.2 Channel far-end performance monitoring parameters
7.2.2.2.1 Code violation – channel far-end (CV-CFE)
This parameter is a count of FEBE anomalies occurring in the bearer channel during the
accumulation period. This parameter is subject to inhibiting, see 7.2.7.13.
If the CRC is applied over multiple bearer channels, then each related FEBE anomaly shall
increment each of the counters related to the individual bearer channels.
7.2.2.2.2 Forward error correction – channel far-end (FEC-CFE)
This parameter is a count of FFEC anomalies occurring in the bearer channel during the
accumulation period. This parameter is subject to inhibiting, see 7.2.7.13.
If FEC is applied over multiple bearer channels, then each related FFEC anomaly shall increment
each of the counters related to the individual bearer channels.
7.2.3 STM data path performance monitoring parameters
The STM channel performance monitoring parameters are for further study.
7.2.4 ATM data path performance monitoring parameters
This clause defines a set of ATM Data Path performance monitoring parameters using the cell
transfer outcomes. Support of the performance parameters in a network element is indicated as
mandatory (M) or optional (O) in Table 7-3.
NOTE – The far-end parameters cannot be supported using only the indicator bits or EOC messages
specified in ITU-T Rec. G.992.1 or ITU-T Rec. G.992.2. They may be provided using the
OAM communication channel specified in clause 6.
7.2.4.1 ATM data path near-end performance monitoring parameters
7.2.4.1.1 Near-end HEC violation count (HEC-P)
The near-end HEC_violation_count performance parameter is a count of the number of occurrences
of a near-end HEC anomaly in the ATM Data Path.
7.2.4.1.2 Near-end delineated total cell count (CD-P)
The near-end delineated_total_cell_count performance parameter is a count of the total number of
cells passed through the cell delineation and HEC function process operating on the ATM Data Path
while in the SYNC state.

ITU-T Rec. G.997.1 (09/2005) 21

7.2.4.1.3 Near-end user total cell count (CU-P)
The near-end user_total_cell_count performance parameter is a count of the total number of cells in
the ATM Data Path delivered at the V-C (for ATU-C) or T-R (for ATU-R) interface.
7.2.4.1.4 Near-end idle cell bit error count (IBE-P)
The near-end idle_bit_error_count performance parameter in a count of the number of bit errors in
the idle cell payload received in the ATM Data Path at the near-end.
NOTE – The idle cell payload is defined in ITU-T Recs I.361 and I.432.x subseries.
7.2.4.2 ATM data path far-end performance monitoring parameters
7.2.4.2.1 Far-end HEC violation count (HEC-PFE)
The far-end HEC_violation_count performance parameter is a count of the number of occurrences
of a far-end HEC anomaly in the ATM Data Path.
7.2.4.2.2 Far-end delineated total cell count (CD-PFE)
The far-end delineated_total_cell_count performance parameter is a count of the total number of
cells passed through the cell delineation process and HEC function operating on the ATM Data Path
while in the SYNC state.
7.2.4.2.3 Far-end user total cell count (CU-PFE)
The far-end user_total_cell_count performance parameter is a count of the total number of cells in
the ATM Data Path delivered at the V-C (for ATU-C) or T-R (for ATU-R) interface.
7.2.4.2.4 Far-end idle cell bit error count (IBE-PFE)
The far-end idle_bit_error_count performance parameter is a count of the number of bit errors in the
idle cell payload received in the ATM Data Path at the far-end.
7.2.5 PTM data path performance monitoring parameters
This clause defines a set of PTM data path performance monitoring parameters. Support of the
performance parameters in a network element is indicated as mandatory (M) or optional (O) in
Table 7-3b.
7.2.5.1 PTM data path near-end performance monitoring parameters
7.2.5.1.1 Near-end CRC error count (CRC-P)
The CRC-P performance parameter is a count of the number of occurrences of a CRC-n anomaly in
the PTM data path at the near-end.
The CRCP-P performance parameter is a count of the number of occurrences of a CRC-np anomaly
in the PTM data path at the near-end.
7.2.5.1.2 Near-end coding violations count (CV-P)
The CV-P performance parameter is a count of the number of occurrences of a cv-n anomaly in the
PTM data path at the near-end.
The CVP-P performance parameter is a count of the number of occurrences of a cv-np anomaly in
the PTM data path at the near-end.
7.2.5.2 PTM data path far-end performance monitoring parameters
NOTE 1 – The far-end counters are not supported by the indicator bits or EOC messages specified in ITU-T
Rec. G.992.x. They may be provided if the higher layer protocol running over this PTM-TC provides means
(outside the scope of this Recommendation) to retrieve far-end PTM-TC surveillance primitives from the
far-end, or through the OAM communication channel specified in clause 6.

22 ITU-T Rec. G.997.1 (09/2005)

NOTE 2 – In IEEE 802.3ah-2005, the Ethernet management function (residing above the γ reference point)
maps the near-end surveillance primitives and counters (obtained over the γ-interface through access to
clause 45 MDIO registers) into MIB objects defined in clause 30. MIB objects are exchanged with the
far-end using the Ethernet OAM PDU format and protocol defined in clause 57.
7.2.5.2.1 Far-end CRC error count (CRC-PFE)
The far-end CRC-PFE performance parameter is a count at the far-end of the number of
occurrences of a CRC-n anomaly (as observed by the far-end) in the PTM data path.
The far-end CRCP-PFE performance parameter is a count at the far-end of the number of
occurrences of a CRC-np anomaly (as observed by the far-end) in the PTM data path.
7.2.5.2.2 Far-end coding violations count (CV-PFE)
The far-end CV-PFE performance parameter is a count at the far-end of the number of occurrences
of a cv-n anomaly (as observed by the far-end) in the PTM data path.
The far-end CVP-PFE performance parameter is a count of the number of occurrences of a cv-np
anomaly (as observed by the far-end) in the PTM data path.
7.2.6 Performance monitoring data collection
Parameter definitions, failure definitions, and other indications, parameters, and signals are defined
above and in Tables 7-1, 7-2, 7-3 and 7-3b. Functions are indicated as mandatory (M) or optional
(O). Mandatory functions shall be met for performance monitoring. Optional functions should be
provided according to the needs of the users.

Table 7-1/G.997.1 – Line performance monitoring parameter definitions

Text Use at Use at
Name End Definition
subclause ATU-C ATU-R
FECS-L Near M M FEC ≥ 1 for one or more bearer channels
FECS-LFE Far M O FFEC ≥ 1 for one or more bearer channels
ES-L Near M M CRC-8 ≥ 1 for one or more bearer channels
OR LOS ≥ 1 OR SEF ≥ 1 OR LPR ≥ 1
ES-LFE Far M O FEBE ≥ 1 for one or more bearer channels
OR LOS-FE ≥ 1 OR RDI ≥ 1 OR LPR-FE ≥ 1
SES-L Near M M (CRC-8 summed over all bearer channels) ≥ 18
OR LOS ≥ 1 OR SEF ≥ 1 OR LPR ≥ 1
SES-LFE Far M O (FEBE summed over all bearer channels) ≥ 18
OR LOS-FE ≥ 1 OR RDI ≥ 1 OR LPR-FE ≥ 1
LOSS-L Near O O LOS ≥ 1
LOSS-LFE Far O O LOS-FE ≥ 1
UAS-L Near M M A second of unavailability
UAS-LFE Far M O A second of unavailability

ITU-T Rec. G.997.1 (09/2005) 23

 Table 7-1/G.997.1 – Line performance monitoring parameter definitions
NOTE 1 – Note that OR represents a logical OR of two conditions.
NOTE 2 – Unavailability begins at the onset of 10 contiguous severely errored seconds, and ends at the
onset of 10 contiguous seconds with no severely errored seconds.
NOTE 3 – If a common CRC or FEC is applied over multiple bearer channels, then each related CRC-8 or
FEC anomaly shall be counted only once for the whole set of bearer channels over which the CRC or FEC
is applied.
NOTE 4 – If the relevant Recommendation supports one-second normalized CRC counter increments,
these increments shall be used instead of an increment of one for each CRC-8 and FEBE anomaly to
declare SES.

Table 7-2/G.997.1 – Channel performance monitoring parameter definitions

Text Use at Use at
Name End Definition
subclause ATU-C ATU-R
CV-C Near M M Count of CRC-8 anomalies in the bearer channel
CV-CFE Far M O Count of FEBE anomalies in the bearer channel
EC-C Near M M Count of FEC anomalies in the bearer channel
EC-CFE Far M O Count of FFEC anomalies in the bearer channel

Table 7-3/G.997.1 – ATM data path performance monitoring parameter definitions

Text Use at Use at
Name End Definition
subclause ATU-C ATU-R
HEC-P Near M M Count of HEC anomalies in the bearer channel
HEC-PFE Far M O Count of FHEC anomalies in the bearer channel
CD-P Near M M Count of delineated cells in the bearer channel
CD-PFE Far M O Count of delineated cells in the bearer channel
CU-P Near M M Count of cells to user in the bearer channel
CU-PFE Far M O Count of cells to user in the bearer channel
IBE-P Near M M Count of idle cell payload bit errors in the
bearer channel
IBE-PFE Far M O Count of idle cell payload bit errors
in the bearer channel

24 ITU-T Rec. G.997.1 (09/2005)

 Table 7-3b/G.997.1 – PTM data path performance monitoring parameter definitions
Text Use at Use at
Name End Definition
subclause ATU-C ATU-R
CRC-P Near M M Count of non-preemptive packets with CRC
error in the bearer channel
CRC-PFE Far M O Count of non-preemptive packets with CRC
error in the bearer channel
CRCP-P Near M M Count of preemptive packets with CRC error
in the bearer channel
CRCP-PFE Far M O Count of preemptive packets with CRC error
in the bearer channel
CV-P Near M M Count of non-preemptive packets with coding
violation in the bearer channel
CV-PFE Far M O Count of non-preemptive packets with coding
violation in the bearer channel
CVP-P Near M M Count of non-preemptive packets with coding
violation in the bearer channel
CVP-PFE Far M O Count of non-preemptive packets with coding
violation in the bearer channel

The line performance monitoring parameters (Table 7-1) are observed for downstream and
upstream directions. In the downstream direction, the near-end line performance monitoring
parameters are observed by the ATU-R and far-end line performance monitoring parameters are
observed by the ATU-C. In the upstream direction, near-end line performance monitoring
parameters are observed by the ATU-C and far-end line performance monitoring parameters are
observed by the ATU-R.
For a downstream bearer channel, near-end channel (Table 7-2), ATM data path (Table 7-3, if
applicable), and PTM Data Path (Table 7-3b, if applicable) performance monitoring parameters are
observed by the ATU-R and far-end performance monitoring parameters are observed by the
ATU-C. For an upstream bearer channel, near-end channel and ATM data path performance
monitoring parameters are observed by the ATU-C and far-end performance monitoring parameters
are observed by the ATU-R.
7.2.7 Procedures for performance monitoring functions
The functions described in this subclause can be performed inside or outside the network element.
7.2.7.1 Line transmission states
A line can be in one of two transmission states:
• unavailable state;
• available state.
The transmission state is determined from filtered SES/non-SES data. The definition of unavailable
state is defined in 7.2.1.1.5. An ADSL Line is available when it is not unavailable.
7.2.7.2 Threshold reports
A TR is an unsolicited error performance report from a Management Entity (ME) over the
Q-interface and from the ATU-R over the U-interface with respect to either a 15-minute or 24-hour
evaluation period. TRs can only occur when the concerned direction is in the available state. At the
Q-interface, TRs for near-end and far-end ES, SES and UAS parameters are mandatory and TRs for
the other defined parameters are optional. Threshold reports are not provided at the T-/S-interface.

ITU-T Rec. G.997.1 (09/2005) 25

TR1s shall occur within 10 seconds after the 15-minute threshold is reached or exceeded.
TR2s shall occur within 10 seconds after the 24-hour threshold is reached or exceeded.
7.2.7.3 Unavailable and available state filters
The unavailable state filter is a 10-second rectangular sliding window with 1-second granularity of
slide.
The available state filter is also a 10-second rectangular sliding window with 1-second granularity
of slide.
7.2.7.4 TR1 filter
The TR1 filter are 15-minute rectangular fixed windows. The start and end times for the 15-minute
rectangular fixed windows shall fall on the hour and at 15, 30 and 45 minutes after the hour.
7.2.7.5 TR2 filter
The TR2 filter is a 24-hour rectangular fixed window. The start and end times for the 24-hour
rectangular fixed windows shall fall on a 15-minute window boundary.
7.2.7.6 Evaluation of TR1
The parameters are counted separately, second by second, over each 15-minute rectangular fixed
window period. The threshold values should be programmable over the range 0 to 900 with default
values. The default values are given in ITU-T Recs M.2100 and M.2101.
A threshold can be crossed at any second within the 15-minute rectangular fixed window. As soon
as a threshold is crossed, a TR1 as appropriate should be sent to the performance management
centre together with a date/time-stamp. Moreover, performance events should continue to be
counted to the end of the current 15-minute period, at which time the current parameter counts are
stored in the history registers and the current parameter registers are reset to zero.
7.2.7.7 Evaluation of TR2
The parameters are counted separately over each 24-hour period. The threshold values should be
programmable with default values.
The network element shall recognize a 24-hour threshold crossing within 15 minutes of its
occurrence. The threshold crossing shall be given the date/time-stamp of the moment of
recognition. A TR2 as appropriate should be sent to the performance management centre with the
date/time-stamp. Moreover, performance events should continue to be counted to the end of the
current 24-hour period, at which time the parameter counts are stored in the history registers and the
current parameter registers are reset to zero.
7.2.7.8 Threshold report evaluation during transmission state changes
Care should be taken to ensure that threshold reports are correctly generated and parameter counters
are correctly processed during changes in the transmission state. This implies that all threshold
reports should be delayed by 10 seconds (see ITU-T Rec. M.2120).
7.2.7.9 Performance history storage in network elements
The parameters for ME performance history storage at the Q-interface that shall be supported are
ES, SES and UAS. Performance history storage for the other defined parameters is optional.
There shall be a current 15-minute (which can also facilitate the TR1 filter) register plus a further N
15-minute history registers for each parameter in each ME. The N 15-minute history registers are
used as a stack, i.e., the value held in each register is pushed down the stack one place at the end of
each 15-minute period, and the oldest register value at the bottom of the stack is discarded.

26 ITU-T Rec. G.997.1 (09/2005)

The N for the parameters ES, SES and UAS shall be at least 16. For the other parameters, N shall be
at least 1 (i.e., only current and previous value is required).
There shall be a current 24-hour register (which can also facilitate the TR2 filter) plus one previous
24-hour register for each parameter.
As a minimum, an invalid data flag shall be provided for each stored interval for each direction for
each monitored transmission entity. For example:
An invalid data flag is set to indicate that the data stored is incomplete or otherwise invalid when:
• The data in the previous and recent intervals has been accumulated over a period of time
that is greater or less than the nominal accumulation period duration.
• The data in the current interval is suspect because a terminal is restarted or a register is reset
in the middle of an accumulation period.
• The data is incomplete in an accumulation period. For example, an incoming transmission
failure or defect may prevent complete collection of far-end performance reports.
The invalid data flag is not set as a result of register saturation.
7.2.7.10 Register size
Every performance parameter register shall be large enough to accumulate all integer numbers from
zero to a particular maximum value, which determines the minimum register size for that parameter.
When the maximum value of a register is reached, the register shall remain at that maximum value
until it is reset, or the value is transferred or discarded, as described in this clause. Minimum
register sizes are 16 bits.
7.2.7.11 Parameter counts
All parameter counts shall be actual counts for the 15-minute filtering period.
Although all parameter counts should (ideally) also be actual for the 24-hour filtering periods, it is
recognized that it might be desirable to limit register sizes. In such cases, register overflow may
occur. Should register overflow occur, the registers shall hold their maximum value for the
parameter considered until the registers are read and reset at the end of the 24-hour period. An
implementation involving setting and resetting an overflow bit may be used.
7.2.7.12 Date/time-stamping of reports
The date/time-stamping accuracy of reports, together with the method of maintaining the accuracy,
is under study.
The format for date/time-stamps is as follows:
• 15-minute window will be stamped Year, Month, Day, Hour, Minute;
• 24-hour window will be stamped Year, Month, Day, Hour;
• Unavailable Time events will be stamped Year, Month, Day, Hour, Minute, Second;
• Alarms will be stamped either at the declaration of the alarm by the equipment or at the
exact time of the event (to be decided) with Year, Month, Day, Hour, Minute, Second.
Equipment clock accuracy requirements are for further study.
7.2.7.13 Inhibiting performance monitoring parameters
For a given monitored entity, the accumulation of certain performance parameters is inhibited
during periods of unavailability, during SESs or during seconds containing defects on that
monitored entity. Inhibiting on a given monitored entity (e.g., ADSL ATM Data Path) is not
explicitly effected by conditions on any other monitored entity (ADSL line). The inhibiting rules
are as follows:

ITU-T Rec. G.997.1 (09/2005) 27

• UAS and Failure Count parameters shall not be inhibited.
• All other performance parameter counts shall be inhibited during UAS and SES. Inhibiting
shall be retroactive to the onset of unavailable time and shall end retroactively to the end of
unavailable time.

7.3 Configuration functions

7.3.1 Line configuration parameters
7.3.1.1 State configuration parameters
7.3.1.1.1 ATU Transmission System Enabling (ATSE)
This configuration parameter defines the transmission system coding types to be allowed by the
near-end ATU on this line. This parameter only applies to the Q-interface. It is coded in a bit-map
representation (0 if not allowed, 1 if allowed) with following definition:
Bit Representation
Octet 1
1 Regional standards (see Note).
2 Regional standards (see Note).
3 G.992.1 operation over POTS non-overlapped spectrum (Annex A/G.992.1).
4 G.992.1 operation over POTS overlapped spectrum (Annex A/G.992.1).
5 G.992.1 operation over ISDN non-overlapped spectrum (Annex B/G.992.1).
6 G.992.1 operation over ISDN overlapped spectrum (Annex B/G.992.1).
7 G.992.1 operation in conjunction with TCM-ISDN non-overlapped spectrum
(Annex C/G.992.1).
8 G.992.1 operation in conjunction with TCM-ISDN overlapped spectrum
(Annex C/G.992.1).
Octet 2
9 G.992.2 operation over POTS non-overlapped spectrum (Annex A/G.992.2).
10 G.992.2 operation over POTS overlapped spectrum (Annex B/G.992.2).
11 G.992.2 operation in conjunction with TCM-ISDN non-overlapped spectrum
(Annex C/G.992.2).
12 G.992.2 operation in conjunction with TCM-ISDN overlapped spectrum
(Annex C/G.992.2).
13 Reserved.
14 Reserved.
15 Reserved.
16 Reserved.
Octet 3
17 Reserved.
18 Reserved.
19 G.992.3 operation over POTS non-overlapped spectrum (Annex A/G.992.3).
20 G.992.3 operation over POTS overlapped spectrum (Annex A/G.992.3).
21 G.992.3 operation over ISDN non-overlapped spectrum (Annex B/G.992.3).
22 G.992.3 operation over ISDN overlapped spectrum (Annex B/G.992.3).

28 ITU-T Rec. G.997.1 (09/2005)

23 Reserved.
24 Reserved.
Octet 4
25 G.992.4 operation over POTS non-overlapped spectrum (Annex A/G.992.4).
26 G.992.4 operation over POTS overlapped spectrum (Annex A/G.992.4).
27 Reserved.
28 Reserved.
29 G.992.3 All Digital Mode operation with non-overlapped spectrum (Annex I/G.992.3).
30 G.992.3 All Digital Mode operation with overlapped spectrum (Annex I/G.992.3).
31 G.992.3 All Digital Mode operation with non-overlapped spectrum (Annex J/G.992.3).
32 G.992.3 All Digital Mode operation with overlapped spectrum (Annex J/G.992.3).
Octet 5
33 G.992.4 All Digital Mode operation with non-overlapped spectrum (Annex I/G.992.4).
34 G.992.4 All Digital Mode operation with overlapped spectrum (Annex I/G.992.4).
35 G.992.3 Reach Extended operation over POTS, Mode 1 (non-overlapped, wide upstream)
(Annex L/G.992.3).
36 G.992.3 Reach Extended operation over POTS, Mode 2 (non-overlapped, narrow upstream)
(Annex L/G.992.3).
37 G.992.3 Reach Extended operation over POTS, Mode 3 (overlapped, wide upstream)
(Annex L/G.992.3).
38 G.992.3 Reach Extended operation over POTS, Mode 4 (overlapped, narrow upstream)
(Annex L/G.992.3).
39 G.992.3 Extended upstream operation over POTS non-overlapped spectrum (Annex
M/G.992.3).
40 G.992.3 Extended upstream operation over POTS overlapped spectrum (Annex
M/G.992.3).
Octet 6
41 G.992.5 operation over POTS non-overlapped spectrum (Annex A/G.992.5).
42 G.992.5 operation over POTS overlapped spectrum (Annex A/G.992.5).
43 G.992.5 operation over ISDN non-overlapped spectrum (Annex B/G.992.5).
44 G.992.5 operation over ISDN overlapped spectrum (Annex B/G.992.5).
45 Reserved.
46 Reserved.
47 G.992.5 All Digital Mode operation with non-overlapped spectrum (Annex I/G.992.5).
48 G.992.5 All Digital Mode operation with overlapped spectrum (Annex I/G.992.5).
Octet 7
49 G.992.5 All Digital Mode operation with non-overlapped spectrum (Annex J/G.992.5).
50 G.992.5 All Digital Mode operation with overlapped spectrum (Annex J/G.992.5).
51 G.992.5 Extended upstream operation over POTS non-overlapped spectrum
(Annex M/G.992.5).
52 G.992.5 Extended upstream operation over POTS overlapped spectrum
(Annex M/G.992.5).

ITU-T Rec. G.997.1 (09/2005) 29

53 Reserved.
54 Reserved.
55 Reserved.
56 Reserved.
NOTE – It is recommended that the bit 1 be used for the ANSI T1.413-1998* Standard. It is recommended
that the bit 2 be used for the Annex C of TS 101 388 v1.3.1.
7.3.1.1.2 ATU impedance state forced (AISF)
This configuration parameter defines the impedance state to be forced on the near-end ATU. It
applies only to the T-/S-interface. It is coded as an integer value with following definition:
1) Force the near-end ATU to the disabled state.
2) Force the near-end ATU to the inactive state.
3) Force the near-end ATU to the active state.
Impedance states only to the Annex A/G.992.3 operation mode and are defined in A.4.1/G.992.3.
7.3.1.1.3 Power management state forced (PMSF)
This configuration parameter defines the line states to be forced by the near-end ATU on this line. It
is coded as an integer value with following definition:
0 Force the line to transition from the L3 idle state to the L0 full-on state. This transition
requires the (short) initialization procedures. After reaching the L0 state, the line may
transition into or exit from the L2 low power state (if L2 state is enabled). If the L0 state is
not reached (after a vendor discretionary number of retries and/or within a vendor
discretionary timeout), then an Initialization Failure occurs. Whenever the line is in the
L3 state, attempts shall be made to transition to the L0 state until it is forced into another
state through this configuration parameter.
2 Force the line to transition from L0 full on to L2 low power state. This transition requires
the entry into L2 mode. This is a out-of-service test value for triggering the L2 mode.
3 Force the line to transition from the L0 full-on or L2 low power state to the L3 idle state.
This transition requires the (orderly) shutdown procedure. After reaching the L3 state, the
line shall remain in the L3 idle state until it is forced into another state through this
configuration parameter.
Forced line state transitions require the line to enter or exit from the L3 idle state. These transitions
are not restricted by the Line state enabling parameter value.
NOTE – This configuration parameter maps to the AdminStatus of the line, which is part of the
GeneralInformationGroup object group specified in RFC 2233, and may not need to be duplicated in the
ADSL MIB. See also RFC 2662. The Administrative Status of the line is UP when the line is forced to the
L0 state and is DOWN when the line is forced to the L3 state.
7.3.1.1.4 Power management state enabling (PMMode)
This configuration parameter defines the line states the ATU-C or ATU-R may autonomously
transition to on this line. It is coded in a bit-map representation (0 if not allowed, 1 if allowed) with
following definition:
Bit 0 L3 state (Idle state);
Bit 1 L1/L2 state (Low power state).

____________________
* T1 standards are maintained since November 2003 by ATIS.

30 ITU-T Rec. G.997.1 (09/2005)

7.3.1.1.5 Minimum L0 time interval between L2 exit and next L2 entry (L0-TIME)
This parameter represents the minimum time (in seconds) between an Exit from the L2 state and the
next Entry into the L2 state. It ranges from 0 to 255 seconds.
7.3.1.1.6 Minimum L2 time interval between L2 entry and first L2 trim (L2-TIME)
This parameter represents the minimum time (in seconds) between an Entry into the L2 state and
the first Power Trim in the L2 state and between two consecutive Power Trims in the L2 State.
It ranges from 0 to 255 seconds.
7.3.1.1.7 Maximum aggregate transmit power reduction per L2 request or L2 trim
(L2-ATPR)
This parameter represents the maximum aggregate transmit power reduction (in dB) that can be
performed in the L2 Request (i.e., at transition of L0 to L2 state) or through a single Power Trim in
the L2 state. It ranges from 0 dB to 31 dB.
7.3.1.1.8 Loop diagnostics mode forced (LDSF)
This configuration parameter defines whether the line should be forced into the loop diagnostics
mode by the near-end ATU on this line. It is coded as an integer value with following definition:
0 Inhibits the near-end ATU from performing loop diagnostics mode procedures on the line.
Loop diagnostic mode procedures may still be initiated by the far-end ATU.
1 Forces the near-end ATU to perform the loop diagnostics procedures.
The line needs to be forced to the L3 state (see 7.3.1.1.3) before it can be forced to the loop
diagnostics mode. Only while the line power management state is the L3 state (see 7.5.1.2), the line
can be forced into the loop diagnostics mode procedures. When the loop diagnostics mode
procedures are completed successfully, the Access Node shall reset the LDSF MIB element to 0 and
the line shall return to remain in the L3 idle state. The loop diagnostics data shall be available at
least until the line is forced to the L0 state (see 7.3.1.1.3). If the loop diagnostics procedures cannot
be completed successfully, (after a vendor discretionary number of retries and/or within a vendor
discretionary timeout), then an Initialization Failure occurs. As long as loop diagnostics procedures
are not completed successfully, attempts shall be made to do so, until the loop diagnostics mode is
no longer forced on the line through this configuration parameter.
7.3.1.1.9 Total maximum aggregate transmit power reduction in L2 (L2-ATPRT)
This parameter represents the total maximum aggregate transmit power reduction (in dB) that can
be performed in an L2 state. This is the sum of all reductions of L2 Request (i.e., at transition of L0
to L2 state) and Power Trims. It ranges from 0 dB to 31 dB.
7.3.1.1.10 Automode cold start forced
This parameter is defined in order to improve testing of the performance of ATUs supporting
automode when it is enabled in the MIB. The valid values are 0 and 1. A change in value of this
parameter indicates a change in loop conditions applied to the devices under test. The ATUs shall
reset any historical information used for automode and for shortening G.994.1 handshake and
initialization.
Automode is defined as the case where multiple operation-modes are enabled in the MIB in the
G.997.1 "ATU Transmission System Enabling (ATSE)" table and where the selection of the
operation-mode to be used for transmission does not only depend on the common capabilities of
both ATUs (as exchanged in G.994.1), but depends also on achievable data rates under given loop
conditions.
This parameter is mandatory at the Q interface for modems supporting automode.

ITU-T Rec. G.997.1 (09/2005) 31

7.3.1.2 Power/PSD configuration parameters
7.3.1.2.1 Downstream maximum nominal power spectral density (MAXNOMPSDds)
This parameter represents the maximum nominal transmit PSD in the downstream direction during
initialization and showtime (in dBm/Hz). A single MAXNOMPSDds parameter is defined per mode
enabled in the ATSE line configuration parameter. It ranges from –60 to –30 dBm/Hz, with 0.1 dB
steps.
7.3.1.2.2 Upstream maximum nominal power spectral density (MAXNOMPSDus)
This parameter represents the maximum nominal transmit PSD in the upstream direction during
initialization and showtime (in dBm/Hz). A single MAXNOMPSDus parameter is defined per mode
enabled in the ATSE line configuration parameter. It ranges from –60 to –30 dBm/Hz, with 0.1 dB
steps.
7.3.1.2.3 Downstream maximum nominal aggregate transmit power (MAXNOMATPds)
This parameter represents the maximum nominal aggregate transmit power in the downstream
direction during initialization and showtime (in dBm). It ranges from 0 to 25.5 dBm,
with 0.1 dB steps.
7.3.1.2.4 Upstream maximum nominal aggregate transmit power (MAXNOMATPus)
This parameter represents the maximum nominal aggregate transmit power in the upstream
direction during initialization and showtime (in dBm). It ranges from 0 to 25.5 dBm, with 0.1 dB
steps.
7.3.1.2.5 Upstream maximum aggregate receive power (MAXRXPWRus)
This parameter represents the maximum upstream aggregate receive power over a set of subcarriers
(in dBm) as specified in the relevant Recommendation. The ATU-C shall request an upstream
power cutback such that the upstream aggregate receive power over that set of subcarriers is at or
below the configured maximum value. It ranges from –25.5 to 25.5 dBm, with 0.1 dB steps. A
special value is used to indicate that no Upstream Maximum Aggregate Receive Power limit is to be
applied (i.e., the maximum value is infinite).
7.3.1.2.6 Downstream subcarrier masking (CARMASKds)
This configuration parameter is an array of boolean values sc(i). Each entry sc(i) defines whether
subcarrier index i is masked on this line in the downstream direction, for i ranging from 0 to
NSCds-1. It is coded as 1 if masked and 0 if not masked. This parameter only applies to the
Q-interface.
NSCds is the higher subcarrier that can be transmitted in the downstream direction. For G.992.3 and
G.992.4, it is defined in the corresponding Recommendations. For G.992.1, NSCds = 256 and for
G.992.2, NSCds = 128.
7.3.1.2.7 Upstream subcarrier masking/enabling (CARMASKus)
This configuration parameter is an array of boolean values sc(i). Each entry sc(i) defines whether
transmission of subcarrier index i is allowed on this line in the upstream direction, for i ranging
from 0 to NSCus-1. It is coded as 0 if not allowed and 1 if allowed. This parameter only applies to
the Q-interface.
NSCus is the higher subcarrier that can be transmitted in the upstream direction. For G.992.3 and
G.992.4, it is defined in the corresponding Recommendation. For Annex A/G.992.1 and G.992.2,
NSCus = 32 and for Annex B/G.992.1, NSCus = 64.

32 ITU-T Rec. G.997.1 (09/2005)

7.3.1.2.8 Downstream PSD mask (PSDMASKds)
This configuration parameter defines the downstream PSD mask applicable at the U-C2 reference
point. This MIB PSD mask may impose PSD restrictions in addition to the Limit PSD mask defined
in the relevant Recommendation (e.g., ITU-T Rec. G.992.5).
The downstream PSD mask in the CO-MIB shall be specified through a set of breakpoints. Each
breakpoint shall consist of a subcarrier index t and a MIB PSD mask level (expressed in dBm/Hz) at
that subcarrier. The set of breakpoints can then be represented as [(t1, PSD1), (t2, PSD2), ... , (tN,
PSDN)]. The subcarrier index shall be coded as an unsigned integer. The MIB PSD mask level shall
be coded as an unsigned integer representing the MIB PSD mask levels 0 dBm/Hz (coded as 0) to
–127.5 dBm/Hz (coded as 255), in steps of 0.5 dBm/Hz, with valid range from 0 to –95dBm/Hz.
The maximum number of breakpoints is 32.
The requirements for a valid set of breakpoints are defined in the relevant Recommendations
(e.g., ITU-T Rec. G.992.5).
7.3.1.2.9 Downstream RFI bands (RFIBANDSds)
This configuration parameter defines the subset of downstream PSD mask breakpoints, as specified
in PSDMASKds, that shall be used to notch an RFI band. This subset consists of couples of
consecutive subcarrier indices belonging to breakpoints: [ti; ti + 1], corresponding to the low level
of the notch.
The specific interpolation around these points is defined in the relevant Recommendations
(e.g., ITU-T Rec. G.992.5).
The CO-MIB shall define the RFI notches using breakpoints in PSDMASKds as specified in the
relevant Recommendations (e.g., ITU-T Rec. G.992.5).
7.3.1.2.10 Upstream PSD mask selection
This configuration parameter defines which upstream PSD mask is enabled. This parameter is used
only for Annexes J and M of ITU-T Recs G.992.3 and G.992.5. As only one selection parameter is
defined in the MIB, the same selection value applies to all relevant modes enabled in the ATSE line
configuration parameter. It ranges from 1 to 9 and selects the mask with the following definition.

Selected mask
Upstream PSD mask
selection value Annex J of G.992.3 Annex M of G.992.3
and G.992.5 and G.992.5
1 ADLU-32 EU-32
2 ADLU-36 EU-36
3 ADLU-40 EU-40
4 ADLU-44 EU-44
5 ADLU-48 EU-48
6 ADLU-52 EU-52
7 ADLU-56 EU-56
8 ADLU-60 EU-60
9 ADLU-64 EU-64

ITU-T Rec. G.997.1 (09/2005) 33

7.3.1.2.11 Upstream PSD mask (PSDMASKus)
This configuration parameter defines the upstream PSD mask applicable at the U-R2 reference
point. This MIB PSD mask may impose PSD restrictions in addition to the Limit PSD mask defined
in the relevant Recommendations (e.g., ITU-T Rec. G.992.3).
The upstream PSD mask in the CO-MIB shall be specified through a set of breakpoints. Each
breakpoint shall consist of a subcarrier index t and a MIB PSD mask level (expressed in dBm/Hz)
at that subcarrier. The set of breakpoints can then be represented as [(t1, PSD1), (t2, PSD2), ... ,
(tN, PSDN)]. The subcarrier index shall be coded as an unsigned integer. The MIB PSD mask level
shall be coded as an unsigned integer representing the MIB PSD mask levels 0 dBm/Hz (coded
as 0) to –127.5 dBm/Hz (coded as 255), in steps of 0.5 dBm/Hz, with valid range from 0 to
–95 dBm/Hz. The maximum number of breakpoints is 4.
The requirements for a valid set of breakpoints are defined in the relevant Recommendations
(e.g., ITU-T Rec. G.992.3).
7.3.1.3 Noise margin configuration parameters
The following configuration parameters are defined to control the Noise Margin in the receive
direction in the ATU. A downstream Noise Margin applies to the ATU-R, an upstream Noise
Margin applies to the ATU-C.
NOTE – The Noise Margin should be controlled to ensure operation at the target BER (Bit Error Ratio) for
each of the received bearer channels, or better. Figure 7-3 shows the relationship between these parameters.
They will be described in detail in the following subclauses.

Reduce Power
Maximum Noise Margin ----------------------------------------------------------------------
Increase Rate if Noise Margin > Upshift Noise Margin
for Upshift Interval
Upshift Noise Margin ----------------------------------------------------------------------
Steady State Operation
Target Noise Margin ----------------------------------------------------------------------
Steady State Operation
Downshift Noise Margin ------------------------------------------------------------ ----------
Decrease Rate if Noise Margin < Downshift Noise Margin
for Downshift Interval
Minimum Noise Margin ----------------------------------------------------------------------
Increase Power. If not possible – reinitialize

NOTE 1 – Upshift Noise Margin, and Downshift Noise Margin are only supported for Rate Adaptive Mode.
NOTE 2 – Minimum Noise Margin ≤ Downshift Noise Margin ≤ Target Noise Margin ≤ Upshift Noise Margin ≤ Maximum Noise
Margin.

Figure 7-3/G.997.1 – Noise margins

7.3.1.3.1 Downstream target noise margin (TARSNRMds)

This is the Noise Margin the ATU-R receiver shall achieve, relative to the BER requirement for
each of the downstream bearer channels, or better, to successfully complete initialization. The target
noise margin ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.3.2 Upstream target noise margin (TARSNRMus)
This is the noise margin the ATU-C receiver shall achieve, relative to the BER requirement for each
of the upstream bearer channels, or better, to successfully complete initialization. The target noise
margin ranges from 0 to 31 dB with 0.1 dB steps.

34 ITU-T Rec. G.997.1 (09/2005)

7.3.1.3.3 Downstream maximum noise margin (MAXSNRMds)
This is the maximum noise margin the ATU-R receiver shall try to sustain. If the noise margin is
above this level, the ATU-R shall request the ATU-C to reduce the ATU-C transmit power to get a
noise margin below this limit (if this functionality is supported – see Note). The maximum noise
margin ranges from 0 to 31 dB with 0.1 dB steps. A special value is used to indicate that no
maximum noise margin limit is to be applied (i.e., the maximum value is infinite).
NOTE – This functionality should be supported by ADSL transmission systems. This functionality shall be
supported by ADSL2 transmission systems.
7.3.1.3.4 Upstream maximum noise margin (MAXSNRMus)
This is the maximum noise margin the ATU-C receiver shall try to sustain. If the noise margin is
above this level, the ATU-C shall request the ATU-R to reduce the ATU-R transmit power to get a
noise margin that is below this limit (if this functionality is supported – see Note). The maximum
noise margin ranges from 0 to 31 dB with 0.1 dB steps. A special value is used to indicate that no
maximum noise margin limit is to be applied (i.e., the maximum value is infinite).
NOTE – This functionality should be supported by ADSL transmission systems. This functionality shall be
supported by ADSL2 transmission systems.
7.3.1.3.5 Downstream minimum noise margin (MINSNRMds)
This is the minimum noise margin the ATU-R receiver shall tolerate. If the noise margin falls below
this level, the ATU-R shall request the ATU-C to increase the ATU-C transmit power. If an
increase to ATU-C transmit power is not possible, a loss-of-margin (LOM) defect occurs, the
ATU-R shall fail and attempt to re-initialize and the NMS shall be notified. The minimum noise
margin ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.3.6 Upstream minimum noise margin (MINSNRMus)
This is the minimum noise margin the ATU-C receiver shall tolerate. If the noise margin falls below
this level, the ATU-C shall request the ATU-R to increase the ATU-R transmit power. If an
increase of ATU-R transmit power is not possible, a loss-of-margin (LOM) defect occurs, the
ATU-C shall fail and attempt to re-initialize and the NMS shall be notified. The minimum noise
margin ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.4 Rate adaptation configuration parameters
The following configuration parameters are defined to manage the rate-adaptive behaviour in the
transmit direction for both the ATU-C and the ATU-R. An ATU-C rate adaptation mode applies to
the upstream direction. An ATU-R rate adaptation mode applies to the downstream direction.
7.3.1.4.1 Downstream rate adaptation mode (RA-MODEds)
This parameter specifies the mode of operation of a rate-adaptive ATU-C in the transmit direction.
The parameter can take three values.
Mode 1: MANUAL – Rate changed manually.
At startup
The Downstream Minimum Data Rate parameter specifies the data rate the ATU-C transmitter shall
operate at for each of the bearer channels, with a downstream noise margin which is at least as large
as the specified Downstream Target Noise Margin, relative to the required BER for each of the
downstream bearer channels, or better. If the ATU-C fails to achieve the Downstream Minimum
Data Rate for one of the bearer channels, the ATU-C will fail to initialize, and the NMS will be
notified. Although the ATU-C and the line might be able to support a higher data rate, the ATU-C
shall not transmit a higher data rate than what is requested for each of the bearer channels.

ITU-T Rec. G.997.1 (09/2005) 35

At showtime
The ATU-C transmitter shall maintain the specified Downstream Minimum Data Rate for each of
the bearer channels.
Mode 2: AT_INIT – Rate automatically selected at startup only and does not change after that.
At startup
The Downstream Minimum Rate parameter specifies the minimum data rate the ATU-C transmitter
shall operate as for each of the bearer channels, with a downstream noise margin which is at least as
large as the specified Downstream Target Noise Margin, relative to the required BER for each of
the bearer channels, or better. If the ATU-C fails to achieve the Downstream Minimum Data Rate
for one of the bearer channels, the ATU-C will fail to initialize, and the NMS will be notified. If the
ATU-C transmitter is able to support a higher downstream data rate at initialization, the excess data
rate will be distributed amongst the downstream bearer channels according to the ratio (0 to 100%)
specified by the Rate Adaptation Ratio parameter for each bearer channel (adding up to 100% over
all bearer channels). When the Downstream Maximum Data Rate is achieved in one of the bearer
channels, then the remaining excess bit rate is assigned to the other bearer channels, still according
to their relative Rate Adaptation Ratio parameters. As long as the downstream data rate is below the
Downstream maximum Data Rate for one of the bearer channels, data rate increase shall take
priority over transmit power reduction.
At showtime
During showtime, no downstream data rate adaptation is allowed. The downstream data rate, which
has been settled during initialization for each of the bearer channels, shall be maintained.
Mode 3: DYNAMIC – Data rate is automatically selected at initialization and is continuously
adapted during operation (showtime). The DYNAMIC rate adaptation mode is optional. All related
configuration parameters are also optional.
At startup
In Mode 3, the ATU-C shall start up as in Mode 2.
At showtime
During showtime, rate adaptation is allowed with respect to the Ratio Adaptation Ratio for
distributing the excess data rate amongst the bearer channels (see Mode 2), and assuring that the
Downstream Minimum Data Rate remains available at the required BER for each of the bearer
channels or better. The downstream data rate can vary between the Downstream Minimum Data
Rate, and the Downstream Maximum Data Rate. Downstream Rate Adaptation is performed when
the conditions specified for Downstream Upshift Noise Margin and Downstream Upshift Interval,
or for Downstream Downshift Noise Margin and Downstream Downshift Interval, are satisfied.
This means:
– For an Upshift action: Allowed when the downstream noise margin is above the
Downstream Upshift Noise Margin during Downstream Minimum Time Interval for
Upshift Rate Adaptation (i.e., upon RAU anomaly).
– For a Downshift action: Allowed when the downstream noise margin is below the
Downstream Downshift Noise Margin during Downstream Minimum Time Interval for
Downshift Rate Adaptation (i.e., upon RAD anomaly).
As long as the downstream data rate is below the Downstream Maximum Data Rate for one of the
bearer channels, data rate increase shall take priority over transmit power reduction.

36 ITU-T Rec. G.997.1 (09/2005)

7.3.1.4.2 Upstream rate adaptation mode (RA-MODEus)
This parameter specifies the mode of operation of a rate-adaptive ATU-R in the transmit direction.
The parameter is used only if the rate-adaptive functionality is supported and can take three values
(MANUAL, AT_INIT, DYNAMIC). The definition of each of the values is identical to their
definition in the Downstream Rate Adaptation Mode (with replacing of ATU-C with ATU-R and
downstream with upstream).
7.3.1.4.3 Downstream upshift noise margin (RA-USNRMds)
If the downstream noise margin is above the downstream upshift noise margin and stays above that
for more than the time specified by the downstream minimum upshift rate adaptation interval, the
ATU-R shall attempt to increase the downstream net data rate. The downstream upshift noise
margin ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.4.4 Upstream upshift noise margin (RA-USNRMus)
If the upstream noise margin is above the upstream upshift noise margin and stays above that for
more than the time specified by the upstream minimum upshift rate adaptation interval, the ATU-C
shall attempt to increase the upstream net data rate. The upstream upshift noise margin ranges from
0 to 31 dB with 0.1 dB steps.
7.3.1.4.5 Downstream minimum time interval for upshift rate adaptation (RA-UTIMEds)
This parameter defines the interval of time the downstream noise margin should stay above the
downstream upshift noise margin before the ATU-R shall attempt to increase the downstream net
data rate. The time interval ranges from 0 to 16383 s.
7.3.1.4.6 Upstream minimum time interval for upshift rate adaptation (RA-UTIMEus)
This parameter defines the interval of time the upstream noise margin should stay above the
upstream upshift noise margin before the ATU-C shall attempt to increase the upstream net data
rate. The time interval ranges from 0 to 16383 s.
7.3.1.4.7 Downstream downshift noise margin (RA-DSNRMds)
If the downstream noise margin is below the downstream downshift noise margin and stays below
that for more than the time specified by the downstream minimum downshift rate adaptation
interval, the ATU-R shall attempt to decrease the downstream net data rate. The downstream
downshift noise margin ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.4.8 Upstream downshift noise margin (RA-DSNRMus)
If the upstream noise margin is below the upstream downshift noise margin and stays below that for
more than the time specified by the upstream minimum downshift rate adaptation interval, the
ATU-C shall attempt to decrease the upstream net data rate. The upstream downshift noise margin
ranges from 0 to 31 dB with 0.1 dB steps.
7.3.1.4.9 Downstream minimum time interval for downshift rate adaptation (RA-DTIMEds)
This parameter defines the interval of time the downstream noise margin should stay below the
downstream downshift noise margin before the ATU-R shall attempt to decrease the downstream
net data rate. The time interval ranges from 0 to 16383 s.
7.3.1.4.10 Upstream minimum time interval for downshift rate adaptation (RA-DTIMEus)
This parameter defines the interval of time the upstream noise margin should stay below the
upstream downshift noise margin before the ATU-C shall attempt to decrease the upstream net data
rate. The time interval ranges from 0 to 16383 s.

ITU-T Rec. G.997.1 (09/2005) 37

7.3.1.5 Line overhead configuration parameters
These parameters are used for testing purpose.
7.3.1.5.1 Minimum overhead rate upstream (MSGMINus)
This parameter defines the minimum rate of the message-based overhead that shall be maintained
by the ATU in the upstream direction. MSGMINus is expressed in bits per second and ranges from
4000 to 63 000 bit/s.
7.3.1.5.2 Minimum overhead rate downstream (MSGMINds)
This parameter defines the minimum rate of the message-based overhead that shall be maintained
by the ATU in the downstream direction. MSGMINds is expressed in bits per second and ranges
from 4000 to 63 000 bit/s.
7.3.1.6 Line performance monitoring parameter thresholds
All line performance monitoring parameters (counters, see Table 7-1) shall have an individual
15-minute and 24-hour threshold parameter if supported.
7.3.2 Channel configuration parameters
7.3.2.1 Data rate configuration parameters
These data rate parameters refer to the transmit direction for both the ATU-C and the ATU-R and
apply to the configuration of an individual upstream or downstream bearer channel. The two data
rate parameters define the data rate minimum and maximum bounds as specified by the operator of
the system (the operator of the ATU-C). It is assumed that the ATU-C and the ATU-R will interpret
the value set by the operator as appropriate for the specific implementation of ADSL between the
ATU-C and the ATU-R in setting the line rates. This model defined in this interface makes no
assumptions about the possible range of these attributes. The Network Management System used by
the operator to manage the ATU-R and the ATU-C may implement its own limits on the allowed
values for the desired bit rate parameters based on the particulars of the system managed. The
definition of such a system is outside the scope of this model.
7.3.2.1.1 Minimum data rate
This parameter specifies the minimum net data rate for the bearer channel as desired by the operator
of the system. The rate is coded in bit/s.
7.3.2.1.2 Minimum reserved data rate
This parameter specifies the minimum reserved net data rate for the bearer channel as desired by the
operator of the system. The rate is coded in bit/s.
This parameter is optional. It is used only if the Rate Adaptation Mode is set to DYNAMIC.
7.3.2.1.3 Maximum data rate
This parameter specifies the maximum net data rate for the bearer channel as desired by the
operator of the system. The data rate is coded in bit/s.
7.3.2.1.4 Rate adaptation ratio
This parameter (expressed in %) specifies the ratio that should be taken into account for the bearer
channel when performing rate adaptation in the direction of the bearer channel. The ratio is defined
as a percentage in the 0 to 100 range. A ratio of 20% means that 20% of the available data rate (in
excess of the Minimum Data Rate summed over all bearer channels) will be assigned to this bearer
channel and 80% to the other bearer channels.
The sum of rate adaptation ratios over all bearers in one direction shall be equal to 100%.

38 ITU-T Rec. G.997.1 (09/2005)

7.3.2.1.5 Minimum data rate in low power state
This parameter specifies the minimum net data rate for the bearer channel as desired by the operator
of the system during the low power state (L1/L2). The power management low power states L1 and
L2 are defined in ITU-T Recs G.992.2 and G.992.3 respectively. The data rate is coded in bit/s.
7.3.2.2 Maximum interleaving delay
This parameter is the maximum one-way interleaving delay introduced by the PMS-TC between the
alfa and the beta reference points, in the direction of the bearer channel. The one-way interleaving
delay is defined in individual ADSL Recommendations as S*D /4 ms, where "S" is the S-factor
and "D" is the "Interleaving Depth" and x denotes rounding to the higher integer.
The ATUs shall choose the S and D values such that the actual one-way interleaving delay (see
Actual Interleaving Delay status parameter in 7.5.2.3) is less or equal than the configured Maximum
Interleaving Delay. The delay is coded in ms, with the value 0 and 1 special values. The value 0
indicates no delay bound is being imposed. The value 1 indicates the Fast Latency Path shall be
used in the G.992.1 operating mode and S and D shall be selected such that S ≤ 1 and D = 1 in
ITU-T Recs G.992.2, G.992.3 and G.992.4 operating modes.
NOTE – A single Maximum Delay value is configured. As a consequence, ATUs supporting multiple ADSL
Recommendations will use the configured value regardless of the operating mode actually being selected at
line initialization.
7.3.2.3 Minimum impulse noise protection
This parameter specifies the minimum impulse noise protection for the bearer channel. The impulse
noise protection is expressed in symbols and can take the values ½, and 0 to 16 symbols by step
of 1.
7.3.2.4 Maximum bit error ratio
This parameter specifies the maximum bit error ratio for the bearer channel as desired by the
operator of the system. The bit error ratio can take the values 1E-3, 1E-5 or 1E-7.
NOTE – ATUs supporting multiple ADSL Recommendations may use or ignore the configured value
depending on the operating mode actually being selected at line initialization. In ITU-T Rec. G.992.3, the
ATUs will use the configured value. In ITU-T Rec. G.992.1, ATUs operate with the Maximum Bit Error
Ratio fixed to 1E-7, regardless of the configured value.
7.3.2.5 Channel performance monitoring parameter thresholds
All Channel performance monitoring parameters (counters, see Table 7-2) shall have an individual
15-minute and 24-hour threshold parameter if supported.
7.3.2.6 Channel data rate thresholds
The data rate threshold parameter procedures shall be as defined in 7.2.7.
7.3.2.6.1 Data rate threshold upshift
This parameter is a threshold on the net data rate upshift achieved over one or more bearer channel
data rate adaptations. An upshift rate change alarm (event) is triggered when the actual data rate
exceeds the data rate at the last entry into showtime by more than the threshold. The data rate
threshold is coded in bit/s.
7.3.2.6.2 Data rate threshold downshift
This parameter is a threshold on the net data rate downshift achieved over one or more bearer
channel data rate adaptations. A downshift rate change alarm (event) is triggered when the actual
data rate is below the data rate at the last entry into showtime by more than the threshold. The data
rate threshold is coded in bit/s.

ITU-T Rec. G.997.1 (09/2005) 39

7.3.3 STM data path configuration parameters
No STM data path configuration parameters are defined.
7.3.4 ATM data path configuration parameters
7.3.4.1 IMA operation mode enable parameter
This parameter enables the IMA operation mode in the ATM data path. It shall indicate to the ATM
data path that he must comply to the requirements for IMA transmission, i.e., minimum amount of
idle cells shall be inserted and no cell discard shall be enabled at the receiver.
7.3.4.2 ATM data path performance monitoring parameter thresholds
All ATM data path performance monitoring parameters (counters, see Table 7-3) shall have an
individual 15-minute and 24-hour threshold parameter if supported.
7.3.5 PTM data path configuration parameters
7.3.5.1 PTM data path performance monitoring parameter thresholds
All PTM data path performance monitoring parameters (counters, see Table 7-3b) shall have an
individual 15-minute and 24-hour threshold parameter if supported.

7.4 Inventory information

7.4.1 ATU-C G.994.1 Vendor ID
The ATU-C G.994.1 Vendor ID is the Vendor ID as inserted by the ATU-C in the G.994.1
CL message. It consists of 8 binary octets, including a country code followed by a (regionally
allocated) provider code, as defined in ITU-T Rec. T.35.

Table 7-4/G.997.1 – Vendor ID information block (8 octets)

T.35 country code (2 octets)
T.35 provider code (vendor identification) (4 octets)
T.35 provider oriented code (vendor revision number) (2 octets)

The G.994.1 Vendor ID should typically identify the vendor of the ATU-C G.994.1 functionality,
whether implemented in hardware or software. It is not intended to indicate the system integrator.
Further details are defined in ITU-T Rec. G.994.1.
7.4.2 ATU-R G.994.1 Vendor ID
The ATU-R G.994.1 Vendor ID is the Vendor ID as inserted by the ATU-R in the G.994.1
CLR message. It consists of 8 binary octets, with same format as the ATU-C G.994.1 Vendor ID.
The G.994.1 Vendor ID should typically identify the vendor of the ATU-R G.994.1 functionality,
whether implemented in hardware or software. It is not intended to indicate the system integrator.
Further details are defined in ITU-T Rec. G.994.1.
7.4.3 ATU-C System Vendor ID
The ATU-C System Vendor ID is the Vendor ID as inserted by the ATU-C in the Overhead
Messages (G.992.3 and G.992.4). It consists of 8 binary octets, with same format as the ATU-C
G.994.1 Vendor ID.
The ATU-C System Vendor ID should typically identify the ATU-C system integrator. In this
context, the system integrator usually refers to the vendor of the smallest field-replaceable unit. As
such, the ATU-C System Vendor ID may not be the same as the ATU-C G.994.1 Vendor ID.

40 ITU-T Rec. G.997.1 (09/2005)

7.4.4 ATU-R system Vendor ID
The ATU-R system Vendor ID is the Vendor ID as inserted by the ATU-R in the Embedded
Operations Channel (G.992.1 and G.992.2) and the Overhead Messages (ITU-T Recs G.992.3 and
G.992.4). It consists of 8 binary octets, with same format as the ATU-C G.994.1 Vendor ID.
The ATU-R system Vendor ID should typically identify the ATU-R system integrator. In this
context, the system integrator usually refers to the vendor of the smallest field-replaceable unit. As
such, the ATU-R System Vendor ID may not be the same as the ATU-R G.994.1 Vendor ID.
7.4.5 ATU-C version number
The ATU-C version number is the version number as inserted by the ATU-C in the Overhead
Messages (ITU-T Recs G.992.3 and G.992.4). It is for version control and is vendor-specific
information. It consists of up to 16 binary octets.
7.4.6 ATU-R version number
The ATU-R version number is the version number as inserted by the ATU-R in the Embedded
Operations Channel (ITU-T Recs G.992.1 and G.992.2) or Overhead Messages (ITU-T
Recs G.992.3 and G.992.4). It is for version control and is vendor-specific information. It consists
of up to 16 binary octets.
7.4.7 ATU-C serial number
The ATU-C serial number is the serial number as inserted by the ATU-C in the Overhead Messages
(G.992.3 and G.992.4). It is vendor-specific information. It consists of up to 32 ascii characters.
Note that the combination of system Vendor ID and serial number creates a unique number for
each ATU-C.
7.4.8 ATU-R serial number
The ATU-R version number is the version number as inserted by the ATU-R in the Embedded
Operations Channel (ITU-T Recs G.992.1 and G.992.2) or Overhead Messages (ITU-T
Recs G.992.3 and G.992.4). It is vendor-specific information. It consists of up to 32 ascii characters.
Note that the combination of system Vendor ID and serial number creates a unique number for each
ATU-R.
7.4.9 ATU-C self-test result
This parameter defines the ATU-C self-test result. It is coded as a 32-bit integer. The most
significant octet of the self-test result is 00hex if the self-test passed and 01hex if the self-test failed.
The interpretation of the other octets is vendor discretionary and can be interpreted in combination
with G.994.1 and system Vendor IDs.
7.4.10 ATU-R self-test result
This parameter defines the ATU-R self-test result. It is coded as a 32-bit integer. The most
significant octet of the self-test result is 00hex if the self-test passed and 01hex if the self-test failed.
The interpretation of the other octets is vendor-discretionary and can be interpreted in combination
with G.994.1 and system Vendor IDs.
7.4.11 ATU-C ADSL transmission system capabilities
This parameter defines the ATU-C transmission system capability list of the different coding types.
It is coded in a bit-map representation with the bits defined in 7.3.1.1.1. This parameter may be
derived from the handshaking procedures defined in ITU-T Rec. G.994.1.

ITU-T Rec. G.997.1 (09/2005) 41

7.4.12 ATU-R ADSL transmission system capabilities
This parameter defines the ATU-R transmission system capability list of the different coding types.
It is coded in a bit-map representation with the bits defined in 7.3.1.1.1. This parameter may be
derived from the handshaking procedures defined in ITU-T Rec. G.994.1.

7.5 Test, diagnostic and status parameters

7.5.1 Line test, diagnostics and status parameters
7.5.1.1 ADSL transmission system
This parameter defines the transmission system in use. It is coded in a bit-map representation with
the bits defined in 7.3.1.1.1. This parameter may be derived from the handshaking procedures
defined in ITU-T Rec. G.994.1.
7.5.1.2 Line power management state
The line has four possible power management states, numbered 0 to 3 and corresponding to
respectively:
L0 – Synchronized – This line state (L0) is when the Line has full transmission (i.e., showtime).
L1 – Power down data transmission – This line state (L1) is when there is transmission on the line
but the net data rate is reduced (e.g., only for OAM and higher layer connection and session
control). This state applies to G.992.2 only.
L2 – Power down data transmission – This line state (L2) is when there is transmission on the line
but the net data rate is reduced (e.g., only for OAM and higher layer connection and session
control). This state applies to G.992.3 and G.992.4 only.
L3 – No-power – This line state (L3) is when there is No Power transmitted on the line at all.
NOTE – This configuration parameter maps to the OperStatus of the line, which is part of the
GeneralInformationGroup object group specified in RFC 2233, and may not need to be duplicated in the
ADSL MIB. See also RFC 2662 and RFC 3440. The Operational Status of the line is UP in the L0, L1 or L2
state (i.e., during showtime) and is DOWN in the L3 state (e.g., during (short) initialization and loop
diagnostics mode).
7.5.1.3 Initialization success/failure cause
This parameter represents the success of failure cause of the last full initialization performed on the
line. It is coded as an integer in the 0 to 5 range, coded as follows:
0 Successful
1 Configuration error
This error occurs with inconsistencies in configuration parameters. E.g., when the line is
initialized in an ADSL Transmission system where an ATU does not support the configured
Maximum Delay or the configured Minimum or Maximum Data Rate for one or more
bearer channels.
2 Configuration not feasible on the line
This error occurs if the Minimum Data Rate cannot be reached on the line with the
Minimum Noise Margin, Maximum PSD level, Maximum Delay and Maximum Bit Error
Ratio for one or more bearer channels.
3 Communication problem
This error occurs, for example, due to corrupted messages or bad syntax messages or if no
common mode can be selected in the G.994.1 handshaking procedure or due to a timeout.

42 ITU-T Rec. G.997.1 (09/2005)

4 No peer ATU detected.
This error occurs if the peer ATU is not powered or not connected or if the line is too long
to allow detection of a peer ATU.
5 Any other or unknown Initialization Failure cause.
7.5.1.4 Downstream last transmitted state
This parameter represents the last successful transmitted initialization state in the downstream
direction in the last full initialization performed on the line. Initialization states are defined in the
individual ADSL Recommendations and are counted from 0 (if G.994.1 is used) or 1 (if G.994.1 is
not used) up to Showtime. This parameter must be interpreted along with the ADSL Transmission
System.
This parameter is available only when, after a failed full initialization, the line diagnostics
procedures are activated on the line. Line diagnostics procedures can be activated by the operator of
the system (through the Line State Forced line configuration parameter) or autonomously by the
ATU-C or ATU-R.
7.5.1.5 Upstream last transmitted state
This parameter represents the last successful transmitted initialization state in the upstream direction
in the last full initialization performed on the line. Initialization states are defined in the individual
ADSL Recommendations and are counted from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used)
up to Showtime. This parameter must be interpreted along with the ADSL Transmission System.
This parameter is available only when, after a failed full initialization, the line diagnostics
procedures are activated on the line. Line diagnostics procedures can be activated by the operator of
the system (through the Line State Forced line configuration parameter) or autonomously by the
ATU-C or ATU-R.
7.5.1.6 Downstream line attenuation (LATNds)
This parameter is the measured difference in the total power transmitted by the ATU-C and the total
power received by the ATU-R over all subcarriers during diagnostics mode and initialization. The
downstream line attenuation ranges from 0 to +127 dB with 0.1 dB steps. A special value indicates
the line attenuation is out of range to be represented.
7.5.1.7 Upstream line attenuation (LATNus)
This parameter is the measured difference in dB in the total power transmitted by the ATU-R and
the total power received by the ATU-C over all subcarriers during diagnostics mode and
initialization. The upstream line attenuation ranges from 0 to +127 dB with 0.1 dB steps. A special
value indicates the line attenuation is out of range to be represented.
7.5.1.8 Downstream signal attenuation (SATNds)
This parameter is the measured difference in the total power transmitted by the ATU-C and the total
power received by the ATU-R over all subcarriers during showtime. The downstream line
attenuation ranges from 0 to +127 dB with 0.1 dB steps. A special value indicates the line
attenuation is out of range to be represented.
NOTE – During showtime, only a subset of the subcarriers may be transmitted by the ATU-C, as compared
to diagnostics mode and initialization. Therefore, the downstream signal attenuation may be significantly
lower than the downstream Line attenuation.
7.5.1.9 Upstream signal attenuation (SATNus)
This parameter is the measured difference in dB in the total power transmitted by the ATU-R and
the total power received by the ATU-C over all subcarriers during showtime. The upstream line

ITU-T Rec. G.997.1 (09/2005) 43

attenuation ranges from 0 to +127 dB with 0.1 dB steps. A special value indicates the line
attenuation is out of range to be represented.
NOTE – During showtime, only a subset of the subcarriers may be transmitted by the ATU-R, as compared
to diagnostics mode and initialization. Therefore, the upstream signal attenuation may be significantly lower
than the upstream line attenuation.
7.5.1.10 Downstream signal-to-noise ratio margin (SNRMds)
The downstream signal-to-noise ratio margin is the maximum increase in dB of the noise power
received at the ATU-R, such that the BER requirements are met for all downstream bearer channels.
The downstream SNR margin ranges from –64 dB to +63 dB with 0.1 dB steps. A special value
indicates the parameter is out of range to be represented.
NOTE – The downstream SNR margin measurement at the ATU-R may take up to 10 s.
7.5.1.11 Upstream signal-to-noise ratio margin (SNRMus)
The upstream signal-to-noise ratio margin is the maximum increase in dB of the noise power
received at the ATU-C, such that the BER requirements are met for all upstream bearer channels.
The upstream SNR margin ranges from –64 dB to +63 dB with 0.1 dB steps. A special value
indicates the parameter is out of range to be represented.
NOTE – The upstream SNR margin measurement at the ATU-C may take up to 10 s.
7.5.1.12 Downstream maximum attainable data rate (ATTNDRds)
This parameter indicates the maximum downstream net data rate currently attainable by the
ATU-C transmitter and the ATU-R receiver. The rate is coded in bit/s.
7.5.1.13 Upstream maximum attainable data rate (ATTNDRus)
This parameter indicates the maximum upstream net data rate currently attainable by the
ATU-R transmitter and the ATU-C receiver. The rate is coded in bit/s.
7.5.1.14 Downstream actual power spectrum density (ACTPSDds)
This parameter is the average downstream transmit power spectrum density over the used
subcarriers (subcarriers to which downstream user data are allocated) delivered by the ATU-C at the
U-C reference point, at the instant of measurement. The power spectrum density level ranges from
–90 dBm/Hz to 0 dBm/Hz with 0.1 dB steps. A special value indicates the parameter is out of range
to be represented.
NOTE – The downstream actual power spectrum density is the sum (in dB) of the REFPSDds and
RMSGIds. See 8.5.1/G.992.3.
7.5.1.15 Upstream actual power spectrum density (ACTPSDus)
This parameter is the average upstream transmit power spectrum density over the used subcarriers
(subcarriers to which upstream user data are allocated) delivered by the ATU-C at the U-C
reference point, at the instant of measurement. The power spectrum density level ranges from
–90 dBm/Hz to 0 dBm/Hz with 0.1 dB steps. A special value indicates the parameter is out of range
to be represented.
NOTE – The upstream actual power spectrum density is the sum (in dB) of the REFPSDus and RMSGIus.
See 8.5.1/G.992.3.
7.5.1.16 Downstream actual aggregate transmit power (ACTATPds)
This parameter is the total amount of transmit power delivered by the ATU-C at the U-C reference
point, at the instant of measurement. The total output power level ranges from –31 dBm to
+31 dBm with 0.1 dB steps. A special value indicates the parameter is out of range to be
represented.

44 ITU-T Rec. G.997.1 (09/2005)

NOTE – The downstream nominal aggregate transmit power may be taken as a best estimate of the
parameter. See 8.12.3.8/G.992.3.
7.5.1.17 Upstream actual aggregate transmit power (ACTATPus)
This parameter is the total amount of transmit power delivered by the ATU-R at the U-R reference
point, at the instant of measurement. The total output power level ranges from –31 dBm to
+31 dBm with 0.1 dB steps. A special value indicates the parameter is out of range to be
represented.
NOTE – The upstream nominal aggregate transmit power may be taken as a best estimate of the parameter.
See 8.12.3.8/G.992.3.
7.5.1.18 Channel characteristics function per subcarrier
This function is defined in 8.12.3.1/G.992.3.
7.5.1.18.1 Downstream H(f) linear representation scale (HLINSCds)
This parameter is the scale factor to be applied to the downstream Hlin(f) values. It is coded as a
16-bit unsigned integer. This parameter is only available after a loop diagnostic procedure.
7.5.1.18.2 Downstream H(f) linear representation (HLINpsds)
This parameter is an array of complex downstream Hlin(f) values in linear scale. Each array entry
represents the Hlin(f = i*∆f) value for a particular subcarrier index i, ranging from 0 to NSCds – 1.
The Hlin(f) is represented as ((scale/215)*((a(i) + j*b(i))/215)), with scale being coded as a 16-bit
unsigned integer and a(i) and b(i) coded as 16-bit 2's complement signed integers in the (–215 + 1)
to (+215 – 1) range. A special value a(i) = b(i) = –215 indicates that no measurement could be done
for the subcarrier because it is out of the passband or that the attenuation is out of range to be
represented. This parameter is only available after a loop diagnostic procedure.
7.5.1.18.3 Downstream H(f) logarithmic measurement time (HLOGMTds)
This parameter contains the number of symbols used to measure the downstream Hlog(f) values. It
is represented as a 16-bit unsigned value.
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).
7.5.1.18.4 Downstream H(f) logarithmic representation (HLOGpsds)
This parameter is an array of real downstream Hlog(f) values in dB. Each array entry represents the
real Hlog(f = i*∆f) value for a particular subcarrier index i, ranging from 0 to NSCds – 1. The real
Hlog(f) value is represented as (6 – m(i)/10), with m(i) 10-bit unsigned integer in the 0 to
1022 range. A special value m = 1023 indicates that no measurement could be done for the
subcarrier because it is out of the passband or that the attenuation is out of range to be represented.
7.5.1.18.5 Upstream H(f) linear representation scale (HLINSCus)
This parameter is the scale factor to be applied to the upstream Hlin(f) values. It is coded in the
same way as the related downstream parameter. This parameter is only available after a loop
diagnostic procedure.
7.5.1.18.6 Upstream H(f) linear representation (HLINpsus)
This parameter is an array of complex upstream Hlin(f) values in linear scale. It is coded in the
same way as the related downstream parameter. This parameter is only available after a loop
diagnostic procedure.

ITU-T Rec. G.997.1 (09/2005) 45

7.5.1.18.7 Upstream H(f) logarithmic measurement time (HLOGMTus)
This parameter contains the number of symbols used to measure the upstream Hlog(f) values. It is
represented as a 16-bit unsigned value.
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).
7.5.1.18.8 Upstream H(f) logarithmic representation (HLOGpsus)
This parameter is an array of real upstream Hlog(f) values in dB. It is coded in the same way as the
related downstream parameter.
7.5.1.19 Quiet line noise PSD per subcarrier
This function is defined in 8.12.3.2/G.992.3.
7.5.1.19.1 Downstream quiet line noise PSD measurement time (QLNMTds)
This parameter contains the number of symbols used to measure the downstream QLN(f) values. It
is represented as a 16-bit unsigned value
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).
7.5.1.19.2 Downstream QLN(f) (QLNpsds)
This parameter is an array of real downstream QLN(f) values in dBm/Hz. Each array entry
represents the QLN(f = i*∆f) value for a particular subcarrier index i, ranging from 0 to NSCds – 1.
The QLN(f) is represented as (–23 – n(i)/2), with n(i) an 8-bit unsigned integer in the 0 to 254
range. A special value n(i) = 255 indicates that no measurement could be done for the subcarrier
because it is out of the passband or that the noise PSD is out of range to be represented.
7.5.1.19.3 Upstream quiet line noise PSD measurement time (QLNMTus)
This parameter contains the number of symbols used to measure the upstream QLN(f) values. It is
represented as a 16-bit unsigned value.
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).
7.5.1.19.4 Upstream QLN(f) (QLNpsus)
This parameter is an array of real upstream QLN(f) values in dBm/Hz. It is coded in the same way
as the related downstream parameter.
7.5.1.20 Signal-to-noise ratio per subcarrier
This function is defined in 8.12.3.3/G.992.3.
7.5.1.20.1 Downstream SNR measurement time (SNRMTds)
This parameter contains the number of symbols used to measure the downstream SNR(f) values. It
is represented as a 16-bit unsigned value.
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).

46 ITU-T Rec. G.997.1 (09/2005)

7.5.1.20.2 Downstream SNR(f) (SNRpsds)
This parameter is an array of real downstream SNR(f) values in dB. Each array entry represents the
SNR(f = i*∆f) value for a particular subcarrier index i, ranging from 0 to NSCds – 1. The SNR(f) is
represented as (–32 + snr(i)/2), with snr(i) an 8-bit unsigned integer in the 0 to 254 range. A special
value snr(i) = 255 indicates that no measurement could be done for the subcarrier because it is out
of the passband or that the noise PSD is out of range to be represented.
7.5.1.20.3 Upstream SNR measurement time (SNRMTus)
This parameter contains the number of symbols used to measure the downstream SNR(f) values. It
is represented as a 16-bit unsigned value.
After a loop diagnostic procedure, this parameter shall contain the number of symbols used to
generate the associate parameter. It should correspond to the value specified in the
Recommendation (e.g., the number of symbols in 1 s time interval for G.992.3).
7.5.1.20.4 Upstream SNR(f) (SNRpsus)
This parameter is an array of real upstream SNR(f) values in dB. It is coded in the same way as the
related downstream parameter.
7.5.1.21 Bits and gains allocation per subcarrier
7.5.1.21.1 Downstream bits allocation (BITSpsds)
This parameter defines the downstream bits allocation table per subcarrier. It is an array of integer
values in the 0 to 15 range for subcarriers 0 to NSCds – 1.
7.5.1.21.2 Upstream bits allocation (BITSpsus)
This parameter defines the upstream bits allocation table per subcarrier. It is an array of integer
values in the 0 to 15 range for subcarriers 0 to NSCus – 1.
7.5.1.21.3 Downstream gains allocation (GAINSpsds)
This parameter defines the downstream gains allocation table per subcarrier. It is an array of integer
values in the 0 to 4093 range for subcarriers 0 to NSCds – 1. The gain value is represented as a
multiple of 1/512 on linear scale.
7.5.1.21.4 Upstream gains allocation (GAINSpsus)
This parameter defines the upstream gains allocation table per subcarrier. It is an array of integer
values in the 0 to 4093 range for subcarriers 0 to NSCus – 1. The gain value is represented as a
multiple of 1/512 on linear scale.
7.5.1.21.5 Downstream transmit spectrum shaping (TSSpsds)
This parameter contains the downstream transmit spectrum shaping parameters expressed as the set
of breakpoints exchanged during G.994.1. Each breakpoint consists in a subcarrier index and the
associated shaping parameter. The shaping parameter is an integer value in the 0 to 127 range. It is
represented as a multiple of –0.5 dB. The value 127 is a special value indicating the subcarrier is not
transmitted.
7.5.1.21.6 Upstream transmit spectrum shaping (TSSpsus)
This parameter contains the upstream transmit spectrum shaping parameters expressed as the set of
breakpoints exchanged during G.994.1. Each breakpoint consists in a subcarrier index and the
associated shaping parameter. The shaping parameter is an integer value in the 0 to 127 range. It is
represented as a multiple of –0.5 dB. The value 127 is a special value indicating the subcarrier is not
transmitted.

ITU-T Rec. G.997.1 (09/2005) 47

7.5.2 Channel status parameters
7.5.2.1 Actual data rate
This parameter reports the actual net data rate the bearer channel is operating at excluding rate in L1
and L2 states. In L1 or L2 states, the parameter contains the net data rate in the previous L0 state.
The data rate is coded in bit/s.
7.5.2.2 Previous data rate
This parameter reports the previous net data rate the bearer channel was operating at just before the
latest rate change event occurred excluding all transitions between L0 state and L1 or L2 states. A
rate change can occur at a power management state transition, e.g., at full or short initialization, fast
retrain or power down or at a dynamic rate adaptation. The rate is coded in bit/s.
7.5.2.3 Actual interleaving delay
This parameter is the actual one-way interleaving delay introduced by the PMS-TC between the alfa
and beta reference points excluding delay in L1 and L2 state. In L1 and L2 state, the parameter
contains the interleaving delay in the previous L0 state. This parameter is derived from the S and D
parameters as S*D /4 ms, where "S" is the Symbols per codeword, and "D" is the "Interleaving
Depth" and x denotes rounding to the higher integer. The Actual Interleaving Delay is coded in
ms (rounded to the nearest ms).

7.6 Network management elements partitioning

This clause defines the network management elements which correspond to the specific
management interfaces:
Q interface: Management interface towards the ATU-C, from the network side perspective. The
ATU-C provides its near-end (at ATU-C) and far-end (at ATU-R) parameters for
the system operator to read and write.
U-C interface: Management interface towards the ATU-C, from the ATU-R's perspective. The
ATU-C provides its near-end parameters (ATU-R far-end) for the ATU-R to read.
U-R interface: Management interface towards the ATU-C, from the ATU-R's perspective. The
ATU-R provides its near-end parameters (ATU-C far-end) for the ATU-C to read.
T-/S-interface: Management interface towards the ATU-R, from the premises side perspective.
The ATU-R provides its near-end (at ATU-R) and far-end (at ATU-C) parameters
for the subscriber to read and write.
The management interface described at the U interface covers the network management elements to
be supported through the OAM communications channel specified in this Recommendation (Clear
EOC between ATU-C and ATU-R). The support of such communications channel is optional. The
exchange between ATU-C and ATU-R of some or all of these network elements may already be
covered by the (EOC) commands listed in the management plane procedures of individual
Recommendations.
Parameters indicated with:
• R are read only.
• W are write only.
• R/W are read and write.
• (M) are mandatory.
• (O) are optional.

48 ITU-T Rec. G.997.1 (09/2005)

The far-end fault and performance monitoring over the Q-interface is equivalent to the near-end
fault and performance monitoring over the T-/S-interface. The near-end fault and performance
monitoring over the Q-interface is equivalent to the far-end fault and performance monitoring over
the T-/S-interface. Over the Q-interface, near-end fault and performance monitoring applies to the
upstream direction only and far-end performance monitoring applies to the downstream direction
only. Over the T-/S-interface, near-end fault and performance monitoring applies to the downstream
direction only and far-end performance monitoring applies to the upstream direction only.
The second table for each category indicates for which Recommendations, the management element
is relevant. A "Y" in a column means that this MIB element is relevant for this Recommendation.

Table 7-5/G.997.1 – Line failures

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) failures
Loss-of-Signal (LOS) 7.1.1.1.1 R (M) R(O) R (O)
Loss-of-Frame (LOF) 7.1.1.1.2 R (M) R(O) R (O)
Loss-of-Power (LPR) 7.1.1.1.3 R (M) R(O) R (O)
Far-end (ATU-R) failures
Loss-of-Signal (LOS-FE) failure 7.1.1.2.1 R (M) R(O) R (O)
Loss-of-Frame (LOF-FE) failure 7.1.1.2.2 R (M) R(O) R (O)
Loss-of-Power (LPR-FE) failure 7.1.1.2.3 R (M) R(O) R (O)
Initialization failures
Line Init (LINIT) Failure 7.1.1.3 R (M) R (O)

Table 7-6/G.997.1 – Line failures

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end failures
Loss-of-Signal (LOS) Y Y Y Y Y
Loss-of-Frame (LOF) Y Y Y Y Y
Loss-of-Power (LPR) Y Y Y Y Y
Far-end failures
Loss-of-Signal (LOS-FE) failure Y Y Y Y Y
Loss-of-Frame (LOF-FE) failure Y Y Y Y Y
Loss-of-Power (LPR-FE) failure Y Y Y Y Y
Initialization failures
Line Init (LINIT) Failure Y Y Y Y Y

ITU-T Rec. G.997.1 (09/2005) 49

 Table 7-7/G.997.1 – ATM data path failures
Defined Q- U-C U-R T-/S-
Category/Element
in clause: Interface Interface Interface Interface
Near-end (ATU-C) failures
No Cell Delineation (NCD) failure 7.1.4.1.1 R (M) R(O)
Loss of Cell Delineation (LCD) failure 7.1.4.1.2 R (M) R(O)
Far-end (ATU-R) failures
No Cell Delineation (NCD-FE) failure 7.1.4.2.1 R (M) R(O)
Loss of Cell Delineation (LCD-FE) 7.1.4.2.2 R (M) R(O)
failure

Table 7-8/G.997.1 – ATM data path failures

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end failures
No Cell Delineation (NCD) failure Y Y Y Y Y
Loss of Cell Delineation (LCD) failure Y Y Y Y Y
Far-end failures
No Cell Delineation (NCD-FE) failure Y Y Y Y Y
Loss of Cell Delineation (LCD-FE) Y Y Y Y Y
failure

Table 7-9/G.997.1 – Line configuration profile

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Line/ATU State
ATU Transmission System Enabling 7.3.1.1.1 R/W (M) R(O)
(ATSE)
ATU Impedance State Forced (AISF) 7.3.1.1.2 R/W (M)
Power Management State Forced 7.3.1.1.3 R/W (M) R/W (M)
(PMSF)
Power Management State Enabling 7.3.1.1.4 R/W (M)
(PMMode)
L0-TIME 7.3.1.1.5 R/W (M) R (O)
L2-TIME 7.3.1.1.6 R/W (M) R (O)
L2-ATPR 7.3.1.1.7 R/W (M) R (O)
L2-ATPRT 7.3.1.1.9 R/W (M) R (O)
Loop Diagnostics Mode Forced 7.3.1.1.8 R/W (M) R/W (M)
Automode Cold Start Forced 7.3.1.1.10 R/W (M) R/W (O)
Power and Spectrum Usage
MAXNOMPSD downstream 7.3.1.2.1 R/W (M) R (O)
MAXNOMPSD upstream 7.3.1.2.2 R/W (M) R (O)

50 ITU-T Rec. G.997.1 (09/2005)

 Table 7-9/G.997.1 – Line configuration profile
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
MAXNOMATP downstream 7.3.1.2.3 R/W (M) R (O)
MAXNOMATP upstream 7.3.1.2.4 R/W (M) R (O)
MAXRXPWR upstream 7.3.1.2.5 R/W (M) R (O)
CARMASK downstream 7.3.1.2.6 R/W (M) R (O)
CARMASK upstream 7.3.1.2.7 R/W (M) R (O)
PSDMASK downstream 7.3.1.2.8 R/W(M) R (O)
RFIBANDS downstream 7.3.1.2.9 R/W(M) R (O)
Upstream PSD mask selection 7.3.1.2.10 R/W (M) R (O)
PSDMASK upstream 7.3.1.2.11 R/W (M) R(O)
Noise Margins
TARSNRM downstream 7.3.1.3.1 R/W (M) R (O)
TARSNRM upstream 7.3.1.3.2 R/W (M) R (O)
MAXSNRM downstream 7.3.1.3.3 R/W (M) R (O)
MAXSNRM upstream 7.3.1.3.4 R/W (M) R (O)
MINSNRM downstream 7.3.1.3.5 R/W (M) R (O)
MINSNRM upstream 7.3.1.3.6 R/W (M) R (O)
Rate Adaptation
RA-MODE downstream 7.3.1.4.1 R/W (M) R (O)
RA-MODE upstream 7.3.1.4.2 R/W (M) R (O)
RA-USNRM downstream 7.3.1.4.3 R/W (O) R (O)
RA-USNRM upstream 7.3.1.4.4 R/W (O) R (O)
RA-UTIME downstream 7.3.1.4.5 R/W (O) R (O)
RA-UTIME upstream 7.3.1.4.6 R/W (O) R (O)
RA-DSNRM downstream 7.3.1.4.7 R/W (O) R (O)
RA-DSNRM upstream 7.3.1.4.8 R/W (O) R (O)
RA-DTIME downstream 7.3.1.4.9 R/W (O) R (O)
RA-DTIME upstream 7.3.1.4.10 R/W (O) R (O)
Overhead
MSGMIN upstream 7.3.1.5.1 R/W(O) R(O)
MSGMIN downstream 7.3.1.5.2 R/W(O) R(O)
Near-end (ATU-C) Performance Monitoring Thresholds (15-minute interval)
FECS-L threshold 15 minutes 7.3.1.6 R/W (O) R (O)
ES-L threshold 15 minutes 7.3.1.6 R/W (M) R (O)
SES-L threshold 15 minutes 7.3.1.6 R/W (M) R (O)
LOSS-L threshold 15 minutes 7.3.1.6 R/W (O) R (O)
UAS-L threshold 15 minutes 7.3.1.6 R/W (M) R (O)

ITU-T Rec. G.997.1 (09/2005) 51

 Table 7-9/G.997.1 – Line configuration profile
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Thresholds (1 day interval)
FECS-L threshold 1 day 7.3.1.6 R/W (O) R (O)
ES-L threshold 1 day 7.3.1.6 R/W (M) R (O)
SES-L threshold 1 day 7.3.1.6 R/W (M) R (O)
LOSS-L threshold 1 day 7.3.1.6 R/W (O) R (O)
UAS-L threshold 1 day 7.3.1.6 R/W (M) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (15-minute interval)
FECS-LFE threshold 15 minutes 7.3.1.6 R/W (O) R (O)
ES-LFE threshold 15 minutes 7.3.1.6 R/W (M) R (O)
SES-LFE threshold 15 minutes 7.3.1.6 R/W (M) R (O)
LOSS-LFE threshold 15 minutes 7.3.1.6 R/W (O) R (O)
UAS-LFE threshold 15 minutes 7.3.1.6 R/W (M) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (1 day interval)
FECS-LFE threshold 1 day 7.3.1.6 R/W (O) R (O)
ES-LFE threshold 1 day 7.3.1.6 R/W (M) R (O)
SES-LFE threshold 1 day 7.3.1.6 R/W (M) R (O)
LOSS-LFE threshold 1 day 7.3.1.6 R/W (O) R (O)
UAS-LFE threshold 1 day 7.3.1.6 R/W (M) R (O)
Initialization Performance Monitoring Thresholds (15-minute interval)
Full inits threshold 15 minutes 7.3.1.6 R (M) R (O)
Failed full inits threshold 15 minutes 7.3.1.6 R (M) R (O)
Short inits threshold 15 minutes 7.3.1.6 R (O) R (O)
Failed short inits threshold 15 7.3.1.6 R (O) R (O)
minutes
Initialization Performance Monitoring Thresholds (1 day interval)
Full inits threshold 1 day 7.3.1.6 R (M) R (O)
Failed full inits threshold 1 day 7.3.1.6 R (M) R (O)
Short inits threshold 1 day 7.3.1.6 R (O) R (O)
Failed short inits threshold 1 day 7.3.1.6 R (O) R (O)

52 ITU-T Rec. G.997.1 (09/2005)

 Table 7-10/G.997.1 – Line configuration profile
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Line/ATU State
ATU Transmission System Enabling Y Y Y Y Y
(ATSE)
ATU Impedance State Forced (AISF) Y Y Y
(Annex A) (Annex A) (Annex A)
Power Management State Forced Y Y Y Y Y
(PMSF)
Power Management State Enabling Y Y Y Y Y
(PMMode)
L0-TIME Y Y Y
L2-TIME Y Y Y
L2-ATPR Y Y Y
L2-ATPRT Y Y Y
Loop Diagnostics Mode Forced Y Y Y
Automode Cold Start Forced Y Y Y
Power and Spectrum Usage
MAXNOMPSD downstream Y Y Y
MAXNOMPSD upstream Y Y Y
MAXNOMATP downstream Y Y Y
MAXNOMATP upstream Y Y Y
MAXRXPWR upstream Y Y Y
CARMASK downstream Y Y Y
CARMASK upstream Y Y Y
PSDMASK downstream Y
RFIBANDS downstream Y
Upstream PSD mask selection Y Y
PSDMASK upstream Y Y
(Annexes (Annexes
J/M) J/M)
Noise Margins
TARSNRM downstream Y Y Y Y Y
TARSNRM upstream Y Y Y Y Y
MAXSNRM downstream Y Y Y Y Y
MAXSNRM upstream Y Y Y Y Y
MINSNRM downstream Y Y Y Y Y
MINSNRM upstream Y Y Y Y Y

ITU-T Rec. G.997.1 (09/2005) 53

 Table 7-10/G.997.1 – Line configuration profile
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Rate Adaptation
RA-MODE downstream Y Y Y Y
RA-MODE upstream Y Y Y Y
RA-USNRM downstream Y Y Y Y
RA-USNRM upstream Y Y Y Y
RA-UTIME downstream Y Y Y Y
RA-UTIME upstream Y Y Y Y
RA-DSNRM downstream Y Y Y Y
RA-DSNRM upstream Y Y Y Y
RA-DTIME downstream Y Y Y Y
RA-DTIME upstream Y Y Y Y
Overhead
MSGMIN upstream Y Y Y
MSGMIN downstream Y Y Y
Near-end Performance Monitoring Thresholds (15-minute interval)
FECS-L threshold 15 minutes Y Y Y Y Y
ES-L threshold 15 minutes Y Y Y Y Y
SES-L threshold 15 minutes Y Y Y Y Y
LOSS-L threshold 15 minutes Y Y Y Y Y
UAS-L threshold 15 minutes Y Y Y Y Y
Near-end Performance Monitoring Thresholds (1 day interval)
FECS-L threshold 1 day Y Y Y Y Y
ES-L threshold 1 day Y Y Y Y Y
SES-L threshold 1 day Y Y Y Y Y
LOSS-L threshold 1 day Y Y Y Y Y
UAS-L threshold 1 day Y Y Y Y Y
Far-end Performance Monitoring Thresholds (15-minute interval)
FECS-LFE threshold 15 minutes Y Y Y Y Y
ES-LFE threshold 15 minutes Y Y Y Y Y
SES-LFE threshold 15 minutes Y Y Y Y Y
LOSS-LFE threshold 15 minutes Y Y Y Y Y
UAS-LFE threshold 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Thresholds (1 day interval)
FECS-LFE threshold 1 day Y Y Y Y Y
ES-LFE threshold 1 day Y Y Y Y Y
SES-LFE threshold 1 day Y Y Y Y Y
LOSS-LFE threshold 1 day Y Y Y Y Y
UAS-LFE threshold 1 day Y Y Y Y Y

54 ITU-T Rec. G.997.1 (09/2005)

 Table 7-10/G.997.1 – Line configuration profile
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Initialization Performance Monitoring Thresholds (15-minute interval)
Full inits threshold 15 minutes Y Y Y Y Y
Failed full inits threshold 15 minutes Y Y Y Y Y
Short inits threshold 15 minutes Y Y Y Y
Failed short inits threshold 15 Y Y Y Y
minutes
Initialization Performance Monitoring Thresholds (1 day interval)
Full inits threshold 1 day Y Y Y Y Y
Failed full inits threshold 1 day Y Y Y Y Y
Short inits threshold 1 day Y Y Y Y
Failed short inits threshold 1 day Y Y Y Y

Table 7-11/G.997.1 – Channel configuration profile

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Data Rate
Minimum Data Rate 7.3.2.1.1 R/W (M) R (O)
Minimum Reserved Data Rate 7.3.2.1.2 R/W (O) R (O)
Maximum Data Rate 7.3.2.1.3 R/W (M) R (O)
Rate Adaptation Ratio 7.3.2.1.4 R/W (O) R (O)
Minimum Data Rate in low power 7.3.2.1.5 R/W (M) R (O)
state
Maximum Interleaving Delay 7.3.2.2 R/W (M) R (O)
Minimum Impulse Noise Protection 7.3.2.3 R/W(M) R (O)
Maximum Bit Error Ratio 7.3.2.4 R/W (M) R (O)
Data Rate Threshold Upshift 7.3.2.6.1 R/W(M)
Data Rate Threshold Downshift 7.3.2.6.2 R/W(M)
Near-end (ATU-C) Performance Monitoring Thresholds (15-minute interval)
CV-C threshold 15 minutes 7.3.2.5 R/W (O) R (O)
FEC-C threshold 15 minutes 7.3.2.5 R/W (O) R (O)
Near-end (ATU-C) Performance Monitoring Thresholds (1 day interval)
CV-C threshold 1 day 7.3.2.5 R/W (O) R (O)
FEC-C threshold 1 day 7.3.2.5 R/W (O) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (15-minute interval)
CV-CFE threshold 15 minutes 7.3.2.5 R/W (O) R (O)
FEC-CFE threshold 15 minutes 7.3.2.5 R/W (O) R (O)

ITU-T Rec. G.997.1 (09/2005) 55

 Table 7-11/G.997.1 – Channel configuration profile
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Far-end (ATU-R) Performance Monitoring Thresholds (1 day interval)
CV-CFE threshold 1 day 7.3.2.5 R/W (O) R (O)
FEC-CFE threshold 1 day 7.3.2.5 R/W (O) R (O)

Table 7-12/G.997.1 – Channel configuration profile

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Data Rate
Minimum Data Rate Y Y Y Y Y
Minimum Reserved Data Rate Y Y Y Y
Maximum Data Rate Y Y Y Y Y
Rate Adaptation Ratio Y Y Y Y Y
Minimum Data Rate in low power Y Y Y Y
state
Maximum Interleaving Delay Y Y Y Y Y
Minimum Impulse Noise Protection Y Y Y
Maximum Bit Error Ratio Y Y Y
Data Rate Threshold Upshift Y Y Y Y Y
Data Rate Threshold Downshift Y Y Y Y Y
Near-end Performance Monitoring Thresholds (15-minute interval)
CV-C threshold 15 minutes Y Y Y Y Y
FEC-C threshold 15 minutes Y Y Y Y Y
Near-end Performance Monitoring Thresholds (1 day interval)
CV-C threshold 1 day Y Y Y Y Y
FEC-C threshold 1 day Y Y Y Y Y
Far-end Performance Monitoring Thresholds (15-minute interval)
CV-CFE threshold 15 minutes Y Y Y Y Y
FEC-CFE threshold 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Thresholds (1 day interval)
CV-CFE threshold 1 day Y Y Y Y Y
FEC-CFE threshold 1 day Y Y Y Y Y

56 ITU-T Rec. G.997.1 (09/2005)

 Table 7-13/G.997.1 – ATM data path configuration profile
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
IMA configuration
IMA Operation Mode Enable 7.3.4.1 R/W (M)
Parameter
Near-end (ATU-C) Performance Monitoring Thresholds (15-minute interval)
HEC-P threshold 15 minutes 7.3.4.2 R/W (O) R (O)
CD-P threshold 15 minutes 7.3.4.2 R/W (O) R (O)
CU-P threshold 15 minutes 7.3.4.2 R/W (O) R (O)
IBE-P threshold 15 minutes 7.3.4.2 R/W (O) R (O)
Near-end (ATU-C) Performance Monitoring Thresholds (1 day interval)
HEC-P threshold 1 day 7.3.4.2 R/W (O) R (O)
CD-P threshold 1 day 7.3.4.2 R/W (O) R (O)
CU-P threshold 1 day 7.3.4.2 R/W (O) R (O)
IBE-P threshold 1 day 7.3.4.2 R/W (O) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (15-minute interval)
HEC-PFE threshold 15 minutes 7.3.4.2 R/W (O) R (O)
CD-PFE threshold 15 minutes 7.3.4.2 R/W (O) R (O)
CU-PFE threshold 15 minutes 7.3.4.2 R/W (O) R (O)
IBE-PFE threshold 15 minutes 7.3.4.2 R/W (O) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (1 day interval)
HEC-PFE threshold 1 day 7.3.4.2 R/W (O) R (O)
CD-PFE threshold 1 day 7.3.4.2 R/W (O) R (O)
CU-PFE threshold 1 day 7.3.4.2 R/W (O) R (O)
IBE-PFE threshold 1 day 7.3.4.2 R/W (O) R (O)

Table 7-14/G.997.1 – ATM data path configuration profile

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
IMA configuration
IMA Operation Mode Enable Y Y Y
Parameter
Near-end Performance Monitoring Thresholds (15-minute interval)
HEC-P threshold 15 minutes Y Y Y Y Y
CD-P threshold 15 minutes Y Y Y Y Y
CU-P threshold 15 minutes Y Y Y Y Y
IBE-P threshold 15 minutes Y Y Y Y Y

ITU-T Rec. G.997.1 (09/2005) 57

 Table 7-14/G.997.1 – ATM data path configuration profile
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Thresholds (1 day interval)
HEC-P threshold 1 day Y Y Y Y Y
CD-P threshold 1 day Y Y Y Y Y
CU-P threshold 1 day Y Y Y Y Y
IBE-P threshold 1 day Y Y Y Y Y
Far-end Performance Monitoring Thresholds (15-minute interval)
HEC-PFE threshold 15 minutes Y Y Y Y Y
CD-PFE threshold 15 minutes Y Y Y Y Y
CU-PFE threshold 15 minutes Y Y Y Y Y
IBE-PFE threshold 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Thresholds (1 day interval)
HEC-PFE threshold 1 day Y Y Y Y Y
CD-PFE threshold 1 day Y Y Y Y Y
CU-PFE threshold 1 day Y Y Y Y Y
IBE-PFE threshold 1 day Y Y Y Y Y

Table 7-15/G.997.1 – Line inventory

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
ATU-C G.994.1 Vendor ID 7.4.1 R (M) R (O) R (O)
ATU-R G.994.1 Vendor ID 7.4.2 R (M) R (O) R (O)
ATU-C System Vendor ID 7.4.3 R (M) R (O) R (O)
ATU-R System Vendor ID 7.4.4 R (M) R (O) R (O)
ATU-C Version Number 7.4.5 R (M) R (O) R (O)
ATU-R Version Number 7.4.6 R (M) R (O) R (O)
ATU-C Serial Number 7.4.7 R (M) R (O) R (O)
ATU-R Serial Number 7.4.8 R (M) R (O) R (O)
ATU-C Self-Test Result 7.4.9 R (M) R (O) R (O)
ATU-R Self-Test Result 7.4.10 R (M) R (O) R (O)
ATU-C Transmission System 7.4.11 R (M) R (O) R (O)
Capabilities
ATU-R Transmission System 7.4.12 R (M) R (O) R (O)
Capabilities

58 ITU-T Rec. G.997.1 (09/2005)

 Table 7-16/G.997.1 – Line inventory
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
ATU-C G.994.1 Vendor ID Y Y Y Y Y
ATU-R G.994.1 Vendor ID Y Y Y Y Y
ATU-C System Vendor ID Y Y Y Y Y
ATU-R System Vendor ID Y Y Y Y Y
ATU-C Version Number Y Y Y Y Y
ATU-R Version Number Y Y Y Y Y
ATU-C Serial Number Y Y Y Y Y
ATU-R Serial Number Y Y Y Y Y
ATU-C Self-Test Result Y Y Y Y Y
ATU-R Self-Test Result Y Y Y Y Y
ATU-C Transmission System Y Y Y Y Y
Capabilities
ATU-R Transmission System Y Y Y Y Y
Capabilities

Table 7-17/G.997.1 – Line performance monitoring parameters

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Counters (current and previous 15-minute interval)
FECS-L counter 15 minutes 7.2.1.1.1 R (M) R (O)
ES-L counter 15 minutes 7.2.1.1.2 R (M) R (O) R(O)
SES-L counter 15 minutes 7.2.1.1.3 R (M) R (O) R(O)
LOSS-L counter 15 minutes 7.2.1.1.4 R (M) R (O)
UAS-L counter 15 minutes 7.2.1.1.5 R (M) R (O)
Near-end (ATU-C) Performance Monitoring Counters (current and previous 1 day interval)
FECS-L counter 1 day 7.2.1.1.1 R (M) R (O)
ES-L counter 1 day 7.2.1.1.2 R (M) R (O) R(O)
SES-L counter 1 day 7.2.1.1.3 R (M) R (O) R(O)
LOSS-L counter 1 day 7.2.1.1.4 R (M) R (O)
UAS-L counter 1 day 7.2.1.1.5 R (M) R (O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 15-minute interval)
FECS-LFE counter 15 minutes 7.2.1.2.1 R (M) R (O)
ES-LFE counter 15 minutes 7.2.1.2.2 R (M) R (O) R(O)
SES-LFE counter 15 minutes 7.2.1.2.3 R (M) R (O) R(O)
LOSS-LFE counter 15 minutes 7.2.1.2.4 R (M) R (O)
UAS-LFE counter 15 minutes 7.2.1.2.5 R (M) R (O)

ITU-T Rec. G.997.1 (09/2005) 59

 Table 7-17/G.997.1 – Line performance monitoring parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Far-end (ATU-R) Performance Monitoring Counters (current and previous 1 day interval)
FECS-LFE counter 1 day 7.2.1.2.1 R (M) R (O)
ES-LFE counter 1 day 7.2.1.2.2 R (M) R (O) R(O)
SES-LFE counter 1 day 7.2.1.2.3 R (M) R (O) R(O)
LOSS-LFE counter 1 day 7.2.1.2.4 R (M) R (O)
UAS-LFE counter 1 day 7.2.1.2.5 R (M) R (O)
Initialization Performance Monitoring Counters (current and previous 15-minute interval)
Full inits counter 15 minutes 7.2.1.3.1 R (M) R (O)
Failed full inits counter 15 minutes 7.2.1.3.2 R (M) R (O)
Short inits counter 15 minutes 7.2.1.3.3 R (O) R (O)
Failed short inits counter 15 minutes 7.2.1.3.4 R (O) R (O)
Initialization Performance Monitoring Counters (current and previous 1 day interval)
Full inits counter 1 day 7.2.1.3.1 R (M) R (O)
Failed full inits counter 1 day 7.2.1.3.2 R (M) R (O)
Short inits counter 1 day 7.2.1.3.3 R (O) R (O)
Failed short inits counter 1 day 7.2.1.3.4 R (O) R (O)

Table 7-18/G.997.1 – Line performance monitoring parameters

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Counters (current and previous 15-minute interval)
FECS-L counter 15 minutes Y Y Y Y Y
ES-L counter 15 minutes Y Y Y Y Y
SES-L counter 15 minutes Y Y Y Y Y
LOSS-L counter 15 minutes Y Y Y Y Y
UAS-L counter 15 minutes Y Y Y Y Y
Near-end Performance Monitoring Counters (current and previous 1 day interval)
FECS-L counter 1 day Y Y Y Y Y
ES-L counter 1 day Y Y Y Y Y
SES-L counter 1 day Y Y Y Y Y
LOSS-L counter 1 day Y Y Y Y Y
UAS-L counter 1 day Y Y Y Y Y

60 ITU-T Rec. G.997.1 (09/2005)

 Table 7-18/G.997.1 – Line performance monitoring parameters
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Far-end Performance Monitoring Counters (current and previous 15-minute interval)
FECS-LFE counter 15 minutes Y Y Y Y Y
ES-LFE counter 15 minutes Y Y Y Y Y
SES-LFE counter 15 minutes Y Y Y Y Y
LOSS-LFE counter 15 minutes Y Y Y Y Y
UAS-LFE counter 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Counters (current and previous 1 day interval)
FECS-LFE counter 1 day Y Y Y Y Y
ES-LFE counter 1 day Y Y Y Y Y
SES-LFE counter 1 day Y Y Y Y Y
LOSS-LFE counter 1 day Y Y Y Y Y
UAS-LFE counter 1 day Y Y Y Y Y
Initialization Performance Monitoring Counters (current and previous 15-minute interval)
Full inits counter 15 minutes Y Y Y Y Y
Failed full inits counter 15 minutes Y Y Y Y Y
Short inits counter 15 minutes Y Y Y Y
Failed short inits counter 15 minutes Y Y Y Y
Initialization Performance Monitoring Counters (current and previous 1 day interval)
Full inits counter 1 day Y Y Y Y Y
Failed full inits counter 1 day Y Y Y Y Y
Short inits counter 1 day Y Y Y Y
Failed short inits counter 1 day Y Y Y Y

Table 7-19/G.997.1 – Channel performance monitoring parameters

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Counters (current and previous 15-minute interval)
CV-C counter 15 minutes 7.2.2.1.1 R (M) R (O)
FEC-C counter 15 minutes 7.2.2.1.2 R (M) R (O)
Near-end (ATU-C) Performance Monitoring Counters (current and previous 1 day interval)
CV-C counter 1 day 7.2.2.1.1 R (M) R (O)
FEC-C counter 1 day 7.2.2.1.2 R (M) R (O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 15-minute interval)
CV-CFE counter 15 minutes 7.2.2.2.1 R (M) R (O)
FEC-CFE counter 15 minutes 7.2.2.2.2 R (M) R (O)

ITU-T Rec. G.997.1 (09/2005) 61

 Table 7-19/G.997.1 – Channel performance monitoring parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Far-end (ATU-R) Performance Monitoring Counters (current and previous 1 day interval)
CV-CFE counter 1 day 7.2.2.2.1 R (M) R (O)
FEC-CFE counter 1 day 7.2.2.2.2 R (M) R (O)

Table 7-20/G.997.1 – ATM data path performance monitoring parameters

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Counters (current and previous 15-minute interval)
HEC-P counter 15 minutes 7.2.4.1.1 R (M) R (O)
CD-P counter 15 minutes 7.2.4.1.2 R (M) R (O)
CU-P counter 15 minutes 7.2.4.1.3 R (M) R (O)
IBE-P counter 15 minutes 7.2.4.1.4 R (M) R (O) R(O)
Near-end (ATU-C) Performance Monitoring Counters (current and previous 1 day interval)
HEC-P counter 1 day 7.2.4.1.1 R (M) R (O)
CD-P counter 1 day 7.2.4.1.2 R (M) R (O)
CU-P counter 1 day 7.2.4.1.3 R (M) R (O)
IBE-P counter 1 day 7.2.4.1.4 R (M) R (O) R(O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 15-minute interval)
HEC-PFE counter 15 minutes 7.2.4.2.1 R (M) R (O)
CD-PFE counter 15 minutes 7.2.4.2.2 R (M) R (O)
CU-PFE counter 15 minutes 7.2.4.2.3 R (M) R (O)
IBE-PFE counter 15 minutes 7.2.4.2.4 R (M) R (O) R(O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 1 day interval)
HEC-PFE counter 1 day 7.2.4.2.1 R (M) R (O)
CD-PFE counter 1 day 7.2.4.2.2 R (M) R (O)
CU-PFE counter 1 day 7.2.4.2.3 R (M) R (O)
IBE-PFE counter 1 day 7.2.4.2.4 R (M) R (O) R(O)

62 ITU-T Rec. G.997.1 (09/2005)

 Table 7-21/G.997.1 – Channel performance monitoring parameters
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Counters (current and previous 15-minute interval)
CV-C counter 15 minutes Y Y Y Y Y
FEC-C counter 15 minutes Y Y Y Y Y
Near-end Performance Monitoring Counters (current and previous 1 day interval)
CV-C counter 1 day Y Y Y Y Y
FEC-C counter 1 day Y Y Y Y Y
Far-end Performance Monitoring Counters (current and previous 15-minute interval)
CV-CFE counter 15 minutes Y Y Y Y Y
FEC-CFE counter 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Counters (current and previous 1 day interval)
CV-CFE counter 1 day Y Y Y Y Y
FEC-CFE counter 1 day Y Y Y Y Y

Table 7-22/G.997.1 – ATM data path performance monitoring parameters

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Counters (current and previous 15-minute interval)
HEC-P counter 15 minutes Y Y Y Y Y
CD-P counter 15 minutes Y Y Y Y Y
CU-P counter 15 minutes Y Y Y Y Y
IBE-P counter 15 minutes Y Y Y Y Y
Near-end Performance Monitoring Counters (current and previous 1 day interval)
HEC-P counter 1 day Y Y Y Y Y
CD-P counter 1 day Y Y Y Y Y
CU-P counter 1 day Y Y Y Y Y
IBE-P counter 1 day Y Y Y Y Y
Far-end Performance Monitoring Counters (current and previous 15-minute interval)
HEC-PFE counter 15 minutes Y Y Y Y Y
CD-PFE counter 15 minutes Y Y Y Y Y
CU-PFE counter 15 minutes Y Y Y Y Y
IBE-PFE counter 15 minutes Y Y Y Y Y
Far-end Performance Monitoring Counters (current and previous 1 day interval)
HEC-PFE counter 1 day Y Y Y Y Y
CD-PFE counter 1 day Y Y Y Y Y
CU-PFE counter 1 day Y Y Y Y Y
IBE-PFE counter 1 day Y Y Y Y Y

ITU-T Rec. G.997.1 (09/2005) 63

 Table 7-23/G.997.1 – Line test, diagnostics and status parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
ADSL Transmission System 7.5.1.1 R (M) R (O)
Power Management State 7.5.1.2 R (M) R (O)
Initialization
Success/Failure Cause 7.5.1.3 R (M) R (M)
Last State Transmitted Downstream 7.5.1.4 R (M) R (M)
Last State Transmitted Upstream 7.5.1.5 R (M) R (M)
Attenuation
LATNds 7.5.1.6 R (M) R (O) R (M)
LATNus 7.5.1.7 R (M) R (O) R (M)
SATNds 7.5.1.8 R (M) R (O) R (M)
SATNus 7.5.1.9 R (M) R (O) R (M)
Signal-to-Noise Ratio Margin
SNRMds 7.5.1.10 R (M) R (O) R (M)
SNRMus 7.5.1.11 R (M) R (O) R (M)
Attainable Data rate
ATTNDRds 7.5.1.12 R (M) R (O) R (M)
ATTNDRus 7.5.1.13 R (M) R (O) R (M)
Actual Power Spectral Density
ACTPSDds 7.5.1.14 R (M) R (O)
ACTPSDus 7.5.1.15 R (M) R (O)
Actual Aggregate Transmit Power
ACTATPds 7.5.1.16 R (M) R (O) R (M)
ACTATPus 7.5.1.17 R (M) R (O) R (M)
Channel Characteristics per subcarrier
HLINSCds 7.5.1.18.1 R(M) R (O) R (M)
HLINpsds 7.5.1.18.2 R (M) R (O) R (M)
HLOGMTds 7.5.1.18.3 R (M) R (O) R (M)
HLOGpsds 7.5.1.18.4 R (M) R (O) R (M)
HLINSCus 7.5.1.18.5 R (M) R (O) R (M)
HLINpsus 7.5.1.18.6 R (M) R (O) R (M)
HLOGMTus 7.5.1.18.7 R (M) R (O) R (M)
HLOGpsus 7.5.1.18.8 R (M) R (O) R (M)
Quiet Line Noise PSD per subcarrier
QLNMTds 7.5.1.19.1 R (M) R (O) R (M)
QLNpsds 7.5.1.19.2 R (M) R (O) R (M)
QLNMTus 7.5.1.19.3 R (M) R (O) R (M)
QLNpsus 7.5.1.19.4 R (M) R (O) R (M)

64 ITU-T Rec. G.997.1 (09/2005)

 Table 7-23/G.997.1 – Line test, diagnostics and status parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Signal-to-Noise Ratio per subcarrier
SNRMTds 7.5.1.20.1 R (M) R (O) R (M)
SNRpsds 7.5.1.20.2 R (M) R (O) R (M)
SNRMTus 7.5.1.20.3 R (M) R (O) R (M)
SNRpsus 7.5.1.20.4 R (M) R (O) R (M)
Bit Allocation per subcarrier
BITSpsds 7.5.1.21.1 R (M) R (O)
BITSpsus 7.5.1.21.2 R (M) R (O)
Gain Scaling per subcarrier
GAINSpsds 7.5.1.21.3 R (M) R (O)
GAINSpsus 7.5.1.21.4 R (M) R (O)
TSSpsds 7.5.1.21.5 R (M) R (O)
TSSpsus 7.5.1.21.6 R (M) R (O)

Table 7-24/G.997.1 – Line test, diagnostics and status parameters

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
ADSL Transmission System Y Y Y Y Y
Power Management State Y Y Y Y Y
Initialization
Success/Failure Cause Y Y Y Y Y
Last State Transmitted Downstream Y Y Y
Last State Transmitted Upstream Y Y Y
Attenuation
LATNds Y Y Y Y Y
LATNus Y Y Y Y Y
SATNds Y Y Y
SATNus Y Y Y
Signal-to-Noise Ratio Margin
SNRMds Y Y Y Y Y
SNRMus Y Y Y Y Y
Attainable Data rate
ATTNDRds Y Y Y Y Y
ATTNDRus Y Y Y Y Y
Actual Power Spectral Density
ACTPSDds Y Y Y
ACTPSDus Y Y Y

ITU-T Rec. G.997.1 (09/2005) 65

 Table 7-24/G.997.1 – Line test, diagnostics and status parameters
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Actual Aggregate Transmit Power
ACTATPds Y Y Y Y Y
ACTATPus Y Y Y Y Y
Channel Characteristics per subcarrier
HLINSCds Y Y Y
HLINMTds Y Y Y
HLINpsds Y Y Y
HLOGMTds Y Y Y
HLOGpsds Y Y Y
HLINSCus Y Y Y
HLINMTus Y Y Y
HLINpsds Y Y Y
HLOGMTus Y Y Y
HLOGpsus Y Y Y
Quiet Line Noise PSD per subcarrier
QLNMTds Y Y Y
QLNpsds Y Y Y
QLNMTus Y Y Y
QLNpsus Y Y Y
Signal-to-Noise Ratio per subcarrier
SNRMTds Y Y Y
SNRpsds Y Y Y
SNRMTus Y Y Y
SNRpsus Y Y Y
Bit Allocation per subcarrier
BITSpsds Y Y Y
BITSpsus Y Y Y
Gain Scaling per subcarrier
GAINSpsds Y Y Y
GAINSpsus Y Y Y
TSSpsds Y Y Y
TSSpsus Y Y Y

66 ITU-T Rec. G.997.1 (09/2005)

 Table 7-25/G.997.1 – Channel test, diagnostics and status parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Actual Data Rate 7.5.2.1 R (M) R (O)
Previous Data Rate 7.5.2.2 R (M) R (O)
Actual Interleaving Delay 7.5.2.3 R (M) R (O) R (O)

Table 7-26/G.997.1 – Channel test, diagnostics and status parameters

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Actual Data Rate Y Y Y Y Y
Previous Data Rate Y Y Y Y Y
Actual Interleaving Delay Y Y Y Y Y

Table 7-27/G.997.1 – PTM data path failures

Defined Q- U-C U-R T-/S-
Category/Element
in clause: Interface Interface Interface Interface
Near-end (ATU-C) failures
Out-of-Sync (OOS) failure 7.1.5.1.1 R (M) R(O)
Far-end (ATU-R) failures
Far-end Out-of-Sync (OOS-FE) failure 7.1.5.2.1 R (M) R(O)

Table 7-28/G.997.1 – PTM data path failures

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end failures
Out-of-Sync (OOS) failure Y Y
Far-end failures
Far-end Out-of-Sync (OOS-FE) failure Y Y

ITU-T Rec. G.997.1 (09/2005) 67

 Table 7-29/G.997.1 – PTM data path performance monitoring parameters
Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Counters (current and previous 15-minute interval)
CRC-P counter 15 minutes 7.2.5.1.1 R (M) R(O)
CRCP-P counter 15 minutes 7.2.5.1.1 R (M) R(O)
CV-P counter 15 minutes 7.2.5.1.2 R (M) R(O)
CVP-P counter 15 minutes 7.2.5.1.2 R (M) R(O)
Near-end (ATU-C) Performance Monitoring Counters (current and previous 1 day interval)
CRC-P counter 1 day 7.2.5.1.1 R (M) R(O)
CRCP-P counter 1 day 7.2.5.1.1 R (M) R(O)
CV-P counter 1 day 7.2.5.1.2 R (M) R(O)
CVP-P counter 1 day 7.2.5.1.2 R (M) R(O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 15-minute interval)
CRC-PFE counter 15 minutes 7.2.5.2.1 R (M) R (O)
CRCP-PFE counter 15 minutes 7.2.5.2.1 R (M) R (O)
CV-PFE counter 15 minutes 7.2.5.2.2 R (M) R (O)
CVP-PFE counter 15 minutes 7.2.5.2.2 R (M) R (O)
Far-end (ATU-R) Performance Monitoring Counters (current and previous 1 day interval)
CRC-PFE counter 1 day 7.2.5.2.1 R (M) R (O)
CRCP-PFE counter 1 day 7.2.5.2.1 R (M) R (O)
CV-PFE counter 1 day 7.2.5.2.2 R (M) R (O)
CVP-PFE counter 1 day 7.2.5.2.2 R (M) R (O)

Table 7-30/G.997.1 – PTM data path performance monitoring parameters

Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Counters (current and previous 15-minute interval)
CRC-P counter 15 minutes Y Y
CRCP-P counter 15 minutes Y Y
CV-P counter 15 minutes Y Y
CVP-P counter 15 minutes Y Y
Near-end Performance Monitoring Counters (current and previous 1 day interval)
CRC-P counter 1 day Y Y
CRCP-P counter 1 day Y Y
CV-P counter 1 day Y Y
CVP-P counter 1 day Y Y

68 ITU-T Rec. G.997.1 (09/2005)

 Table 7-30/G.997.1 – PTM data path performance monitoring parameters
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Far-end Performance Monitoring Counters (current and previous 15-minute interval)
CRC-PFE counter 15 minutes Y Y
CRCP-PFE counter 15 minutes Y Y
CV-PFE counter 15 minutes Y Y
CVP-PFE counter 15 minutes Y Y
Far-end Performance Monitoring Counters (current and previous 1 day interval)
CRC-PFE counter 1 day Y Y
CRCP-PFE counter 1 day Y Y
CV-PFE counter 1 day Y Y
CVP-PFE counter 1 day Y Y

Table 7-31/G.997.1 – PTM data path configuration profile

Defined in Q- U-C U-R T-/S-
Category/Element
clause: Interface Interface Interface Interface
Near-end (ATU-C) Performance Monitoring Thresholds (15-minute interval)
CRC-P threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CRCP-P threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CV-P threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CVP-P threshold 15 minutes 7.3.5.1 R/W (O) R (O)
Near-end (ATU-C) Performance Monitoring Thresholds (1 day interval)
CRC-P threshold 1 day 7.3.5.1 R/W (O) R (O)
CRCP-P threshold 1 day 7.3.5.1 R/W (O) R (O)
CV-P threshold 1 day 7.3.5.1 R/W (O) R (O)
CVP-P threshold 1 day 7.3.5.1 R/W (O) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (15-minute interval)
CRC-PFE threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CRCP-PFE threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CV-PFE threshold 15 minutes 7.3.5.1 R/W (O) R (O)
CVP-PFE threshold 15 minutes 7.3.5.1 R/W (O) R (O)
Far-end (ATU-R) Performance Monitoring Thresholds (1 day interval)
CRC-PFE threshold 1 day 7.3.5.1 R/W (O) R (O)
CRCP-PFE threshold 1 day 7.3.5.1 R/W (O) R (O)
CV-PFE threshold 1 day 7.3.5.1 R/W (O) R (O)
CVP-PFE threshold 1 day 7.3.5.1 R/W (O) R (O)

ITU-T Rec. G.997.1 (09/2005) 69

 Table 7-32/G.997.1 – PTM data path configuration profile
Category/Element G.992.1 G.992.2 G.992.3 G.992.4 G.992.5
Near-end Performance Monitoring Thresholds (15-minute interval)
CRC-P threshold 15 minutes Y Y
CRCP-P threshold 15 minutes Y Y
CV-P threshold 15 minutes Y Y
CVP-P threshold 15 minutes Y Y
Near-end Performance Monitoring Thresholds (1 day interval)
CRC-P threshold 1 day Y Y
CRCP-P threshold 1 day Y Y
CV-P threshold 1 day Y Y
CVP-P threshold 1 day Y Y
Far-end Performance Monitoring Thresholds (15-minute interval)
CRC-PFE threshold 15 minutes Y Y
CRCP-PFE threshold 15 minutes Y Y
CV-PFE threshold 15 minutes Y Y
CVP-PFE threshold 15 minutes Y Y
Far-end Performance Monitoring Thresholds (1 day interval)
CRC-PFE threshold 1 day Y Y
CRCP-PFE threshold 1 day Y Y
CV-PFE threshold 1 day Y Y
CVP-PFE threshold 1 day Y Y

70 ITU-T Rec. G.997.1 (09/2005)

 Appendix I

Processing examples
I.1 Illustration of transmitter processing
#define INIT 0xFFFF
#define FLAG 0x7E
#define ESC 0x7D
#define INV 0x20
#define GENPOL 0x8408
unsigned char msg[1024], temp; /* 8 bit unsigned char */
unsigned short int crc; /* 16 bit unsigned integer */
int N, j, msglen;
{
crc = INIT;
msg[0] = 0xFF;
crc = update_crc(msg[0], crc);
msg[1] = 0x03;
crc = update_crc(msg[1], crc);
N = 2;
j = 0;
while (j < msglen)
{
temp = xmit_msg_byte(j++);
crc = update_crc(temp, crc);
if ( (temp = FLAG) || (temp = ESC) )
{
msg[N] = ESC;
msg[N+1] = temp ^ INV;
N = N + 2;
}
else
{
msg[N] = temp;
N = N + 1;
}
}
crc = ~crc;
msg [N] = crc & 0x00FF;
msg[N+1] = (crc >> 8) & 0x00FF;
xmit_msg();
}

unsigned short int update_crc(unsigned char new_byte, unsigned short int

crc_reg)
{
int i;
crc_reg = crc_reg ^ new_byte;
for (i=0; i<8; i++)
if (crc_reg & 0x0001)
crc_reg = (crc_reg>>1) ^ GENPOL;
else
crc_reg = crc_reg >> 1;
return (crc_reg);
}

ITU-T Rec. G.997.1 (09/2005) 71

I.2 Illustration of receiver processing

72 ITU-T Rec. G.997.1 (09/2005)

 BIBLIOGRAPHY

– ITU-T Recommendation I.361 (1999), B-ISDN ATM layer specification.

– ITU-T Recommendation M.20 (1992), Maintenance philosophy for telecommunication
networks.
– ITU-T Recommendation M.2100 (2003), Performance limits for bringing-into-service and
maintenance of international multi-operator PDH paths and connections.
– ITU-T Recommendation M.2101 (2003), Performance limits for bringing-into-service and
maintenance of international multi-operator SDH paths and multiplex sections.
– ITU-T Recommendation M.2120 (2002), International multi-operator paths, sections and
transmission systems fault detection and localization procedures.
– ITU-T Recommendation X.731 (1992) | ISO/IEC 10164-2:1993, Information technology –
Open Systems Interconnection – Systems management: State management function.
– ANSI T1.231-2003, Digital Subscriber Line (DSL) – Layer 1 In-Service Digital
Transmission Performance Monitoring.
– ANSI T1.413-1998, Network to Customer Installation Interfaces – Asymmetric Digital
Subscriber Line (ADSL) Metallic Interface.
– ETSI TS 101 388 V1.3.1 (2002), Transmission and Multiplexing (TM); Access
transmission systems on metallic access cables; Asymmetric Digital Subscriber Line
(ADSL) – European specific requirements [ITU-T Recommendation G.992.1 modified].
– ISO/IEC 3309:1993, Information technology – Telecommunications and information
exchange between systems – High-level data link control (HDLC) procedures – Frame
structure.
– IETF RFC 1700 (1994), Assigned Numbers.
– IETF RFC 2662 (1999), Definitions of Managed Objects for the ADSL Lines.
– IETF RFC 2233 (1997), The Interfaces Group MIB using SMIv2.
– IETF RFC 3440 (2002), Definitions of Extension Managed Objects for Asymmetric Digital
Subscriber Lines.
– IEEE 802.3-2005, IEEE Standard for Information technology – Telecommunications and
information exchange between systems – Local and metropolitan area networks – specific
requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications.

ITU-T Rec. G.997.1 (09/2005) 73

 SERIES OF ITU-T RECOMMENDATIONS

Series A Organization of the work of ITU-T

Series D General tariff principles

Series E Overall network operation, telephone service, service operation and human factors

Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other multimedia signals

Series K Protection against interference

Series L Construction, installation and protection of cables and other elements of outside plant

Series M Telecommunication management, including TMN and network maintenance

Series N Maintenance: international sound programme and television transmission circuits

Series O Specifications of measuring equipment

Series P Telephone transmission quality, telephone installations, local line networks

Series Q Switching and signalling

Series R Telegraph transmission

Series S Telegraph services terminal equipment

Series T Terminals for telematic services

Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects and next-generation networks

Series Z Languages and general software aspects for telecommunication systems

Printed in Switzerland
Geneva, 2006