T Rec G.983.2 200507 I!!pdf e PDF

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.983.2
TELECOMMUNICATION (07/2005)
STANDARDIZATION SECTOR
OF ITU
SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Digital sections and digital line system – Optical line
systems for local and access networks
ONT management and control interface

specification for B-PON
ITU-T Recommendation G.983.2

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 SYSTEMS G.400–G.449
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.

ONT management and control interface specification for B-PON
Summary
In the B-PON system defined in ITU-T Rec. G.983.1 [3] (called ATM-PON in ITU-T Rec. G.983.1),
the ONTs are located at the customer site. The B-PON element management system will only
manage ONTs as part of the B-PON system through the OLT using the ONT management and
control interface (OMCI).
This Recommendation presents requirements for the OMCI. Firstly, it specifies managed entities of a
protocol-independent Management Information Base (MIB) that models the exchange of information
between the OLT and ONT, then it covers the ONT management and control channel, protocol and
detailed messages. This 2nd revised version of ITU-T Rec. G.983.2 incorporates the material from
G.983.2 Amendment 1 (2003), G.983.2 Amendment 2 (2005), G.983.2 Implementers' Guide (2003),
G.983.6 (2002), G.983.7 (2001), G.983.8 (2003), G.983.9 (2004), G.983.10 (2004) into the base text
of G.983.2 (2002). It also includes minor corrections, clarifications, and augmentation of functions.
Source
ITU-T Recommendation G.983.2 was approved on 14 July 2005 by ITU-T Study Group 15
(2005-2008) under the ITU-T Recommendation A.8 procedure.
ITU-T Rec. G.983.2 (07/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 not 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.983.2 (07/2005)

CONTENTS
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Abbreviations................................................................................................................ 3
4 Reference model and terms .......................................................................................... 7
4.1 OMCI in ITU-T Rec. G.983.1 ........................................................................ 7
4.2 ONT functions ................................................................................................ 9
4.3 VP and VC Mux functionality in the ONT .................................................... 12
5 Requirements of the management interface specification ............................................ 12
5.1 Configuration management ............................................................................ 13
5.2 Fault management .......................................................................................... 15
5.3 Performance management .............................................................................. 15
5.4 Security management ..................................................................................... 16
6 Protocol-independent MIB for the OMCI .................................................................... 16
6.1 Managed entities............................................................................................. 17
6.2 Managed entity relation diagrams .................................................................. 23
7 MIB description ............................................................................................................ 40
7.1 ONT equipment management......................................................................... 42
7.2 ANI management............................................................................................ 59
7.3 UNI management............................................................................................ 62
7.4 VP and VC MUX management...................................................................... 218
7.5 Traffic management........................................................................................ 229
8 ONT Management and Control Channel (OMCC) ...................................................... 243
9 ONT management and control protocol ....................................................................... 244
9.1 ONT management and control protocol cell format....................................... 244
9.2 Message flow control and error recovery....................................................... 251
9.3 OMCI handling within the ONT .................................................................... 254
Annex A – Transport of video return path service................................................................... 256
A.1 Network overview .......................................................................................... 256
A.2 Mode 1 STB-ONU Interface .......................................................................... 257
A.3 Mode 1 ONU-network interface..................................................................... 258
A.4 Mode 2 STB-ONU interface .......................................................................... 259
A.5 Mode 2 ONU-network interface..................................................................... 259
Appendix I – OMCI common mechanisms and services......................................................... 261
I.1 Common mechanisms .................................................................................... 261
I.2 Common services ........................................................................................... 270
I.3 Common services with PON protection ......................................................... 307
I.4 Common services with DBA support............................................................. 316
ITU-T Rec. G.983.2 (07/2005) iii

Page
Appendix II – OMCI message set............................................................................................ 319
II.1 General remarks.............................................................................................. 319
II.2 Message layout ............................................................................................... 321
Appendix III – Support of F4/F5 maintenance flows in the ONT ........................................... 351
III.1 General principle ............................................................................................ 351
III.2 Definition of the F4/F5 segment and end-to-end applicability ...................... 351
III.3 OMCI support of F4/F5 flows in the ONT..................................................... 352
Appendix IV – Traffic management options ........................................................................... 353
IV.1 Priority QueueB-PON ........................................................................................ 353
IV.2 Clarification of ONT functional blocks.......................................................... 354
IV.3 An example of the traffic scheduler configuration......................................... 355
Appendix V – MAC addresses and Ether types....................................................................... 357
Appendix VI – Transparent support of video return path service............................................ 358
VI.1 Network overview .......................................................................................... 358
BIBLIOGRAPHY.................................................................................................................... 360
iv ITU-T Rec. G.983.2 (07/2005)

ONT management and control interface specification for B-PON
1 Scope
This Recommendation specifies the ONT Management and Control Interface (OMCI) for the
B-PON system defined in ITU-T Rec. G.983.1 [3] (called ATM-PON in ITU-T Rec. G.983.1) to
enable multi-vendor interoperability between the OLT and the ONT.
The OMCI specification addresses the ONT configuration management, fault management and
performance management for B-PON system operation and for several services including:
• ATM adaptation layers 1, 2, and 5;
• Circuit Emulation Service;
• Ethernet services, including MAC Bridged LAN, VLAN tagging and filtering;
• Internet Protocol Routing;
• Wireless LAN (IEEE 802.11) service;
• ADSL and VDSL services;
• Voice services, including ISDN;
• Wavelength division multiplexing, including video;
• PON protection switching;
• Dynamic Bandwidth Assignment;
• Enhanced Security.
The focus of this OMCI specification is on FTTH and FTTBusiness ONTs. The Recommendation
defines a protocol necessary to support the capabilities identified for these ONTs. It also allows
optional components and future extensions.
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] ITU-T Recommendation G.784 (1999), Synchronous digital hierarchy (SDH) management.
[2] ITU-T Recommendation G.774 (2001), Synchronous digital hierarchy (SDH) –
Management information model for the network element view.
[3] ITU-T Recommendation G.983.1 (2005), Broadband optical access systems based on
Passive Optical Networks (PON).
[4] ITU-T Recommendation I.321 (1991), B-ISDN protocol reference model and its
application.
[5] ITU-T Recommendation I.363.1 (1996), B-ISDN ATM Adaptation Layer specification:
Type 1 AAL.
ITU-T Rec. G.983.2 (07/2005) 1

Type 5 AAL.
[7] ITU-T Recommendation I.371 (2004), Traffic control and congestion control in B-ISDN.
[8] ITU-T Recommendation I.610 (1999), B-ISDN operation and maintenance principles and
functions.
[9] ITU-T Recommendation I.751 (1996), Asynchronous transfer mode management of the
network element view.
[10] ITU-T Recommendation Q.824.6 (1998), Stage 2 and stage 3 description for the Q3
interface – Customer administration: Broadband Switch Management.
[11] ITU-T Recommendation I.432.1 (1999), B-ISDN user-network interface – Physical layer
specification: General characteristics.
[12] ITU-T Recommendation I.356 (2000), B-ISDN ATM layer cell transfer performance.
[13] IEEE 802.1D-2004, Media Access Control (MAC) Bridges.
Type 2 AAL.
[15] ITU-T Recommendation I.366.1 (1998), Segmentation and Reassembly Service Specific
Convergence Sublayer for the AAL type 2.
[16] ITU-T Recommendation I.366.2 (2000), AAL type 2 service specific convergence sublayer
for narrow-band services.
[17] IETF RFC 2096 (1997), IP Forwarding Table MIB.
[18] IEEE 802.1Q-2003, Virtual Bridged Local Area Networks.
[19] IEEE 802.11-1999, Standard for Information technology – Telecommunications and
information exchange between systems – Local and Metropolitan Area networks – Specific
requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) specifications, Annex D.
[20] ITU-T Recommendation G.997.1 (2005), Physical layer management for digital subscriber
line (DSL) transceivers.
[21] IETF RFC 3728 (2004), Definitions of Managed Objects for Very High Speed Digital
Subscriber Lines (VDSL).
[22] ITU-T Recommendation G.983.3 (2001), A broadband optical access system with
increased service capability by wavelength allocation.
increased service capability using dynamic bandwidth assignment.
enhanced survivability.
[25] SCTE 55-1 (2002), Digital Broadband Delivery System: Out Of Band Transport Part 1:
Mode A.
[26] SCTE 55-2 (2002), Digital Broadband Delivery System: Out Of Band Transport Part 2:
Mode B.
2 ITU-T Rec. G.983.2 (07/2005)

3 Abbreviations
This Recommendation uses the following abbreviations:
AAL ATM Adaptation Layer
ABR Available Bit Rate
ABT/DT ATM Block Transfer Delayed Transmission
ABT/IT ATM Block Transfer Immediate Transmission
ADSL Asymmetrical Digital Subscriber Line
AES Advanced Encryption Standard
AN Access Node
ANI Access Node Interface
AP Access Point
APON ATM over Passive Optical Network
APS Automatic Protection Switching
ARC Alarm Reporting Control
ARP Address Resolution Protocol
ATC ATM Transfer Capabilities
ATM Asynchronous Transfer Mode
ATU-C ADSL Transceiver Unit, Central office end
ATU-R ADSL Transceiver Unit, Remote terminal end
AVC Attribute Value Change
BER Bit Error Rate
BES Block Errored Second
B-ISDN Broadband Integrated Services Digital Network
B-PON Broadband Passive Optical Network
BRAS Broadband Remote Access Server
BSS Basic Service Set
CBR Constant Bit Rate
CCA Clear Channel Assessment
CES Circuit Emulation Service
CFI Canonical Format Indicator
CFP Contention Free Period
CLEI Common Language Equipment Identification
CLP Cell Loss Priority
CNR Carrier-to-Noise Ratio
CRC Cyclic Redundancy Check
CSO Composite Second Order
CSS Controlled Slip Second
ITU-T Rec. G.983.2 (07/2005) 3

CTB Composite Triple Beat
CTP Connection Termination Point
CTS Clear To Send
DBA Dynamic Bandwidth Assignment
DBR Deterministic Bit Rate
DCF Distributed Coordination Function
DSL Digital Subscriber Line
DSSS Direct-Sequence Spread Spectrum
DTIM Delivery Traffic Indication Message
ES Errored Second
ESS Extended Service Set
FEC Forward Error Correction
FHSS Frequency-Hopping Spread Spectrum
FTTB Fibre to the Building
FTTBusiness Fibre to the Business
FTTC Fibre to the Curb
FTTCab Fibre to the Cabinet
FTTH Fibre to the Home
GFR Guaranteed Frame Rate
HE Head End
HEC Header Error Control
HN Home Network
HOL Head of the Line
IBSS Independent Basic Service Set
ICMP Internet Control Message Protocol
ICV Integrity Check Value
IF Interface
IP Internet Protocol
IR Infrared
ISDN Integrated Services Digital Network
LAN Local Area Network
LIM Line Interface Module
LME Sublayer Management Entity
LSB Least Significant Bit
LT Line Terminal
MAC Media Access Control
MCM Multiple Carrier Modulation
4 ITU-T Rec. G.983.2 (07/2005)

ME Managed Entity
MIB Management Information Base
MLME MAC Layer Management Entity
MMPDU MAC Management Protocol Data Unit
MPDU MAC Protocol Data Unit
MSDU MAC Service Data Unit
MSB Most Significant Bit
MSDU MAC Service Data Unit
MTU Maximum Transmission Unit
NMS Network Management System
NSCds Number of Subcarrier – Downstream
NSCus Number of Subcarrier – Upstream
NT Network Terminal
OAN Optical Access Network
ODN Optical Distribution Network
OLT Optical Line Terminal
OMCC ONT Management and Control Channel
OMCI ONT Management and Control Interface
ONT Optical Network Terminal
ONU Optical Network Unit
OpS Operations System
PCF Point Coordination Function
PHY Physical Interface
PLCP Physical Layer Convergence Protocol
PM Performance Monitoring
PMD Physical Medium Dependent
PMS-TC Physical Media Specific – Transmission Convergence
PON Passive Optical Network
POTS Plain Old Telephone Service
PSD Power Spectral Density
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
RF Radio Frequency
RFI Radio Frequency Interference
RM Resource Management
RTS Request To Send
SBR Statistical Bit Rate
ITU-T Rec. G.983.2 (07/2005) 5

SCM Single Carrier Modulation
SDP Simple Device Protocol
SDT Structured Data Transfer
SES Severely Errored Second
SIFS Short Interframe Space
SME Station Management Entity
SNI Service Node Interface
SNR Signal-to-Noise Ratio
SSCS Service-Specific Convergence Sublayer
STA Station
STB Set Top Box
TC Transmission Convergence
TCA Threshold Crossing Alert
TCI Tag Control Information
TE Terminal Equipment
TPID Tag Protocol Identifier
TU Time Unit
UAS Unavailable Seconds
UBR Unspecified Bit Rate
UNI User Network Interface
UPC Usage Parameter Control
VBR Variable Bit Rate
VC Virtual Channel
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VDSL Very High Speed DSL
VID VLAN Identifier
VLAN Virtual Local Area Network
VP Virtual Path
VPC Virtual Path Connection
VPI Virtual Path Identifier
VRP Video Return Path
VTU-O VDSL Transceiver Unit, ONU end (a.k.a. VTU-C)
VTU-R VDSL Transceiver Unit, Remote Terminal end
WEP Wired Equivalent Privacy
WRR Weighted Round Robin
xDSL x Digital Subscriber Line
6 ITU-T Rec. G.983.2 (07/2005)

4 Reference model and terms
4.1 OMCI in ITU-T Rec. G.983.1

The network architecture reference model for B-PON is described in ITU-T Rec. G.983.1 [3] and
shown in Figure 1. The B-PON fits various access network architectures, i.e., Fibre to the Home
(FTTH), Fibre to the Building/Curb (FTTB/C) and Fibre to the Cabinet (FTTCab).
The terminology of ONT, which will be used throughout this Recommendation, is more broadly
defined as an ONU used for the FTTH and Fibre to the Business (FTTBusiness) configurations. In
general, the differences between FTTH and FTTBusiness are that FTTBusiness will serve more
than one end user, have stricter availability requirements, and be able to afford more features and
functions than FTTH. Throughout the text, with the exception of the ONTB-PON Data managed entity
description, the term ONT should generally be read as implying either ONT or ONU, whichever is
appropriate for the particular instance.
The OMCI specification fits into the overall G.983.1 [3] model for an access network system as
illustrated in Figure 1.
Figure 1/G.983.2 − Reference model
For protected B-PON systems, three reference logical models are possible. Protected models 1
and 2 correspond to protection architectures described in ITU-T Rec. G.983.5. Protected model 3
describes an additional protection scheme option.
ITU-T Rec. G.983.2 (07/2005) 7

1) Protected reference model-1
In this model, the termination point of the OMCI is common between the working side and the
protection side. The OMCI specifications specific to this arrangement are described in this
Recommendation in 4.2.1, 7.2.3, and clause I.3.
Figure 2/G.983.2 − Protected reference model-1
2) Reference model-2
In this model, the OMCI has two distinct termination points: one for the working side and one for
the protection side. The OMCI specifications are the same as those in unprotected systems, as either
OMCI connection is identical to that shown in Figure 1.
8 ITU-T Rec. G.983.2 (07/2005)

3) Reference model-3
In this model, the OMCI has two distinct termination points: one for the working side and one for
the protection side. In addition, this model includes separate ONTs for the working side and the
protection side. The OMCI specifications for this model are the same as those for protected
reference model 2.
4.2 ONT functions

As shown in Figure 5, the functions of the ONT are:
a) access network line termination function (AN-LT);
b) user network interface line termination function (UNI-LT), noting that in the Fibre to the
Business case the UNIs from one ONT may belong to different users;
c) ATM multiplexing and de-multiplexing function (ATM-Mux).
Figure 5/G.983.2 − ONT functional diagram
4.2.1 Protection switching modelling

According to ITU-T Rec. G.983.5, there are two types of protection architecture: 1+1 architecture
and 1:1 architecture. Thus, two models can be considered when describing the relationship between
ONT features and protection features.
ITU-T Rec. G.983.2 (07/2005) 9

1) 1+1 model
Figure 6 shows a 1+1 model ONT. In this model, the traffic in the working entity and the traffic in
the protection entity are the same. The TC Adaptor provides the same traffic to the working
PON-LT and the protection PON-LT.
Figure 6/G.983.2 − 1+1 model ONT (ANI side)
2) 1:1 model
Figure 7 shows a 1:1 model ONT. In this model, extra traffic can be supported. The working entity
conveys the traffic in normal operation. If the working entity has failed, or a forced switch/manual
switch to the protection entity operation has been carried out, only the protection entity conveys the
traffic. The TC Adaptor for normal traffic provides the traffic to the working PON-LT when the
working PON-LT is enabled. The TC Adaptor for normal traffic provides the traffic to the
protection entity when the working PON-LT is disabled. The TC Adaptor for extra traffic provides
the extra traffic to the protection entity only when the working entity is enabled.
Figure 7/G.983.2 − 1:1 model ONT (ANI side)
4.2.2 Dynamic bandwidth assignment modelling

A T-CONT buffer managed entity is introduced in order to specify the DBA function. T-CONT
buffer can contain Priority Queues and Traffic Schedulers and be associated with the TC Adapter.
Two models are considered regarding the association between the T-CONT buffers and Priority
Queues or Traffic Schedulers.
10 ITU-T Rec. G.983.2 (07/2005)

In model 1, the Priority Queues, Traffic Schedulers and the T-CONT Buffers are inherently
associated with each other in a fixed fashion. In model 2, the Priority Queues, Traffic Schedulers
and T-CONT buffers can be associated flexibly. Figures 8 and 9 show the two models.
Figure 8/G.983.2 − ONT model 1
Figure 9/G.983.2 − ONT model 2
ITU-T Rec. G.983.2 (07/2005) 11

The simplest and default configuration is for the Priority Queues and T-CONT buffers. This can
guarantee the minimum delay of traffic assuming enough bandwidth is provided for the ONT.
Optionally, one or more stages of WRR and/or HOL scheduling can be installed in order to
guarantee minimum bandwidths, classes of services, and other traffic controls. A multi-stage Traffic
Scheduler can be implemented as shown in Figure 10 as an example.
Figure 10/G.983.2 − ONT model with traffic scheduler
4.3 VP and VC Mux functionality in the ONT

In ITU-T Rec. G.983.1 [3], the end-to-end B-PON system (i.e., OLT, ODN and ONT) can function
as an ATM VP cross-connection with both provisioned and on-demand connectivity. The
configuration of the ATM VP Cross-Connection can be initiated by:
a) the network element operations system via the management interface (e.g., Q3);
b) the Service Node (SN) over a VB5.2 Broadband Bearer Connection Control (B-BCC)
protocol.
The ONT, in contrast, always acts as a provisioned ATM multiplexer. The OMCI itself does not
distinguish between these two cases, because the OLT always provisions the ONT connections via
the OMCI. The OLT can, however, assign different priorities to OMCI messages such that, in the
case of b), a fast response time of the OMCI is achieved.
The OLT and ONT as a whole can function as a VP as well as a VC switch. The ONT itself can
cross-connect traffic at the VP level or the VC level, depending upon implementation. Additionally,
this choice can be different for the ATM and non-ATM UNIs. This is more fully described in 5.1.
5 Requirements of the management interface specification

The OMCI is used by the OLT to control an ONT. This protocol allows the OLT to:
a) establish and release connections across the ONT;
b) manage the UNIs at the ONT;
c) request configuration information and performance statistics;
d) autonomously inform the system operator of events such as link failures.
The OMCI protocol runs across an ATM connection between the OLT controller and the ONT
controller that is established at ONT initialization. The OMCI protocol is asymmetric: the controller
12 ITU-T Rec. G.983.2 (07/2005)

in the OLT is the master and the one in the ONT is the slave. A single OLT controller using
multiple instances of the protocol over separate control channels may control multiple ONTs.
The ONT management and control interface requirements given in this Recommendation are
needed to manage the ONT in the following areas:
a) Configuration management;
b) Fault management;
c) Performance management;
d) Security management.
5.1 Configuration management

Configuration management provides functions to exercise control over, identify, collect data from
and provide data to the ONT. This involves the following:
a) Configuration of equipment;
b) Configuration of the UNIs;
c) Configuration of the VP Network CTPB-PONs and ATM Cross-Connections;
d) Configuration of Interworking VCC Termination Points (non-ATM UNIs only);
e) Configuration of the OAM flows;
f) Configuration of the physical ports;
g) Configuration of AAL profiles;
h) Configuration of service profiles;
i) Configuration of traffic descriptors;
j) Configuration of T-CONT buffers and Traffic Schedulers.
The ONT can support various cross connect and non-cross connect modes at the VP and VC level.
In cases where the ONT provides standard ATM UNI services, the ONT typically supports VP
cross-connection in order to free VPI values on the UNI (the VPI value on the ANI is not free
because the same VPI value cannot be assigned to different ONTs due to the specification of ITU-T
Rec. G.983.1, and VP cross-connection on the ONT resolves this limitation for the UNI).
In the case of non-ATM UNI services, the VC providing the service must be terminated. To
represent this, the OMCI unifies the VC termination and interworking VCCTP into the
Interworking VCC Termination Point ME. Figure 11 shows the termination model. For non-ATM
LIMs, the aggregate of traffic parameters for the various VC terminations is represented by the
Traffic Descriptor Profile Pointer associated with the VP Network CTP that contains the VC
terminations.
ITU-T Rec. G.983.2 (07/2005) 13

Figure 11/G.983.2 − VP cross-connection termination model
For cases such as the support of ONUs with xDSL interfaces, it is generally necessary to implement
VC cross-connections. VC cross-connection can be supported by the ONT/ONU, as indicated by
the termination model shown in Figure 12.
For cases when the ONT provides no ATM interfaces, there are non-cross connected modes of
operation that are available, in either the VP or VC level. However, the implementer may choose to
use cross-connect modes even in this case.
Figure 12/G.983.2 − VC cross-connection termination model
There are eight combinations of cross-connection modes for an ONT. These are listed in Table 0.
Related to this, the ONT has two traffic management modes: Priority-based, or Cell Rate-based. An
ONT implementer is free to choose any cross-connect and traffic management mode combination.
14 ITU-T Rec. G.983.2 (07/2005)

Table 0/G.983.2 − Cross-connection modes for ONTs
Mode ATM IF non-ATM IF
Value ATM layer Cross connection ATM layer
0 VP no VP
1 VP yes VP
2 VP yes VC
3 VP no VC
4 VC no VP
5 VC yes VP
6 VC yes VC
7 VC no VC
5.2 Fault management

The ONT supports limited fault management only. Most of the operations are limited to failure
indication. The OMCI supports failure reporting on the following managed entities that are
described throughout clause 7:
a) ONTB-PON;
b) Subscriber Line Cardholder;
c) Subscriber Line Card;
d) Physical Path Termination Point ATM UNI;
e) Physical Path Termination Point Ethernet UNI;
f) Physical Path Termination Point CES UNI;
g) TC AdapterB-PON;
h) Interworking VCC Termination Point;
i) VP Network CTPB-PON;
j) Physical Path Termination Point POTS UNI;
k) Physical Path Termination Point ADSL UNI;
l) Physical Path Termination Point VDSL UNI;
m) ONUB-PON;
n) VC Network CTPB-PON.
An alarm table is defined for each of these entities.
The ONT shall also support selective OAM cell loop-back testing at the UNI. The ONT diagnostics
are limited to the ONT self test. The OLT or element manager will process the information from the
ONT; for example, the OLT will determine the severity of each alarm when reporting it to the
network operator. ATM management of continuity monitoring is not a part of this Recommendation
(see [B-1] and ITU-T Rec. I.751 [9]).
5.3 Performance management

The ONT has only limited performance monitoring. For the low-cost FTTH ONT, the performance
monitoring is limited to PMD and TC layer performance monitoring. However, for the
FTTBusiness ONT, ATM cell level protocol monitoring, traffic management and
UPC disagreement monitoring may be required. The following are related managed entities:
a) UPC Disagreement Monitoring History DataB-PON;
ITU-T Rec. G.983.2 (07/2005) 15

b) AAL 1 Protocol Monitoring History DataB-PON;
c) AAL 5 Protocol Monitoring History DataB-PON;
d) Ethernet Performance Monitoring History Data;
e) CES Physical Interface Monitoring History Data;
f) TC Adapter Protocol Monitoring History Data;
g) AAL 2 CPS Protocol Monitoring History DataB-PON;
h) Priority QueueB-PON;
i) MAC Bridge PM History Data;
j) MAC Bridge Port PM History Data;
k) Voice PM History Data;
l) VP PM History Data;
m) IP Router PM History Data 1;
n) IP Router PM History Data 2;
o) ICMP PM History Data 1;
p) ICMP PM History Data 2;
q) VC PM History Data;
r) Ethernet Performance Monitoring History Data 2;
s) IEEE 802.11 Counters;
t) ADSL ATU-C Performance Monitoring History Data;
u) ADSL ATU-R Performance Monitoring History Data;
v) ADSL ATU-C Channel Performance Monitoring History Data;
w) ADSL ATU-R Channel Performance Monitoring History Data;
x) TC Adaptor Performance Monitoring History Data ADSL;
y) VDSL VTU-O Physical Interface Monitoring History Data;
z) VDSL VTU-R Physical Interface Monitoring History Data;
z1) VDSL VTU-O Channel Performance Monitoring History Data;
z2) VDSL VTU-R Channel Performance Monitoring History Data;
z3) AAL 2 SSCS Protocol Monitoring History DataB-PON.
Note that it is not required to upload all the performance monitoring-related managed entities during
the MIB upload (see 7.1.2). Furthermore, all PM objects are created at the request of the OLT.
All the history data shall be maintained in the OLT. ATM management of performance monitoring
is not a part of this Recommendation (see [B-1] and ITU-T Rec. I.751 [9]).
5.4 Security management

There are no security features of the OMCI.
6 Protocol-independent MIB for the OMCI

The OMCI should be defined to allow vendors to offer modular, incremental capabilities to meet
different levels of customer needs. This Recommendation first targets FTTH and FTTBusiness
ONTs. It defines a protocol necessary to support capabilities identified by ITU-T Rec. G.983.1 [3].
It is important for early deployment and interoperability, yet it allows for optional components and
future extensions.
16 ITU-T Rec. G.983.2 (07/2005)

A protocol-independent MIB is used to describe the exchange of information across the OMCI and
forms the basis from which protocol-specific models (e.g., Simple Device Protocol for the ONT)
are defined. This MIB has as much commonality as possible with the related generic MIB as
defined in other ITU-T Recommendations. It is intended to make the OMCI relatively simple while
maintaining consistency with the MIB used by the interface between the network-element manager
and the OLT.
6.1 Managed entities

The protocol-independent MIB presented in this Recommendation has been defined in terms of
managed entities. The managed entities are abstract representations of resources and services in an
ONT.
This Recommendation uses three levels for indicating the degree of compliance necessary for
specific functions and managed entities associated with the OMCI specification:
• Requirement (R): Entities necessary for operational compatibility;
• Conditional Requirements (CR): Entities necessary when the specified optional function
is implemented;
• Option (O): Entities that may be useful and required by an operator but that are not
necessary for operational compatibility.
The possible managed entities are listed in Table 1.
Table 1/G.983.2 − Managed entities in the OMCI

Required/ Defined in
Managed entity Description
Optional clause
802.1p Mapper Service Profile O Used to define mapping of 802.1 frames to 7.3.95
VCC TPs based on 802.1p priority bits
802.11 Counters O Used for IEEE 802.11 interface supported by 7.3.61
the ONT
802.11 General Purpose Object CR Used for IEEE 802.11 interface supported by 7.3.59
the ONT
802.11 MAC&PHY Operation CR Used for IEEE 802.11 interface supported by 7.3.60
and Antenna Data the ONT
802.11 PHY FHSS DSSS IR O Used for IEEE 802.11 interface supported by 7.3.62
Tables the ONT
802.11 Station Management CR Used for IEEE 802.11 interface supported by 7.3.57
data 1 the ONT
802.11 Station Management CR Used for IEEE 802.11 interface supported by 7.3.58
data 2 the ONT
802.1p Mapper Service Profile CR Used for 802.1p Priority Mapping of data 7.3.95
interfaces
AAL 1 ProfileB-PON CR Used when the ONT supports CES UNIs 7.3.8
AAL 1 Protocol Monitoring O Used when AAL 1 layer performance 7.3.9
History DataB-PON monitoring is supported
AAL 2 CPS Protocol O Used when AAL 2 layer performance 7.3.20
Monitoring History DataB-PON monitoring is supported
AAL 2 ProfileB-PON CR Used when the ONT supports AAL 2 7.3.18
AAL 2 PVC ProfileB-PON CR Used when the ONT supports AAL 2 PVC 7.3.19
ITU-T Rec. G.983.2 (07/2005) 17

Optional clause
AAL 2 SSCS Parameter CR Used when the ONT supports AAL 2 SSCS 7.3.22
Profile 1
AAL 2 SSCS Parameter CR Used when the ONT supports AAL 2 SSCS 7.3.23
Profile 2
AAL 2 SSCS Protocol CR Used when AAL 2 layer performance 7.3.21
Monitoring History DataB-PON monitoring is supported
AAL 5 ProfileB-PON CR Used when the ONT supports LAN UNIs 7.3.10
AAL 5 Protocol Monitoring O Used when AAL 5 layer performance 7.3.11
History DataB-PON monitoring is supported
ADSL ATU-C Channel O Performance monitoring data for an ADSL 7.3.79
Performance Monitoring ATU-C channel
History Data
ADSL ATU-C Performance O Performance monitoring data for an ADSL 7.3.77
Monitoring History Data ATU-C modem Path
ADSL ATU-R Channel O Performance monitoring data for an ADSL 7.3.80
Performance Monitoring ATU-R Channel
History Data
ADSL ATU-R Performance O Performance monitoring data for an ADSL 7.3.78
Monitoring History Data ATU-R modem path
ADSL Channel Configuration CR Contains Configuration for a Channel 7.3.72
Profile
ADSL Channel Downstream CR Contains status on the Downstream Channel 7.3.67
Status Data
ADSL Channel Upstream CR Contains status on the Upstream Channel 7.3.68
Status Data
ADSL Downstream PSD Mask CR Contains Masking information for the 7.3.75
Profile Downstream PSD
ADSL Downstream RFI Bands CR Contains information on the Downstream 7.3.76
Profile RFI Bands
ADSL Line Configuration CR Contains the Line Parameters for an ADSL 7.3.69
Profile Part 1 line
Profile Part 2 line
Profile Part 3 line
ADSL Line Inventory and CR Contains the inventory and status 7.3.65
Status Data Part 1 information on the ADSL Line
ADSL Line Inventory and CR Contains the inventory and status 7.3.66
Status Data Part 2 information on the ADSL Line
ADSL Subcarrier Masking CR Contains masking information for the 7.3.73
Downstream Profile Downstream subcarriers
ADSL Subcarrier Masking CR Contains masking information for the 7.3.74
Upstream Profile Upstream subcarriers
18 ITU-T Rec. G.983.2 (07/2005)

Optional clause
ANI O PON IF, description purposes only, see 7.2.2
clause 7.2 (ANI Management)
ARP Configuration Data CR Used for IP Port supported by the ONT 7.3.47
ARP Service Profile CR Used for IP Port supported by the ONT 7.3.46
ATM VC Cross-Connection O Used for VC multiplexing with VCI 7.4.5
translation in the ONU
ATM VP Cross-Connection CR Used for VP multiplexing with VPI 7.4.2
translation in the ONT
CES Physical Interface O Used for the CES interface performance 7.3.15
Monitoring History Data monitoring
CES Service ProfileB-PON CR Used for CES services supported by the 7.3.12
ONT
Ethernet Performance O Used for Ethernet interface performance 7.3.14
Monitoring History Data monitoring
Ethernet Performance O Used for Ethernet performance monitoring 7.3.55
Monitoring History Data 2
ICMP PM History Data 1 O Used for ICMP performance monitoring 7.3.42
ICMP PM History Data 2 O Used for ICMP performance monitoring 7.3.43
Interworking VCC CR Used for non-ATM UNIs 7.3.7
Termination Point
IP Port Configuration Data CR Used for IP Port supported by the ONT 7.3.37
IP Route Table CR Used for IP Router supported by the ONT 7.3.44
IP Router Configuration Data CR Used for IP Router supported by the ONT 7.3.39
IP Router PM History Data 1 O Used for IP Router performance monitoring 7.3.40
IP Router PM History Data 2 O Used for IP Router performance monitoring 7.3.41
IP Router Service Profile CR Used for IP Router supported by the ONT 7.3.38
IP Static Routes CR Used for IP Router supported by the ONT 7.3.45
LES Service Profile CR Used for LES services supported by the 7.3.25
ONT
Logical N × 64 kbit/s Sub-port CR Used as logical interface for structured CES 7.3.4
ConnectionTermination Point
MAC Bridge Configuration CR Used for MAC bridge supported by the ONT 7.3.30
Data
MAC Bridge PM History Data O Used for MAC bridge performance 7.3.35
monitoring
MAC Bridge Port Bridge CR Used for MAC bridge supported by the ONT 7.3.34
Table Data
MAC Bridge Port CR Used for MAC bridge supported by the ONT 7.3.31
Configuration Data
MAC Bridge Port Designation CR Used for MAC bridge supported by the ONT 7.3.32
Data
ITU-T Rec. G.983.2 (07/2005) 19

Optional clause
MAC Bridge Port Filter O Used for Ether type filtering 7.3.51
Preassign Table
MAC Bridge Port Filter Table CR Used for MAC bridge supported by the ONT 7.3.33
Data
MAC Bridge Port PM History O Used for MAC bridge port performance 7.3.36
Data monitoring
MAC Bridge Service Profile CR Used for MAC bridge supported by the ONT 7.3.29
Multicast Interworking VCC CR Used to manage multicasting support 7.3.97
Termination Point
OLTB-PON O Used for OLT identification for 7.3.96
interoperability facilitation
ONT Data R Used for OMCI MIB management 7.1.2
ONTB-PON R Used for ONT equipment management 7.1.1
ONUB-PON O Used for ONU equipment management 7.1.8
Physical Path Termination CR Used for IEEE 802.11 interface supported by 7.3.56
Point 802.11 UNI the ONT
Physical Path Termination CR Used for the physical path termination point 7.3.63
Point ADSL UNI Part 1 at an ADSL CO modem
Point ADSL UNI Part 2 at an ADSL CO modem
Physical Path Termination CR Used for physical path termination point at 7.3.1
Point ATM UNI the ATM UNI
Point CES UNI the CES UNI
Point Ethernet UNI the Ethernet UNI
Physical Path Termination O Used for ISDN port supported by the ONT 7.3.48
Point ISDN UNI
Physical Path Termination O Used for local craft terminal port 7.3.54
Point LCT UNI
Physical Path Termination CR Used for physical path trail termination point 7.3.26
Point POTS UNI at the POTS UNI
Point VDSL UNI at a VDSL connection
Physical Path Termination O Used for video input port 7.3.53
Point Video ANI
Physical Path Termination O Used for video port 7.3.52
Point Video UNI
PON IF Line Card CR Used for the PON line card plug-in, only 7.1.6
used if PON interface is implemented on a
plug-in unit
20 ITU-T Rec. G.983.2 (07/2005)

Optional clause
PON IF Line Cardholder CR Used for the PON line card plug-in slot, only 7.1.5
used if PON interface is implemented on a
plug-in unit
PON Physical Path O Used for physical path at the ANI, 7.2.1
Termination Point description purpose only, see 7.2 (ANI
Management)
PON TC Adapter O Used for TC layer at PON interface, 7.2.3
description purpose only, see 7.2 (ANI
Management)
Priority QueueB-PON CR Used for ONTs that support priority queues 7.5.1
to multiplex ATM traffic flows
Software Image R Used for the software image of the ONT. 7.1.7
Software image for the subscriber line cards
is optional
Subscriber Line Card CR (Note) Used for the UNI line card plug-in 7.1.4
Subscriber Line Cardholder CR (Note) Used for the UNI line card plug-in slot 7.1.3
TC Adapter Protocol O Used when TC layer performance 7.3.16
Monitoring History Data monitoring is supported
TC AdapterB-PON CR Used for TC layer at the UNI side for the 7.3.6
ATM UNI
TC Adaptor Performance O Performance monitoring data for the ADSL 7.3.81
Monitoring History Data ATM Data Path
ADSL
T-CONT Buffer CR Used when one or more T-CONT buffers are 7.2.4
supported.
Threshold DataB-PON CR Used for the set-up of threshold values 7.3.17
Traffic Descriptors CR Used for the ONT that supports traffic 7.5.2
shaper to specify ATM layer traffic
characteristics in the case of accommodation
of non-ATM UNI. Moreover, in the case of
accommodation of ATM UNI, Traffic
Descriptors may be used for the UPC
function in the ONT, if it is required.
Traffic Scheduler CR Used when Traffic Scheduler is used. 7.5.5
UNIB-PON R User network interface 7.3.5
UPC Disagreement Monitoring CR Used for the ONT that supports UPC 7.5.4
History DataB-PON
VC Network CTPB-PON O Used for VC link termination in the VC 7.4.4
MUX
VC PM History Data O Used for VC performance monitoring 7.4.6
VDSL Band Plan CR Parameters used to configure a VDSL Band 7.3.88
Configuration Profile Plan Configuration Profile.
VDSL Channel Configuration CR Parameters used to configure a VDSL 7.3.87
Profile Channel Configuration Profile
ITU-T Rec. G.983.2 (07/2005) 21

Optional clause
VDSL Channel Data CR Contains the Channel Parameters for VDSL 7.3.85
Fast and Slow channels
VDSL Line Configuration CR Parameters used to configure a VDSL Line 7.3.86
Profile Configuration Profile
VDSL VTU-O Channel O Performance monitoring data for a VDSL 7.3.91
Performance Monitoring VTU-O channel
History Data
VDSL VTU-O Physical Data CR Contains the Physical Layer Parameters for a 7.3.83
VTU-O
VDSL VTU-O Physical O Monitoring Data for a VDSL VTU-O 7.3.89
Interface Monitoring History Physical Interface
Data
VDSL VTU-R Channel O Performance monitoring data for an VDSL 7.3.92
Performance Monitoring VTU-R channel
History Data
VDSL VTU-R Physical Data CR Contains the Physical Layer Parameters for a 7.3.84
VTU-R
VDSL VTU-R Physical O Monitoring Data for a VDSL VTU-R 7.3.90
Interface Monitoring History Physical Interface
Data
Video Return Path Service CR Used for Video Return Path service 7.3.93
Profile
Video Return Path Statistics O Used for Video Return Path service 7.3.94
VLAN Tagging Filter Data O Used for VLAN tagging 7.3.50
VLAN Tagging Operation O Used for VLAN tagging 7.3.49
Configuration Data
Voice CTP CR Used for Voice termination point supported 7.3.27
by the ONT
Voice PM History Data O Used for voice performance monitoring 7.3.28
Voice Service Profile AAL CR Used for AAL Voice services supported by 7.3.24
the ONT
VP Network CTPB-PON R Used for the VP link termination in the 7.4.1
VP Mux
VP PM History Data O Used for VP performance monitoring 7.4.3
NOTE – The preferred solution is that the Subscriber Line Card and Subscriber Line Cardholder managed
entities should always be modelled, regardless of whether or not the ONT has integrated interfaces; however,
for reasons of backward compatibility, these managed entities remain as "CR."
22 ITU-T Rec. G.983.2 (07/2005)

6.2 Managed entity relation diagrams
The relationships between the required managed entities are given in Figures 13 to 31. Figure 13
gives the legend of symbols used in these diagrams. Note that the Threshold DataB-PON managed
entity may be associated with any managed entity that has thresholded counters. This is indicated by
a special symbol to reduce congestion on the figures. Also note that several managed entities in the
figures are optional or conditionally required; hence, they may not be used in some
implementations.
Figure 13/G.983.2 − Legend for managed entity relation diagrams
ITU-T Rec. G.983.2 (07/2005) 23

Figure 14/G.983.2 − Managed entity relation diagram for non-integrated interfaces
NOTE – Physical Path Termination Point refers to any/all actual physical trails (CES, Ethernet, ATM, etc.).
However, the relationship between Physical Path Termination Point and TC AdapterB-PON is only applied for
Physical Path Termination Point ATM UNI.
24 ITU-T Rec. G.983.2 (07/2005)

Figure 14 shows an ONT with cardholders on both UNI and ANI side (an ONT with integrated
interfaces on the UNI and/or ANI side can be modelled by Figure 14 as well, since integrated
interfaces use "pseudo" Subscriber Line Cards and Cardholders). Note that extensions of Figure 14
are possible as well, e.g., an ONT with several Subscriber Line Cardholders on the UNI side and
one integrated PON interface.
As for the ATM functions, there are 12 possible models allowed for ONTs: with four models for the
ATM interfaces, and eight models for the non-ATM interfaces. The six VP models are illustrated in
Figures 15 to 20. It should be noted that in each diagram, the term "VP" can be replaced with "VC",
to produce the VC model.
Figure 15/G.983.2 − Managed entity relation diagram for ATM interfaces with VP level
cross-connections and priority queue-based traffic management
ITU-T Rec. G.983.2 (07/2005) 25

Figure 16/G.983.2 − Managed entity relation diagram for ATM interfaces with VP level
cross-connections and cell rate-based traffic management
26 ITU-T Rec. G.983.2 (07/2005)

Figure 17/G.983.2 − Managed entity relation diagram for non-ATM interfaces with VP level
cross-connections and priority queue-based traffic management
ITU-T Rec. G.983.2 (07/2005) 27

cross-connections and cell rate-based traffic management
28 ITU-T Rec. G.983.2 (07/2005)

non-cross-connect and priority queue-based traffic management
ITU-T Rec. G.983.2 (07/2005) 29

non-cross-connect and cell rate-based traffic management
30 ITU-T Rec. G.983.2 (07/2005)

Figures 21 to 31 show the relation diagrams for the non-ATM interfaces supported to date in the
OMCI. Please note that the Interworking VCC TP managed entity is common between Figures 17
to 20 and between Figures 21 to 31. The diagrams are partitioned in this way for brevity and clarity.
Figure 21/G.983.2 − Managed entity relation diagram for MAC Bridged LAN interfaces
ITU-T Rec. G.983.2 (07/2005) 31

Figure 22/G.983.2 − Managed entity relation diagram for IP router interfaces
32 ITU-T Rec. G.983.2 (07/2005)

Figure 23/G.983.2 − Managed entity relation diagram for structured CES interfaces
ITU-T Rec. G.983.2 (07/2005) 33

Figure 24/G.983.2 − Managed entity relation diagram for unstructured CES interfaces
34 ITU-T Rec. G.983.2 (07/2005)

Figure 25/G.983.2 − Managed entity relation diagram for AAL 2-based voice interfaces
ITU-T Rec. G.983.2 (07/2005) 35

Figure 26/G.983.2 − Managed entity relation diagram for AAL 1-based voice interfaces
36 ITU-T Rec. G.983.2 (07/2005)

Figure 27/G.983.2 − Managed entity relation diagram for ADSL interfaces
ITU-T Rec. G.983.2 (07/2005) 37

Figure 28/G.983.2 − Managed entity relation diagram for VDSL interfaces
Figure 29/G.983.2 − Managed entity relation diagram for IEEE 802.11 interfaces
38 ITU-T Rec. G.983.2 (07/2005)

Figure 30/G.983.2 − Managed entity relation diagram for video interfaces, including the
optional video return path function
ITU-T Rec. G.983.2 (07/2005) 39

Figure 31/G.983.2 − Managed entity relation diagram for 802.1p mapper interfaces
7 MIB description
A detailed description of all ONT managed entities is provided in the clauses that follow. The
descriptions include:
a) the purpose of the entity;
b) the relationship(s) that the entity supports with other managed entities;
c) the attributes of the entity;
40 ITU-T Rec. G.983.2 (07/2005)

d) the management operations that may be performed on the entity;
e) the notifications generated by the managed entity.
These clauses are organized as follows:
a) ONT equipment management;
b) ANI (i.e., PON IF) management;
c) UNI management;
d) VP layer management;
e) traffic management.
A managed entity can be instantiated by the ONT autonomously or on explicit request of the OLT
via a create command.
Attributes of a managed entity for which no create action exists (i.e., a managed entity which is
auto-instantiated by the ONT) can be (R), (W), or (R, W). On the other hand, attributes of a
managed entity for which a create action exists (i.e., a managed entity which is instantiated on
explicit request by the OLT) can be either (R), (W), (R, W), (R, Set-by-create), (W, Set-by-create),
or (R, W, Set-by-create). For attributes that are not "Set-by-create", a default value will be specified
in this Recommendation which will be assigned to the attribute on instantiation of the managed
entity.
The following gives a more detailed explanation for each of the possible cases:
(R): On instantiation of the managed entity (either autonomously or on request
of the OLT via a create action), the ONT sets the attribute to a default
value. The OLT can only read the value of the attribute. In case of an
autonomous attribute value change, the ONT will send an attribute value
change notification to the OLT.
(W): On instantiation of the managed entity (either autonomously or on request
value. The OLT can only write the value of the attribute. In case of an
autonomous attribute value change, the ONT will NOT send an attribute
value change notification to the OLT.
(R, W): On instantiation of the managed entity (either autonomously or on request
value. The OLT can both read and write the value of the attribute. In case
of an autonomous attribute value change, the ONT will send an attribute
value change notification to the OLT.
(R, Set-by-create): On instantiation of the managed entity (by necessity on request of the OLT
via a create action), the ONT sets the attribute to the value specified in the
create command. Subsequently, the OLT can only read the value of the
attribute. In case of an autonomous attribute value change, the ONT will
send an attribute value change notification to the OLT.
(W, Set-by-create): On instantiation of the managed entity (by necessity on request of the OLT
create command. Subsequently, the OLT can only write the value of the
attribute. In case of an autonomous attribute value change, the ONT will
NOT send an attribute value change notification to the OLT.
(R, W, Set-by-create): On instantiation of the managed entity (by necessity on request of the OLT
create command. Subsequently, the OLT can both read and write the value
ITU-T Rec. G.983.2 (07/2005) 41

of the attribute. In case of an autonomous attribute value change, the ONT
will send an attribute value change notification to the OLT.
In all bit vectors indicated in this Recommendation, bit 1 represents the least significant bit, while
bit 8 represents the most significant bit within a byte. If the bit vector is made up of more than one
byte, then the numbering starts from the least significant byte onwards.
In all attribute descriptions that refer to the Boolean values "true" and "false", true will be coded
as 0x01 and false will be coded as 0x00.
In all attribute descriptions that refer to spaces, the value 0x20 must be used for the entire size of the
attribute.
The notifications generated by a managed entity stem from the following events: Alarms, Attribute
Value Changes (AVCs), Threshold Crossing Alerts (TCAs), and Test results. Alarms, TCAs, and
failures of autonomous self tests are all reported via "Alarm" messages. AVCs are reported via
"Attribute Value Change" messages. Test results are reported:
a) via a "Test result" message if the test is invoked by a "Test" command from the OLT;
b) via an "Alarm" message in the case of failure of an autonomous self test (in start-up phase).
Details about these messages and the related coding are in Appendix II.
7.1 ONT equipment management

7.1.1 ONTB-PON
This managed entity represents the ONT as equipment.
An instance of this managed entity is automatically created by the ONT after initialization. After the
creation of this managed entity, the associated attributes are updated according to the data within
the ONT itself.
Relationships
All other managed entities in this Recommendation are related directly or indirectly to the
ONTB-PON entity.
Attributes
Managed Entity id: This attribute provides a unique number for each instance of this managed
entity. There is only one instance and it has the number 0x0000. (R) (mandatory) (2 bytes)
Vendor id: This attribute identifies the vendor of the ONT, and is the same as the 4 most
significant bytes of the ONT serial number as specified in ITU-T Rec. G.983.1. Upon
autonomous instantiation, this attribute consists of all spaces. (R) (mandatory) (4 bytes)
Version: This attribute identifies the version of the ONT as defined by the vendor. The printable
value of "0" shall be used when version information is not available or applicable to the ONT
being represented. Upon autonomous instantiation, this attribute consists of all spaces.
(R) (mandatory) (14 bytes)
Serial Number: The serial number is unique for each ONT. Note that the serial number of the
ONT is already defined in ITU-T Rec. G.983.1 [3] and contains the vendor id and/or the version
number. The first four bytes are the ASCII encoded vendor ID four letter mnemonic. The second
four bytes are a binary encoded 'serial number', under the complete control of the vendor in
question. Upon autonomous instantiation, this attribute consists of all zeroes. (R) (mandatory)
(8 bytes)
42 ITU-T Rec. G.983.2 (07/2005)

Traffic management option: This attribute identifies the upstream traffic management function
implemented in the ONT. There are two options:
1) "Priority controlled upstream traffic" (0x00): the upstream traffic coming from the user is
given a priority.
2) "Cell rate controlled upstream traffic" (0x01): the maximum upstream traffic of each
individual connection is guaranteed.
Note that the Traffic management option will not apply to downstream traffic. In other words,
there is no need for a traffic descriptor for the downstream direction and downstream priority
queues can be used. Upon autonomous instantiation, this attribute is set to the value that
describes the ONT's implementation. The OLT must adapt its model to conform to the ONT's
selection. (R) (mandatory) (1 byte)
VP/VC cross-connection function option: This attribute identifies the support of ATM VP or
VC cross-connection management functions for the interworking connections to non-ATM
UNIs. The value is set according to Table 0. Upon autonomous instantiation, this attribute is set
to the value that describes the ONT's implementation. The OLT must adapt its model to conform
to the ONT's selection. (R) (mandatory) (1 byte)
Battery backup: This attribute provides a Boolean indication of whether or not the ONT
supports battery backup. False will indicate that no battery is provisioned; true indicates that a
battery is provisioned. Upon autonomous instantiation, this attribute is set to false. (R, W)
(mandatory) (1 byte)
Administrative State: This attribute is used to activate (unlock: value 0x00) and deactivate
(lock: value 0x01) the functions performed by instances of this managed entity. Selection of a
default value for this attribute is outside the scope of this Recommendation as it is normally
handled through supplier-operator negotiations. (R, W) (mandatory) (1 byte)
Operational State: This attribute indicates whether or not a managed entity is capable of
performing its task. Valid values are enabled (0x00) and disabled (0x01). (R) (optional) (1 byte)
Equipment id: This attribute may be used to identify the specific type of ONT. In North
America, this may be used for the equipment CLEI code. Upon autonomous instantiation, this
attribute consists of all spaces. (R) (optional) (20 bytes)
OMCC Version: This attribute is used to identify the specific version of the OMCC protocol
being used by the ONT. This is used to allow the OLT to manage a network with ONTs that
support different OMCC versions. Valid values include 0x00 (2000 version), 0x01 (2002
version), and 0x02 (2005 version). Future versions will be added sequentially. Default value is
0x00. (R) (optional) (1 byte)
Vendor Product Code: This attribute is used to provide a vendor-specific product code for the
ONT. Upon autonomous instantiation, this attribute consists of all spaces. (R) (optional)
(2 bytes)
Security Capability: This attribute is used to advertise the advanced security modes of the ONT.
The following codepoints are defined:
0: No extra security features are supported;
1: AES encryption of the downstream payload is supported;
2:.255: Reserved for future use.
Upon autonomous instantiation, this attribute will be set to zero. (R) (optional) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 43

SecurityMode: This attribute is used to select the advanced security mode for the ONT. Note
that all secure VPs in an ONT must use the same security mode at any time. The following
codepoints are defined:
0: Churning algorithm will be used;
1: AES algorithm will be used;
2..255: Reserved for future use.
Upon autonomous instantiation, this attribute will be set to zero. (R, W) (optional) (1 byte)
Total T-CONT buffer number: This attribute provides a total number of T-CONT buffers,
which are not associated with the PON IF line card. Upon autonomous instantiation, this
attribute will be set to zero. (R) (mandatory if DBA supported) (1 byte)
Total Priority Queue number: This attribute provides a total number of priority queues, which
are not associated with the PON IF line card. Upon autonomous instantiation, this attribute will
be set to zero. (R) (mandatory if DBA supported) (1 byte)
Total Traffic Scheduler number: This attribute provides a total number of Traffic Schedulers,
which are not associated with the PON IF line card. The ONT supports NULL function, HOL
(Head Of the Line) scheduling and WRR (Weighted Round Robin) from the priority control and
guarantee of minimum rate control points of view, respectively. If the ONT does not have any
Traffic Scheduler, this attribute should be 0x00. Upon autonomous instantiation, this attribute
will be set to zero. (R) (mandatory if DBA supported) (1 byte)
Actions
Get: Get one or more attributes.
Set: Set one or more attributes.
Reboot: Reboot the ONT.
Test: This action is used to initiate an ONT self test. Test outcome is "Pass" or "Fail".
Synchronize Time: This action is used to synchronize the start time of all Monitoring managed
entities of the ONT with the reference time of the OLT and to reset the registers of the
Monitoring managed entities. The effect of this action is that all counters of all Monitoring
managed entities are set to 0x00 and restart counting. Also, the value of the Interval End Time
attribute of the Monitoring managed entities is set to 0x00 and restarts counting.
Note that no other OMCI action has the same effect: synchronization of the start time is not
guaranteed at start-up or after a MIB reset command (optional).
Notifications
Attribute value change: This notification is used to report autonomous changes to the attributes
of this managed entity. The attribute value change notification shall identify the attribute
changed and its new value. The list of AVCs for this managed entity is given in Table 2a.
Alarm: This notification is used to notify the managed system when a failure has been detected
or cleared. Both ONT and OLT should know the alarm list used by this entity. The alarm list for
this entity is given in Table 2b.
Test result: For the "Test result" event, notification is sent to the OLT via an alarm ONLY if the
ME fails the autonomous self test.
44 ITU-T Rec. G.983.2 (07/2005)

Table 2a/G.983.2 − AVC list for ONTB-PON
Number Attribute value change Description
1-7 N/A
8 OpState Operational state of ONTB-PON
9-16 Reserved
Table 2b/G.983.2 − Alarm list for ONTB-PON

Number Event Description
Alarm
0 EquipmentAlarm A functional failure on an internal interface
1 PoweringAlarm Loss of external power
2 BatteryMissing Battery is provisioned but missing
3 BatteryFailure Battery is provisioned and present but cannot recharge
4 BatteryLow Battery is provisioned and present but its voltage is too low
5 PhysicalIntrusionAlarm Applies if the ONT is supported with detection such as door or box
open
Test result
6 ONTSelfTestFailure ONT has failed autonomous self test
7 DyingGasp ONT is powering off imminently
8-223 Reserved
224-239 Vendor-specific alarms Not to be standardized
7.1.2 ONT data

This managed entity is contained in the ONT managed entity and is used to model the MIB itself.
Clause I.1.2 explains the use of this managed entity with respect to MIB synchronization.
Clause I.1.4 explains the alarm synchronization process, also issued on this managed entity.
An instance of this managed entity is automatically created by the ONT after initialization. After the
creation of this managed entity, the associated attributes are updated according to the data within
the ONT itself.
Relationships
One instance of this managed entity is contained in the instance of the ONT managed entity.
Attributes
MIB data sync: This attribute is used to check the alignment of the MIB of the ONT with the
corresponding MIB within the OLT. MIB data sync is a "sequence number" checked by the OLT
to see if the MIB snapshots for the OLT and ONT have the same sequence number. Refer to I.1.1
for a detailed description of this attribute. Upon autonomous instantiation, this attribute is set to
0x00. (R, W) (mandatory) (1 byte)
Actions
ITU-T Rec. G.983.2 (07/2005) 45

Get all alarms: Latch a snapshot (i.e., copy) of the current alarm statuses of all managed entities
and reset the alarm message counter.
Get all alarms next: Get the latched alarm status of the next managed entity within the current
snapshot.
MIB reset: Reset the MIB data sync attributes to 0x00 and reset the MIB of the ONT to its
default state. This default MIB consists of one instance of the ONTB-PON managed entity, one
instance of the ONT Data managed entity, two instances of the Software Image managed entity,
zero or more instances of the Subscriber Line Cardholder managed entity, zero or more instances
of the PON IF Line Cardholder, and zero or more instances of the Priority QueueB-PON managed
entity (for the priority queues that reside in the ONT).
MIB upload: Latch a snapshot (i.e., copy) of the current MIB.
MIB upload next: Get the latched attribute values of the managed entity within the current
snapshot.
Notifications
None.
7.1.3 Subscriber line cardholder
This managed entity represents the slots of the ONT that are capable of holding Subscriber Line
Cards. One or more of these entities are contained in the ONT. Each Subscriber Line Cardholder
can contain 0 or 1 subscriber Linecard.
An instance of this managed entity shall exist for each slot. Instances of this managed entity are
created automatically by the ONT after the ONT initialization. After the creation of this managed
entity, the associated attributes are updated according to the data within the ONT itself.
Instances of this managed entity are also created for ONTs with integrated interfaces on the UNI
side. They then represent virtual Subscriber Line Cardholders.
Relationships
An instance of the Subscriber Line Cardholder may contain instances of the Subscriber Line
Card managed entity to model the containment of Subscriber Line Cards within slots of the
ONT.
Attributes
entity. The first byte of this two-byte identifier is set to:
• 0x00 if the ONT has non-integrated interfaces on the UNI side
• 0x01 if the ONT has integrated interfaces on the UNI side.
The second byte of this identifier is the slot id.
To accommodate a universal code for the ONT slot id for both PON and UNI interfaces, one
could interpret the least significant 7 bits of the slot id as the actual physical slot number with the
most significant bit serving as an interface type (UNI/ANI) indicator. Therefore, the coding of
the UNI slot id is in the range of 0x01-0x7F (1-127). For reasons of backward compatibility,
integrated Subscriber Line interfaces (i.e., no plug-in UNI cards) can also be associated with a
"pseudo" slot id 0x00. The code 0x01 is used for the leftmost lower slot of the ONT when
looking at the side where the Subscriber Line Cards are plugged in, 0x02 is used for the next slot
just to the right of the previous one, and so forth; numbering on the next higher shelf continues at
its left edge.
NOTE 1 – Up to 127 slots are supported.
46 ITU-T Rec. G.983.2 (07/2005)

Actual Plug-in unit Type: This attribute is equal to the type of the LIM in the cardholder or
equal to a value of 0x00 (= no LIM) if the cardholder is empty. This attribute will then be
redundant with attribute "Type" of the managed entity Subscriber Line Card. (R) (mandatory)
(1 byte)
Expected Plug-in unit Type: This attribute identifies which type of plug-in unit is provisioned
for the slot. For type coding, see Table 3. The value of 0x00 (no LIM) means that the Subscriber
Line Cardholder is not provisioned to contain a LIM. The value of 0xFF (255) means that the
Subscriber Line Cardholder is configured for plug-and-play. Upon autonomous instantiation, this
attribute is set to 0x00. For integrated interfaces, this attribute represents the type of interface.
(R, W) (mandatory) (1 byte)
Actions
Notifications
Attribute Value Change: This notification is used to report autonomous changes of the Actual
Plug-in unit type. The attribute value change notification shall identify the attribute changed and
its new value. The AVCs for this managed entity are listed in Table 4a. For ONTs with
integrated interfaces, AVCs are not supported.
NOTE 2 – In the AVC tables, the numbering follows that of the Attribute mask coding found in Table
II.1. Accordingly, each AVC table has a maximum of 16 entries. If an existing attribute does not emit
AVCs, then "N/A" (not applicable) is listed in the AVC column. "Reserved" is used for numbers that do
not correspond to an existing attribute.
Alarm: This notification is used to notify the management system that there is something wrong
with the provisioned plug-in unit. Both ONT and OLT should know the alarm list (see Table 4b)
used by this entity. In case of no provisioning (no LIM configured) or in case the SubscriberLine
Cardholder has been configured for plug-and-play, no alarms are raised. If the
plugInLIMMissingAlarm is active, the plugInTypeMismatchAlarm shall not be raised. For
ONTs with integrated interfaces, alarms are not supported.
Table 3/G.983.2 − Subscriber line card types

Coding Contents Description
0 no LIM Default value
1 A1.5 ATM 1.544 Mbit/s module
2 A2 ATM 2.048 Mbit/s
3 A6.3 ATM 6.312 Mbit/s module
4 A6.3U ATM 6.312 Mbit/s module, Remote (U-interface)
5 A8 ATM 8.448 Mbit/s
6 A25 ATM 25.6 Mbit/s module
9 A45/34 Configurable ATM 44.736/34.368 Mbit/s module
10 A150SMF SDH ATM STM-1 SMF UNI
11 A150MMF SDH ATM STM-1 MMF UNI
ITU-T Rec. G.983.2 (07/2005) 47

12 A150UTP SDH ATM STM-1 UTP UNI
13 C1.5 (DS1) 1.544 Mbit/s Local (T-interface) AAL 1 module
14 C2.0 (E1) 2.048 Mbit/s Local (T-interface) AAL 1 module
15 C6.3 (J2) 6.312 Mbit/s Local (T-interface) AAL 1 module
16 C-DS1/E1 Configurable DS1/E1 AAL 1 module
17 C-DS1/E1/J1 Configurable DS1/E1/J1 AAL 1 module
18 C6.3U (J2) 6.312 Mbit/s Remote (U-interface) AAL 1 module
19 C192k 192 kbit/s Local (T-interface) AAL 1 module
20 C44.7 (DS3) 44.736 Mbit/s Local (T-interface) AAL 1 module
21 C34.3 (E3) 34.368 Mbit/s Local (T-interface) AAL 1 module
22 10Base-T 10 Base-T Ethernet LAN IF
23 100Base-T 100 Base-T Ethernet LAN IF
24 10/100Base-T 10/100 Base-Tx Ethernet LAN IF
25 Token Ring Token Ring LAN IF
26 FDDI FDDI LAN IF
27 FR Frame relay
28 C1.5 (J1) 1.544 Mbit/s Local (T-interface) AAL 1 module
29 A150SMF SONET ATM OC-3 SMF UNI
30 A150MMF SONET ATM OC-3 MMF UNI
31 A150UTP SONET ATM OC-3 UTP UNI
32 POTS Plain Old Telephony Service
33 ISDN-BRI ISDN Basic Rate Interface
34 Gigabit Ethernet Gigabit Ethernet IF
35 ADSL ADSL IF
36 SHDLS SHDSL IF
37 VDSL VDSL IF
38 Video Service Video module
39 LCT Local craft terminal interface
40 802.11 IEEE 802.11 interface
41 ADSL/POTS Combination ADSL and POTS interfaces
42 VDSL/POTS Combination VDSL and POTS interfaces
43..249 Reserved
250 PON1244155 Asymmetric 1244/155 Mbit/s PON IF
252 PON622symm Symmetric 622/622 Mbit/s PON IF
253 PON155 Symmetric 155/155 Mbit/s PON IF
48 ITU-T Rec. G.983.2 (07/2005)

255 Plug-and- Plug-and-play (for the Subscriber Line Cardholder managed entity only)
play/Unknown Unrecognized module (for the Subscriber Line Card managed entity
only)
Table 4a/G.983.2 − AVC list for subscriber line cardholder

1 ActualType Actual type of LIM in cardholder
2-16 Reserved
Table 4b/G.983.2 − Alarm list for subscriber line cardholder

Number Alarm Description
0 PlugInLimMissingAlarm Configured Plug-in LIM is not present
1 PlugInTypeMismatchAlarm Inserted Plug-in LIM is wrong type
2 ImproperCardRemoval Card has been removed without being deprovisioned. (This is
a redundant alarm that is used to help the OLT distinguish
between transitions from state S2 to state S1 and transitions
from state S4 to state S1. This alarm is sent only when a
transition occurs from state S2 to state S1. See Table 32 for
state diagrams.)
3-223 Reserved
Figure 32 shows a state diagram of the various behaviours of inserting/removing a particular

Subscriber Line Card into/from a Subscriber Line Cardholder that is provisioned to a specific type
or to plug-and-play.
In the figure, state S3' is conceptually identical to state S3 except in the behaviour when entering or
leaving this state upon provisioning or deprovisioning.
In order to avoid a cluttered picture, the following state transitions, although possible, are not shown
in the figure: from S3 to S9 on provisioning of plug-and-play mode, from S3' to S8 on provisioning
of plug-and-play mode, from S9 to S3 on deprovisioning of plug and play-mode, and from S8 to S3'
on deprovisioning of plug-and-play mode.
ITU-T Rec. G.983.2 (07/2005) 49

Figure 32/G.983.2 − Subscriber line cardholder state diagram
NOTE 3 – The state diagram presented in Figure 32 is not applicable for ONTs with integrated interfaces.
50 ITU-T Rec. G.983.2 (07/2005)

7.1.4 Subscriber line card
This managed entity is used to represent the subscriber line card that is provisioned in an ONT slot.
For ONTs with integrated interfaces on the UNI side, this managed entity represents available types
of interfaces. An instance of this managed entity shall be automatically created by the ONT when
the OLT has provisioned the subscriber line card (i.e., when the OLT has set attribute "Expected
Plug-in Unit Type" of the Subscriber Line Cardholder to a specific LIM type). See 7.1.3. Moreover,
an instance of this managed entity can also be created by the ONT at the request of the OLT if the
attribute "Expected Plug-in Unit Type" of the corresponding Subscriber Line Cardholder is equal to
the value 0xFF (255), which corresponds to "plug-and-play". For ONTs with integrated interfaces
on the UNI side, an instance of this managed entity is automatically created for each instance of the
Subscriber Line Cardholder managed entity.
An instance of this managed entity shall be deleted by the ONT when the OLT has deprovisioned
the subscriber line card (i.e., when the OLT has set attribute "Expected Plug-in Unit Type" of the
Subscriber Line Cardholder to 0x00, i.e., "no LIM"). Moreover, an instance of this managed entity
can also be deleted by the ONT on request of the OLT if the attribute "Expected Plug-in Unit Type"
of the corresponding Subscriber Line Cardholder is equal to the value 0xFF, i.e., "plug-and-play".
For ONTs with integrated interfaces on the UNI side, an instance of this managed entity cannot be
deleted by an OLT request.
Relationships
One instance of this managed entity is contained by an instance of the Subscriber Line
Cardholder.
Attributes
entity. The number used is the same as the instance number used for the Subscriber Line
Cardholder managed entity instance containing this Subscriber Line Card instance.
(R, Set-by-create (if applicable)) (mandatory) (2 bytes)
Type: This attribute identifies the Subscriber Line Card type. This attribute is a unique code as
defined in Table 3. The value of 0xFF (255) means "unknown", i.e., the inserted Subscriber Line
Card cannot be recognized by the ONT. In this case, the attribute's Serial Number, Version and
Vendor id do not contain valid information. Upon autonomous instantiation, this attribute is set
to 0x00. (R, Set-by-create (if applicable)) (mandatory) (1 byte)
Number of ports: This attribute gives the quantity of access ports on the Subscriber Line Card.
Upon instantiation, this attribute is set equal to 0x01. (R) (optional) (1 byte)
Serial Number: The serial number is unique for each Subscriber Line Card. Note that the serial
number may contain the vendor id and/or version number. For ONTs with integrated interfaces
on the UNI side, this value is identical to the value of the Serial Number attribute of the
ONTB-PON managed entity Upon instantiation, this attribute consists of all spaces.
Version: This attribute identifies the version of the Subscriber Line Card as defined by the
vendor. A value of 0x00 shall be used when version information is not available or applicable to
the ONT being represented. For ONTs with integrated interfaces on the UNI side, this value is
identical to the value of the Version attribute of the ONTB-PON managed entity. Upon
autonomous instantiation, this attribute consists of all spaces. (R) (mandatory) (14 bytes)
Vendor id: This attribute identifies the vendor of the Subscriber Line Card. For ONTs with
integrated interfaces on the UNI side, this value is identical to the value of the Vendor id
attribute of the ONTB-PON managed entity. Upon instantiation, this attribute consists of all spaces.
(R) (optional) (4 bytes)
ITU-T Rec. G.983.2 (07/2005) 51

Administrative State: This attribute is used to "unlock" (value 0x00) and "lock" (value 0x01)
the functions performed by the Subscriber Line Card. When the administrative state is set to
"lock", all user traffic to and from this Subscriber Line Card is blocked and alarms for this
Subscriber Line Card and all associated managed entities are no longer generated. Selection of a
handled through supplier-operator negotiations. (R, W, Set-by-create (if applicable))
Operational State: This attribute indicates whether or not the managed entity is capable of
performing its task. Valid values are enabled (0x00), disabled (0x01), and unknown (0x02).
Upon instantiation, this attribute is set to (0x02). (R) (optional) (1 byte)
BridgedorIPInd: This attribute indicates whether the Ethernet interface is bridged or derived
from an IP router function (Bridged: 0x00; IP router: 0x01; 0x02 Bridged and IP Router). 0x02
means that both bridged and IP router functions are supported by the subscriber line card. Upon
autonomous instantiation, the value 0x00 is used. (R, W) (optional, only applicable for
subscriber line cards with Ethernet interfaces) (1 byte)
Equipment id: This attribute may be used to identify the vendor's specific type of line card. This
attribute applies only to line cards that do not have integrated interfaces. In North America, this
may be used for the equipment CLEI code. Upon instantiation, this attribute consists of all
spaces. (R) (optional) (20 bytes)
CardConfiguration: This attribute is used to select the appropriate configuration on
configurable line cards (e.g., T1/E1). Table 3 specifies 3 configurable card types: A45/34
(code 9), C-DS1/E1 (code 16), and C-DS1/E1/J1 (code 17). Values are indicated below for the
allowed card types and configurations.
Card Type Configuration Value
A45/34 ATM 44.736 Mbit/s 0x00
ATM 34.368 Mbit/s 0x01
C-DS1/E1 DS1 0x00
E1 0x01
C-DS1/E1/J1 DS1 0x00
E1 0x01
J1 0x02
Upon autonomous instantiation, the value 0x00 is used. (R, W, Set-by-create (if applicable))
(mandatory for configurable line cards) (1 byte)
Actions
Create: Create an instance of this managed entity (optional, only when plug-and-play is
supported).
Delete: Delete an instance of this managed entity (optional, only when plug-and-play is
supported).
Reboot: Reboot the Subscriber Line Card.
Test: Test the Subscriber Line Card (this action is optional).
52 ITU-T Rec. G.983.2 (07/2005)

Notifications
Attribute value change: This notification is used to report autonomous changes of attributes of
this managed entity. The notification shall identify the attribute and its new value. The list of
AVCs for this managed entity is given in Table 5a.
Alarm: This notification is used to notify the management system when a failure has been
detected or cleared. Both ONT and OLT should know the alarm list used by this entity. The
alarm list for this entity is given in Table 5b.
NOTE – For ONTs with integrated interfaces on the UNI side, alarms are not applicable except perhaps
for video support. Use of alarms for video support is considered optional and is for future study.
Test result: For the "Test result" event, notification is sent to the OLT via an alarm ONLY if the
ME fails the autonomous self test.
Table 5a/G.983.2 − AVC list for subscriber line card

1-6 N/A
7 OpState Operational state of Subscriber Line Card
8 N/A
9-16 Reserved
Table 5b/G.983.2 − Alarms list for subscriber line card

0 EquipmentAlarm A failure on an internal interface or failed self test
1 PoweringAlarm LIM fuse failure or failure of LIM DC/DC converter
Test result
2 SelfTestFailure Failure of Subscriber Line Card autonomous self test
3-223 Reserved
7.1.5 PON IF line cardholder

This managed entity represents slots of the ONT that are capable of holding a network card on the
ANI side. An instance of this managed entity shall exist for each slot. Instances of this managed
entity are created automatically by an ONT that supports PON IF plug-in after the ONT
initialization. (For integrated PON interfaces, no instances of this managed entity need to be
created. However, if PON IF-based traffic management features (T-CONTs, Priority queues, and
Traffic Schedulers) are to be modelled, an instance of this entity facilitates this.)
NOTE 1 – This definition merely provides a placeholder to facilitate equipment management of removable
PON IF line cards.
Relationships
An instance of the PON IF Line Cardholder may contain instances of the PON IF Line Card
managed entity to model the containment of PON IF Line Cards within slots of the ONT.
ITU-T Rec. G.983.2 (07/2005) 53

Attributes
entity. The first byte of this two-byte identifier is always 0x00. The second byte of this identifier
is the slot id.
To accommodate a universal code of the ONT slot id for both PON and UNI interfaces, one must
interpret the least significant 7 bits of the slot id as the actual physical slot number with the most
significant bit serving as an interface type (UNI/ANI) indicator. Therefore, the coding of the
PON IF Line Card slot id is in the range of 0x81-0xFF (129-255). The code 0x81 (129) is used
for the leftmost lower slot of the ONT when looking at the side where the PON IF Line Cards are
plugged in, 0x82 (130) is used for the next slot just to the right of the previous one, and so forth;
numbering on the next higher shelf continues at its left edge. (R) (mandatory) (2 bytes)
NOTE 2 – Only up to 127 slots are supported.
Actions
Notifications
None.
7.1.6 PON IF line card
This managed entity is used to model a field-replaceable PON IF Line Card contained within an
ONT.
An instance of this managed entity shall be automatically created by the ONT. (For integrated PON
interfaces, no instances of this managed entity need to be created. However, if PON IF-based traffic
management features (T-CONTs, Priority queues, and Traffic Schedulers) are to be modelled, an
instance of this entity facilitates this.)
NOTE – This definition merely provides a placeholder to facilitate equipment management of removable
PON IF line cards.
Relationships
One instance of this managed entity is contained by an instance of the PON IF Line Cardholder.
Attributes
entity. The number used is the same as the instance number used for the PON IF Line
Cardholder managed entity instance containing this PON IF Line Card instance. (R) (mandatory)
(2 bytes)
Serial Number: The serial number is unique for each PON IF Line Card. Upon autonomous
instantiation, this attribute consists of all spaces. (R) (mandatory) (8 bytes)
Version: This attribute identifies the version of the PON IF Line Card as defined by the vendor.
Upon autonomous instantiation, this attribute consists of all spaces. (R) (mandatory) (14 bytes)
Vendor id: This attribute identifies the vendor of the PON IF Line Card. Upon autonomous
instantiation, this attribute consists of all spaces. (R) (optional) (4 bytes)
Equipment id: This attribute may be used to identify the vendor's specific type of PON interface
card. This attribute applies only to PON interface cards that do not have integrated interfaces. In
North America, this may be used for the equipment CLEI code. Upon instantiation, this attribute
consists of all spaces. (R) (optional) (20 bytes)
54 ITU-T Rec. G.983.2 (07/2005)

Total T-CONT buffer number: This attribute provides a total number of T-CONT buffers,
which are associated with the PON IF line card. Upon autonomous instantiation, the value 0x00
is used. (R) (mandatory) (1 byte)
Total Priority Queue number: This attribute provides a total number of priority queues, which
are associated with the PON IF line card. Upon autonomous instantiation, the value 0x00 is used.
(R) (mandatory) (1 byte)
Total Traffic Scheduler number: This attribute provides a total number of Traffic Schedulers,
which are associated with the PON IF line card. The ONT supports NULL function, HOL (Head
Of the Line) scheduling and WRR (Weighted Round Robin) from the priority control and
guarantee of minimum rate control points of view, respectively. If the ONT does not have any
Traffic Scheduler, this attribute should be 0x00. Upon autonomous instantiation, the value 0x00
is used. (R) (mandatory) (1 byte)
Actions
Reboot: Reboot the PON IF Line Card.
Test: Test the PON IF Line Card (this action is optional and for further study). If testing is used,
a "Test Result" event should be added to the notifications and event list.
Notifications
Attribute Value Change: This notification is used to report autonomous changes to the
attributes of this managed entity. The notification shall identify the attribute that changed and its
new value. If additional attributes are added, any relevant AVCs should be listed in a table.
Alarm: Alarms on the PON IF are transmitted to the OLT by PLOAM messages (see ITU-T
Rec. G.983.1 [3]). There are no OMCI-based alarms for the PON IF.
7.1.7 Software image
This managed entity represents a program stored in the ONT.
Two instances of this managed entity shall be automatically created by the ONT after the creation
of an ONT managed entity (mandatory) and each Subscriber Line Card managed entity (optional –
not applicable for ONTs with integrated interfaces on the UNI side). It is used to report to the
management system the software currently installed in non-volatile memory. After the creation of
the instances of this managed entity, the associated attributes are updated according to the data
within the ONT and Subscriber Line Cards.
Relationships
Two instances of this managed entity are contained in an instance of the ONT and Subscriber
Line Card managed entities.
Attributes
entity. The number consists of a two-byte field. The first field (MSB) identifies the ME instance
(ONT (value 0x00) or removable Subscriber/PON IF Line Card (value 0x01-0x7F/0x81-0xFF))
containing the associated Software Image ME. The second field (LSB) distinguishes between the
two (redundant) Software Image ME instances (values 0x00 and 0x01). (R) (mandatory)
(2 bytes)
Version: This attribute identifies the version of the software. Upon autonomous instantiation,
this attribute consists of all spaces. (R) (mandatory) (14 bytes)
ITU-T Rec. G.983.2 (07/2005) 55

Is committed: This attribute indicates whether the associated software image is "committed"
(value 0x01) or "uncommitted" (value 0x00). By definition, the "committed" software image will
be loaded and executed upon a reboot of the ONT and/or associated removable Subscriber/PON
IF Line Card ME. During normal operation, one software image will always be "committed"
while the other is "uncommitted". Under no circumstances are both software images allowed to
be "committed" at the same time. On the other hand, both software images are only allowed to be
non-committed at the same time if both are invalid. Upon autonomous instantiation, this attribute
of instance 0 shall be initialized to "committed" and this attribute of instance 1 shall be initialized
to "uncommitted". (R) (mandatory) (1 byte)
Is active: This attribute indicates whether the associated software image is "active" (value 0x01)
or "inactive" (value 0x00). By definition, the active software image is one that is currently
loaded and executing in the ONT (or associated Subscriber/PON IF Line Card). Under normal
operation, one software image will always be "active" while the other is "inactive". Under no
circumstances are both software images allowed to be "active" at the same time. On the other
hand, both software images are only allowed to be inactive at the same time if both are invalid.
Upon autonomous instantiation, this attribute of instance 0 shall be initialized to "active" and this
attribute of instance 1 shall be initialized to "inactive". (R) (mandatory) (1 byte)
Is valid: This attribute indicates whether the associated software image is "valid" (value 0x01) or
"invalid" (value 0x00). By definition, a software image is "valid" if it has been verified to be an
executable code image. The verification mechanism is not subject to standardization; however, at
a minimum it must include a data integrity (CRC) check of the entire code image. Upon
autonomous instantiation, the associated code image is verified and this attribute is set according
to the result of this verification. (R) (mandatory) (1 byte)
Actions
Start Download: Initiate a software download sequence to the alternate (i.e., currently inactive)
software image. This action is only valid for a software image that is currently inactive and is not
committed (i.e., is not selected as the bootable image). (optional)
Download Section: Download a section of a software image. This action is only valid for a
software image that is currently being downloaded (image 1 in state S2/image 0 in state S2').
(optional)
End Download: Signal the completion of a download sequence, providing both the valid CRC
and version information for a final verification of an associated downloaded software image.
This action is only valid for a software image that is currently being downloaded (image 1 in
state S2/image 0 in state S2'). (optional)
Activate Image: Load/execute a valid software image. When this action is applied to a software
image that is currently inactive, execution of the current code image is suspended; the associated
software image is loaded from non-volatile memory; and execution of this new code image is
initiated. When this action is applied to a software image that is already active, a soft restart is
performed (i.e., the software image is not reloaded from non-volatile memory, execution of the
current volatile code image is simply restarted). This action is only valid for a valid software
image. (optional)
Commit Image: Select a valid software image to be the default image to be loaded and executed
by the boot code upon start-up (i.e., set the Is_committed attribute value to 0x01 for the
associated Software Image ME and set the Is_committed attribute value to 0x00 for the other
Software Image ME). This action is only valid for a valid software image. (optional)
56 ITU-T Rec. G.983.2 (07/2005)

In Figure 33, a state diagram is given, showing an example of the "life cycle" of software images
under the actions given above. State S0 is a conceptual initialization state when neither of the
software images is valid (i.e., executable). During S0, the OMCC is not functional.
Notifications
None.
ITU-T Rec. G.983.2 (07/2005) 57

Figure 33/G.983.2 − Software image state diagram
58 ITU-T Rec. G.983.2 (07/2005)

7.1.8 ONUB-PON
This managed entity represents the ONU as equipment.
An instance of this managed entity is automatically created by the ONU after initialization. After
the creation of this managed entity, the associated attributes are updated according to the data
within the ONU itself.
The ONUB-PON managed entity has the same Relationships, Attributes, Actions, and Notifications as
the ONTB-PON managed entity. The only difference is the M.E. type, which is useful to higher layer
management systems to identify ONUs as shared network equipment and ONTs as dedicated
termination equipment.
7.2 ANI management

The OMCI will not maintain the basic PON interface information. The OLT will maintain the PON
interface related managed entities and will get all the basic ONT-related information needed for
those managed entities via PLOAM cells (e.g., Transmit Failure) as specified in ITU-T
Rec. G.983.1 [3]. However, these entities are used to hold DBA and APS control information. For
the purpose of description, the ONT will autonomously create one instance of each of the managed
entities "PON Physical Path Termination Point", "ANI" and "PON TC Adapter" upon creation of
the ONTB-PON managed entity. In cases where DBA or APS are provided, the appropriate attributes
will be set accordingly.
7.2.1 PON physical path termination point
An instance of this managed entity represents a point in the ONT where a PON Physical Path
terminates and physical path level functions (e.g., path overhead functions) are performed.
An instance of this managed entity is automatically created by the ONT after initialization.
However, this instance will not be reported during a MIB upload.
Relationships
One or more instances of this managed entity are contained in an instance of the ONT or PON IF
Line Card managed entities.
Attributes
entity. This 2-byte number is directly associated with the physical position of the PON IF. The
first byte is the slot id (defined in 7.1.5). If the PON IF is integrated, this value is 0x80 (128).
The second byte is the port id with value range from 0x01 to 0xFF (1 to 255): 0x01 is used for
the leftmost/lowest port on a PON IF Line Card, 0x02 is used for the next right/upper port, and
so forth. (R) (mandatory) (2 bytes)
Actions
None.
Notifications
None.
7.2.2 ANI
This managed entity is used to organize data associated with the Access Network Interface (ANI)
supported by the ONT. One instance of this managed entity shall exist for each ONT.
However, this instance will not be reported during a MIB upload, unless DBA is supported.
ITU-T Rec. G.983.2 (07/2005) 59

Relationships
One or more instances of this managed entity are contained in an instance of the ONTB-PON or
PON IF Line Card managed entities.
Attributes
entity. This 2-byte number is directly associated with the physical position of the PON IF. The
assigned number is the same as the id of the PON Physical Path Termination Point with which
this ANI is associated. (R) (mandatory) (2 bytes)
SR indication: This boolean attribute indicates the capability of status reporting. The value
TRUE means that the status reporting is available for all T-CONT buffers which are associated
with the ANI. The default value is false. (R) (Mandatory if DBA supported) (1 byte)
Total Data Grant: This attribute provides the total number of data grants that are able to be
supported in this ANI port. Upon autonomous instantiation, this attribute will be set to zero.
(R) (Mandatory if DBA supported) (1 byte)
Total DS Grant: This attribute provides the total number of divided slot grants that are able to
be supported in this ANI port. Upon autonomous instantiation, this attribute will be set to zero.
(R) (Mandatory if DBA supported) (1 byte)
T-CONT reporting types: This attribute provides a special code that indicates the kinds of
reports that this ONT can perform. Value 0x00 means that T-CONT buffer reporting uses one
byte. Value 0x01 means that T-CONT buffer reporting uses one byte or two bytes. Value 0x02
means that T-CONT buffer reporting uses one byte or two or four bytes. More explanation is
described in ITU-T Rec. G.983.4. Upon autonomous instantiation, this attribute will be set to
zero. (R) (Optional) (1 byte)
Actions
Notifications
this managed entity. The notification shall identify the attribute and its new value. The AVCs for
this managed entity are given in Table 6a.
Table 6a/G.983.2 − AVC list for physical path termination point ATM ANI
1 N/A
2 Total Data Grant Number of data grants supported
3 Total DS Grant Number of Divided slot grants supported
4 T-CONT reporting type The type of DBA reports supported
5-16 Reserved
7.2.3 PON TC adapter

An instance of this managed entity represents a point in the ONT where the adaptation of the ATM
Layer to the underlying physical infrastructure (i.e., the PON) takes place. One instance of this
managed entity shall exist for each ONT.
However, this instance will not be reported during an MIB upload, unless APS is supported.
60 ITU-T Rec. G.983.2 (07/2005)

Relationships
One instance of this managed entity will exist for the PON Physical Path Termination Point
managed entity.
Attributes
entity. The assigned number is the same as the id of the PON Physical Path Termination Point
with which this PON TC Adapter is associated. For the 1+1 protection model, the PON TC
Adapter is associated with the PON Physical Path Termination Point of the working entity. For
the 1:1 protection model, the PON TC Adapter is associated with the PON Physical Path
Termination Point of the working entity for normal traffic and of the protection entity for extra
traffic. (R) (mandatory) (2 bytes)
TC Adapter type: This attribute represents PON TC Adapter type. Valid values are provided
below.
0x0: protection function is not available;
0x1: 1+1 architecture is available;
0x2: 1:1 architecture is available and normal traffic shall be adapted;
0x3: 1:1 architecture is available and extra traffic shall be adapted.
Upon autonomous instantiation, this attribute will be set to zero. (R) (mandatory for
PON protection) (1 byte)
Protection pointer: This attribute provides the instance id of the PON Physical Path
Termination Point that serves as the protection entity. This attribute is valid only when
TC adapter type is 0x1 or 0x2. Upon autonomous instantiation, this attribute will be set to zero.
(R) (mandatory for PON protection) (2 bytes)
Revertive Ind: This attribute indicates whether the protection scheme uses revertive mode
(= TRUE, value 0x01) or non-revertive mode (= FALSE, value 0x00). Upon autonomous
instantiation, this attribute will be set to false. (R) (mandatory for PON protection) (1 byte)
Wait To Restore Time: This attribute specifies the amount of time, in seconds, to wait after a
fault clears before restoring traffic to the protected trail/connection/line that initiated the
switching. Upon autonomous instantiation, this attribute will be set to zero. (R, W) (mandatory
for PON protection) (2 bytes)
Switching Guard Time: This attribute specifies the amount of time, in milliseconds, that must
elapse after detection of a fault before a protection trail/connection/line can be used to transport
the normal traffic signal and/or to select the normal traffic signal. Upon autonomous
instantiation, this attribute will be set to zero. (R, W) (optional) (2 bytes)
Actions
Notifications
None.
7.2.4 T-CONT buffer
An instance of this managed entity represents a logical object to the data grant provided by the
OLT. A T-CONT buffer can accommodate ATM cells in priority queues or Traffic Schedulers that
exist in the ATM layer. Therefore, the T-CONT buffer is regarded as a logical buffer.
ITU-T Rec. G.983.2 (07/2005) 61

Relationships
One or more instances of this managed entity are contained in an instance of the ONT managed
entity.
Attributes
entity. This 2-byte number is associated with the physical capability that realizes the T-CONT
buffer. The first byte is the slot id of the PON IF card with which this T-CONT buffer is
associated. For integrated PON IF interfaces, this byte can be associated with "pseudo" slot id
0x80 (128). If the ONT has T-CONT buffers that are not associated with the PON IF card at the
creation of this instance, the first byte of this T-CONT buffer is 0xFF. The second byte is the
T-CONT id that is numbered by the ONT itself. The T-CONT id is numbered in ascending order
with the range of 0x00 to 0xFF in each PON-IF Line Card or ONT core. (R) (mandatory)
(2 bytes)
ANI Pointer: This attribute provides the ANI instance id in which this T-CONT buffer can send
ATM cells in response to one of data grants. Upon autonomous instantiation this attribute
consists of the 0x8001 or 0x8101. (The default value should be decided in consideration of the
backward compatibility.) (R,W) (Mandatory) (2 bytes)
Policy: This attribute represents scheduling policy. Valid values include but are not limited to
"Null" (value 0x00), "HOL" (value 0x01) or "WRR" (value 0x02). Upon autonomous
instantiation this attribute consists of the 0x01. (R) (mandatory) (1 byte)
Actions
Notifications
None.
7.3 UNI management

7.3.1 Physical path termination point ATM UNI
This managed entity represents the point at an ATM UNI in the ONT where physical paths
terminate and physical path level functions (e.g., path overhead functions) are performed.
An instance of this managed entity shall be automatically created/deleted by the ONT upon the
creation/deletion of a Subscriber Line Card of ATM type.
Relationships
One or more instances of this managed entity shall be contained in an instance of a Subscriber
Line Card managed entity classified as ATM type.
Attributes
entity. This 2-byte number is directly associated with the physical position of the UNI. The first
byte is the slot id (defined in 7.1.3). The second byte is the port id with a value range from 0x01
to 0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card, 0x02 is
used for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
Expected type: The following coding is used for this attribute: 0x00 = by autosensing, 0x01 to
0xFE (1 to 254) = one of the values from Table 3 that is compatible with the type of the LIM.
Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
62 ITU-T Rec. G.983.2 (07/2005)

Sensed type: If the value of "Expected type" is not equal to 0x00, then the value of "Sensed
type" equals the value of "Expected type". If the value of "Expected type" equals 0x00, then the
value of "Sensed type" equals one of the values from Table 3 (0x01 to 0xFE) and by necessity is
compatible with the Type of the Subscriber Line Card managed entity. Upon autonomous
instantiation, the value 0x00 is used. (R) (mandatory if the ONT supports LIMs with
configurable interface types, e.g., ATM45/34) (1 byte)
Cable configuration: For an ATM45 interface, there are two options for the cable length. This
attribute is used to select the option. Value 0x00: cable length ≤ 68.6 m; value 0x01 cable length
> 68.6 m. (R, W) (mandatory for interfaces with cable configuration options) (1 byte)
Loopback Configuration: This attribute represents the loopback configuration of this physical
interface. Value 0x00: no loopback; value 0x01: loopback2 ("Loopback2" refers to a loopback at
the ONT to the OLT. The OLT can execute a physical level loopback test after loopback2 is
set.). Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
Operational State: This attribute indicates whether or not this managed entity is capable of
performing its task. The operational state reflects the perceived ability to receive or to generate a
valid signal. Valid values are enabled (0x00) and disabled (0x01). (R) (optional) (1 byte)
Actions
Notifications
this managed entity are given in Table 6b.
alarms for this entity are given in Table 6c. The SDH and SONET interface related alarm should
be consistent with the existing standards. The relevant Recommendations are ITU-T Recs G.744,
M.3100 and Q.834.1.
Table 6b/G.983.2 − AVC list for physical path termination point ATM UNI
1 N/A
2 SensedType Sensed SLC type (values given in Table 3)
3 N/A
4 N/A
5 N/A
6 OpState Operational state
7-16 Reserved
ITU-T Rec. G.983.2 (07/2005) 63

Table 6c/G.983.2 − Alarm list for physical path termination point ATM UNI
0 TF Transmitter failure
1 LOS Loss of signal
2 LOF Loss of frame
3 OOF Out of frame
4 RAI Remote alarm indication
5 ERR Block error
6 OOF (PLCP) Out of frame (physical layer convergence protocol)
7 RAI (PLCP) Remote alarm indication (physical layer convergence protocol)
8 ERR (PLCP) Block error (physical layer convergence protocol)
9 REI (PLCP) Remote error indication (physical layer convergence protocol)
10 SONET/SDH MS-SD Multiplex section – signal degraded
11 SONET/SDH MS-RDI Multiplex section – remote defect indication
12 SONET/SDH MS-ERR Multiplex section – block error
13 SONET/SDH MS-REI Multiplex section – remote error indication
14 SONET/SDH MS-AIS Multiplex section – alarm indication signal
15 SONET/SDH P-RDI Path – remote defect indication
16 SONET/SDH P-ERR Path – block error
17 SONET/SDH P-REI Path – remote error indication
18 SONET/SDH P-AIS Path-alarm indication signal
19 SONET/SDH LOP Loss of pointer in the VC4
20 1.5 M REC 1.544 Mbit/s receive alarm
21 1.5 AIS 1.544 Mbit/s alarm indication signal
22 1.5 M BAIS 1.544 Mbit/s back alarm indication signal
23 6 M REC 6.312 Mbit/s receive alarm
24 6 M SEND 6.312 Mbit/s send alarm
25 6 M ERR 6.312 Mbit/s block error
26 2 M RDI 2.048 Mbit/s remote defect indication
27 2 M E-ERR 2.048 Mbit/s CRC-4 error indication
28 2 M AIS 2.048 Mbit/s alarm indication signal
33 34 M FEBE 34.368 Mbit/s far end block error
36 45 IDLE 44.736 Mbit/s idle
37-223 Reserved
64 ITU-T Rec. G.983.2 (07/2005)

7.3.2 Physical path termination point Ethernet UNI
This managed entity represents the points at an Ethernet UNI in the ONT where physical paths
terminate and physical path level functions (e.g., Ethernet function) are performed.
creation/deletion of a Subscriber Line Card of Ethernet type.
Relationships
Line Card managed entity classified as a native LAN type (e.g., Ethernet).
Attributes
byte is the slot id (defined in 7.1.3). The second byte is the port id with value range from 0x01 to
0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card, 0x02 is used
for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
0xFE (1 to 254) equals one of the values from Table 3 that is compatible with the type of the
LIM. Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
value of "Sensed type" = one of the values from Table 3 and by necessity is compatible with the
Type of Subscriber Line Card managed entity. Upon autonomous instantiation, the value 0x00 is
used. (R) (mandatory if the ONT supports LIMs with configurable interface types, e.g., 10/100
BaseT card) (1 byte)
Auto Detection Configuration: For 10/100 Base-Tx Ethernet interfaces, this attribute is used to
set the configuration options: Auto-sensing: 0x00; 10BaseT: 0x01; 100BaseT: 0x02: Gigabit
Ethernet: 0x03; 10BaseT Auto-sensing: 0x10; 10BaseT (half duplex): 0x11; 100BaseT (half
duplex): 0x12; Gigabit Ethernet (half duplex): 0x13; Gigabit Ethernet Auto-sensing: 0x20. Upon
autonomous instantiation, the value 0x00 is used. (R, W) (mandatory for interfaces with auto
detection options) (1 byte)
Ethernet loopback configuration: This attribute is used to set the Ethernet loopback
configuration: No loopback (value 0x00), Loop3 (value 0x03, Loopback of downstream traffic
after PHY transceiver). Loop 3 is depicted in Figure 34. Upon autonomous instantiation, the
value 0x00 is used. (R, W) (mandatory) (1 byte)
ConfigurationInd: This attribute indicates the configuration status of the Ethernet UNI.
10BaseT (full duplex): 0x01; 100BaseT (full duplex): 0x02; Gigabit Ethernet (full duplex):
0x03; 10BaseT (half duplex): 0x11; 100BaseT (half duplex): 0x12 Gigabit Ethernet (half
duplex): 0x13; When the configuration status is not detected (e.g., Ethernet link is not
established or line card is not yet installed), the value 0x00 is used. Upon autonomous
instantiation, the value 0x00 is used. (R) (mandatory) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 65

MaxFrameSize: This attribute denotes the maximum allowed frame size to be transmitted
across this interface. Upon autonomous instantiation, the value 1518 is used. (R,W) (mandatory)
(2 bytes)
DTEorDCEInd: This attribute indicates whether the Ethernet interface wiring is DTE or DCE
(DCE: 0x00; DTE: 0x01). Upon autonomous instantiation, the value 0x00 is used. (R, W)
PauseTime: This attribute allows the ONT line card to request that the customer terminal
temporarily suspend sending data. Units are in "pause_quanta" (1 pause_quantum equals 512 bits
times of the particular implementation). Values: 0x0000 to 0xFFFF. Upon autonomous
instantiation, the value 0x0000 is used. (R,W) (optional) (2 bytes)
BridgedorIPInd: This attribute indicates whether the Ethernet interface is bridged or derived
from an IP router function (Bridged: 0x00; IP router: 0x01; 0x02: depends on Subscriber Line
Card.) 0x02 means that the SLC "BridgedorIPInd" attribute will be either 0x00 or 0x01. Upon
autonomous instantiation, the value 0x02 is used. (R, W) (optional) (1 byte)
ARC: This attribute is used to control alarm reporting from this managed entity. See I.1.8 for a
complete description. (R, W) (optional) (1 byte)
ARCInterval: This attribute provides a provisionable length of time. See I.1.8 for a complete
description. (R, W) (optional) (1 byte)
PPPoE Filter: This attribute may be used to control filtering of PPPoE packets on this Ethernet
port. The value 0x00 is used to disable filtering. The value 0x01 is used to enable filtering. When
filtering is enabled, all packets other than PPPoE packets will be discarded. Default value is
0x00. (R,W) (optional) (1 byte)
Power control: This attribute controls whether power is provided to an external equipment over
the Ethernet PPTP. Value 0x01 enables power over Ethernet. The default value 0x00 disables
power feed. (R, W) (optional) (1 byte)
Figure 34/G.983.2 − Schematic diagram of Loop 3
Actions
66 ITU-T Rec. G.983.2 (07/2005)

Notifications
this managed entity. The notification shall identify its new value. The AVC list is given in
Table 6d.
alarm list for this entity is given in Table 6e. See also Appendix III.
Table 6d/G.983.2 − AVC list for physical path termination point Ethernet UNI
1 N/A
2 SensedType Sensed type of Ethernet interface. Valid values are 0x01
(10BaseT), 0x02 (100BaseT) and 0x03 (Gigabit).
3 N/A
4 N/A
5 N/A
7-10 N/A
11-16 Reserved
Table 6e/G.983.2 − Alarm list for physical path termination point Ethernet UNI
0 LAN-LOS No carrier at the Ethernet UNI
1-223 Reserved
7.3.3 Physical path termination point CES UNI

This managed entity represents the points at a CES UNI in the ONT where physical paths terminate
and physical path level functions are performed.
creation/deletion of a Subscriber Line Card of CES type.
Relationships
Line Card managed entity classified as CES type.
Attributes
byte is the slot id (defined in 7.1.3). The second byte is the port id with a value range from 0x01
0xFE (1 to 254) equals one of the values from Table 3 that is compatible with the type of the
LIM. Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 67

value of "Sensed type" = one of the values from Table 3 and by necessity is compatible with the
Type of the Subscriber Line Card managed entity. Upon autonomous instantiation, the value
0x00 is used. (R) (mandatory for the case of ONT supports LIMs with configurable interface
types, e.g., C1.5/2/6.3) (1 byte)
CES loopback configuration: This attribute represents the loopback configuration of the
physical interface. (See Figure 35.)
• Value 0x00: no loopback;
• value 0x01: payload loopback;
• value 0x02: line loopback;
• value 0x03: OpS-directed loopback1 (loopback from/to ATM network side);
• value 0x04: OpS-directed loopback2 (loopback from/to CES UNI side);
• value 0x05: OpS-directed loopback3 (loopback of both ATM network side and CES UNI
side);
• value 0x06: Manual button-directed loopback (Read only);
• value 0x07: Network-side Code inband-directed loopback (Read only);
• value 0x08: SmartJack-directed loopback (Read only);
• value 0x09: Network-side Code inband-directed loopback. (ARMED) (Read only).
Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
NOTE – For loopback3, note that both paths are wrapped independently.
Figure 35/G.983.2 − Schematic diagram of loopback1, loopback2, and loopback3
DS1Framing: This attribute indicates the framing structure used. Valid values are
"ExtendedSuperFrame" (0x00), "SuperFrame" (0x01), "UnFrame" (0x02), "G.704" (0x03) and
"JT-G.704" (0x04). Upon autonomous instantiation, the value 0x00 is used. (R, W) (1 byte)
(mandatory)
68 ITU-T Rec. G.983.2 (07/2005)

Encoding: This attribute denotes the encoding scheme required. Valid values are "B8ZS" (value
0x00), "AMI" (value 0x01), "HDB3" (0x02), and "B3ZS" (0x03). Upon autonomous
instantiation, the value 0x00 is used. (R, W) (1 byte) (mandatory)
LineLength: This attribute provides the length of the twisted pair cable from the
physicalPathTTP of type "DS1" interface to the DSX1 cross-connect point or the length of the
DS3 cable from the physicalPathTTP of type "DS3" to the DSX3 cross-connect point. Valid
values are given in Table 6f. Upon autonomous instantiation for DS1 interfaces, the value 0x00
is used for non-power feed type DS1, and the value 0x06 is used for power feed type DS1. Upon
autonomous instantiation for DS3 interfaces, the value 0x0F is used. (R, W) (1 byte) (optional)
DS1Mode: This attribute indicates the mode of DS1 used. The valid values are "Mode#1" (value
0x00), "Mode#2" (value 0x01), "Mode#3" (value 0x02), and "Mode#4" (value 0x03). Moreover,
each Mode is defined as described in Table 6g. Upon autonomous instantiation, the value 0x00 is
used. (R,W) (optional) (1 byte)
Table 6f/G.983.2 − Valid values for LineLength attribute

Value Power feed Line length
0x00 Non-power feed type DS1 0-33.5 m (0-110 ft)
0x01 Non-power feed type DS1 33.5-67.1 m (110-220 ft)
0x06 Power feed type DS1 (Wet-T1), short-haul 0-40.5 m (0-133 ft)
0x07 Power feed type DS1 (Wet-T1), short-haul 40.5-81.1 m (133-266 ft)
0x0A Power feed type DS1 (Wet-T1), short-haul 162.5-199.6 m (533-655 ft)
0x0B Power feed type DS1 (Wet-T1), long-haul 0 dB
0x0C Power feed type DS1 (Wet-T1), long-haul 7.5 dB
0x0D Power feed type DS1 (Wet-T1), long-haul 15 dB
0x0E Power feed type DS1 (Wet-T1), long-haul 22.5 dB
0x0F DS3 power feed 0-68.5 m (0-225 ft)
0x10 DS3 power feed 68.5-137.1 m (226-450 ft)
Table 6g/G.983.2 − Coding of DS1Mode attribute

Mode Connect Line length Power feed Loop back
#1 DS1-CPE Short Haul Without power feed Smart Jack
#2 DS1-CPE Long Haul Without power feed Smart Jack
#3 DS1-NIU-CPE Long Haul Without power feed Intelligent Office Repeater
#4 DS1-NIU-CPE Long Haul With power feed Intelligent Office Repeater
ITU-T Rec. G.983.2 (07/2005) 69

LineType: This attribute denotes the line type used in the application for DS3 or E3 interfaces.
Valid values are:
• 0x00, Other;
• 0x01, ds3m23;
• 0x02, ds3syntran;
• 0x03, ds3CbitParity;
• 0x04, ds3ClearChannel;
• 0x05, e3Framed;
• 0x06, e3plcp.
(R, W) (mandatory for DS3 and E3 interfaces, not applicable to other interfaces) (1 byte)
Actions
Notifications
this managed entity. The notification shall identify its new value. The list of AVCs for this
managed entity is given in Table 7a.
alarm list for this entity is given in Table 7b. These alarms should be consistent with the existing
standards.
Table 7a/G.983.2 − AVC list for physical path termination point CES UNI
1 N/A
2 SensedType Sensed SLC type (values given in Table 3)
3 CESLoopbackConfig Loopback configuration of physical interface
4 N/A
6-8 N/A
9-16 Reserved
70 ITU-T Rec. G.983.2 (07/2005)

Table 7b/G.983.2 − Alarm list for physical path termination point CES UNI
0 TF Transmitter failure
1 LOS Loss of signal
2 LOF Loss of frame
3 OOF Out of frame
4 RAI Remote alarm indication
5 1.5 M BAIS 1.544 Mbit/s back alarm indication signal
6 R-INH Receive alarm – inhibit
8 6 M SEND 6.312 Mbit/s send alarm
9 6 M ERR 6.312 Mbit/s block error
10 6 M BERR 6.312 Mbit/s back error
15 1.5 M REC 1.544 Mbit/s receive alarm
16 1.5 AIS 1.544 Mbit/s alarm indication signal
17 INFO0 INFO0 reception (INFO0)
20-223 Reserved
7.3.4 Logical N × 64 kbit/s sub-port connection termination point

This managed entity is used to generically model logical sub-ports contained within a higher level
physical layer interface (e.g., DS0s within a DS1, DS1s within a DS3, etc.). A single instance of this
managed entity can represent an arbitrary (i.e., consecutive or non-consecutive) group of multiple
channels/time slots (e.g., multiple DS0/DS1) at the user side as an integral bundle.
An instance of this managed entity shall be created by the OLT before the creation of an associated
Interworking VCC Termination Pointer (see 7.3.7, Interworking VCC termination point).
Relationships
Zero or more instances of this ME shall be contained in an instance of the Physical Path
Termination Point CES UNI.
Attributes
entity. (R, Set-by-create) (mandatory) (2 bytes)
Physical Path Termination Pointer: This attribute provides a pointer to the instance of the
corresponding Physical Path Termination Point CES UNI managed entity id. (R, Set-by-create)
(mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 71

List of Time Slots: This attribute provides a bitmap, which indicates the time slots. Each bit
indicates whether the corresponding time slot is included in the connection or not. The
correspondence is as indicated in Table 8. (R, Set-by-create) (mandatory) (12 bytes)
Table 8/G.983.2 − Coding list of time slots

Byte Bit
8 7 6 5 4 3 2 1
1 TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
...
Actions
Create: Create an instance of this managed entity.
Delete: Delete an instance of this managed entity.
Notifications
None.
7.3.5 UNIB-PON
This managed entity is used to organize data associated with the ATM User Network Interfaces
(UNIs) supported by the ONT. For non-ATM UNIs, this is used as a logical ATM UNI. One
instance of this managed entity shall exist for each UNI supported by the ONT.
Instances of this managed entity shall be automatically created/deleted by the ONT immediately
following the creation/deletion of a Subscriber Line Card managed entity. After the creation of an
instance of this managed entity, the associated attributes are updated according to the data within
the Subscriber Line Card (if present) or within the ONT for the case of integrated interfaces on the
UNI side.
Note that this managed entity is an aggregation of UNI and UNIinfo managed entities.
Relationships
Zero or more instances of the UNIB-PON managed entity may be contained in an instance of a
Subscriber Line Card managed entity.
Attributes
entity. This 2-byte number is directly associated with the physical position of the UNI. The
assigned number is the same as the id of the Physical Path Termination Point with which this
UNI is associated. (R) (mandatory) (2 bytes)
Local Maximum Number of Supportable VPCs: This attribute identifies the number of VPCs
that can be supported by the ONT at this end of the interface. Default is 0x0100 (256).
(R) (mandatory for ATM interfaces) (2 bytes)
Local Maximum Number of Allocated VPI Bits: This attribute identifies the maximum
number of allocated bits of the VPI sub-field that can be supported by the ONT at this UNI.
Default is 0x08. (R) (mandatory for ATM interfaces) (1 byte)
72 ITU-T Rec. G.983.2 (07/2005)

Loopback Location Code: This attribute provides the code that identifies incoming ATM layer
OAM loopback cells that are to be looped-back at this UNI (see also Appendix III). The default
of this attribute consists of all 0xFFs. (R, W) (mandatory for ATM interfaces) (16 bytes)
Configuration Option Status: This attribute holds the UNI Configuration Code field. Its bits
are assigned as described in Table 9. Upon autonomous instantiation, the value zero is used.
(R, W) (mandatory) (2 bytes)
the functions performed by the UNI. When the Administrative State attribute is set to "lock", all
user traffic to and from this UNI is blocked and alarms for this UNI and all associated managed
entities are no longer generated. Selection of a default value for this attribute is outside the scope
of this Recommendation as it is normally handled through supplier-operator negotiations. (R, W)
Table 9/G.983.2 − Coding of the configuration option status attribute

Bit Name Setting
1 ServerTrailFaultPropagation 0: Upstream VP-AIS generation in the ATM cell flow is deactivated
ATM layer 1: Upstream VP-AIS generation in the ATM cell flow is activated
2 ServerTrailFaultPropagation 0: All TC layer alarm reporting through the OMCC is inhibited
TC layer 1: All TC layer alarm reporting through the OMCC is not inhibited
3 ServerTrailFaultPropagation 0: All PHY layer alarm reporting through the OMCC is inhibited
PHY layer 1: All PHY layer alarm reporting through the OMCC is not inhibited
4 ServerTrailFaultPropagation 0: All AAL layer alarm reporting through the OMCC is inhibited
AAL layer 1: All AAL layer alarm reporting through the OMCC is not inhibited
5-16 Reserved
Actions
Notifications
None.
7.3.6 TC AdapterB-PON
An instance of this managed entity represents a point in the ATM subscriber line card where the
adaptation of the ATM layer to the underlying physical infrastructure (e.g., SDH or PDH transport
network) takes place. ITU-T Rec. I.321 [4] identifies this adaptation function as one of many
functions performed at the Transmission Convergence (TC) Sublayer of the B-ISDN protocol stack.
This managed entity is responsible for generating alarms that report the (in)ability of the managed
entity to delineate ATM cells from the payload of a terminated digital transmission path.
creation/deletion of an ATM UNI and its Physical Path Termination Point.
Relationships
Zero or more instances of this managed entity shall be contained in the Subscriber Line Card
managed entity. One instance of this managed entity shall exist for each instance of the Physical
Path Termination Point managed entity.
ITU-T Rec. G.983.2 (07/2005) 73

Attributes
entity. The assigned number is the same as the id of the Physical Path Termination Point with
which this TC AdapterB-PON is associated. (R) (mandatory) (2 bytes)
Framer configuration: Some UNIs such as the ATM45 have two methods of mapping ATM
cells into the payload of a DS3 frame: physical layer convergence protocol (PLCP) based
mapping and HEC based mapping. This attribute is used to select the "PLCP option" (value
0x01) or the "HEC option" (value 0x00). Upon autonomous instantiation, this attribute is set to
"PLCP option". (R, W) (mandatory for interfaces with framer configuration options) (1 byte)
Cell Scrambling Control: This attribute is used to activate/deactivate the ATM cell scrambling
function. This attribute is only present for ATM interfaces where ATM cell scrambling may be
controlled, i.e., "activated" (value 0x01) or "deactivated" (value 0x00). [B-7] requires cell
scrambling for ATM/SONET interfaces but allows cell scrambling to be controlled (i.e., turned
on and off) for ATM/DS3 interfaces. Upon autonomous instantiation, this attribute is set to
"activated". (R, W) (mandatory for interfaces with scrambling options) (1 byte)
Cell Rate Decoupling Type: This attribute is used to select the cell rate decoupling type
whenever ITU-T Rec. I.432.1 [11] and [B-8] give different definitions. ITU-T defined type:
0x00; ATM Forum defined type: 0x01. Upon autonomous instantiation, 0x00 is used. (R, W)
(mandatory for interfaces with decoupling options) (1 byte)
Actions
Notifications
alarm list for this entity is given in Table 10b.
Table 10a/G.983.2 − AVC list for TC AdapterB-PON

1-3 N/A
4 OpState Operational state of TC AdapterB-PON
5-16 Reserved
74 ITU-T Rec. G.983.2 (07/2005)

Table 10b/G.983.2 − Alarm list for TC AdapterB-PON
0 LCD Loss of cell delineation
1-223 Reserved
7.3.7 Interworking VCC termination point

An instance of this managed entity represents a point in the ONT where the interworking of a
service (e.g., CES, IP) or underlying physical infrastructure (e.g., nxDSO/DS1/DS3/E3/Ethernet)
takes place. At this point, ATM cells are generated from a bit stream
(e.g., nxDSO/DS1/DS3/E3/Frame Relay/Ethernet) or a bit stream is reconstructed from ATM cells.
Instances of this managed entity are created and deleted by the ONT on request of the OLT.
Establishment of a "CES interworking connection"
Since it is more complicated to introduce the "pointer list" as an attribute, the following mechanism
will be used to create a CES interworking connection:
• for structured service: Create first a VP Network CTPB-PON instance and an N × 64 kbit/s
Sub-port Connection Termination Point instance, and then create an Interworking
VCC Termination Point; the latter would contain a reference to the VP Network CTPB-PON
instance on one hand and the N × 64 kbit/s Sub-port Connection Termination Point instance
on the other hand; or
• for unstructured service: Create first a VP Network CTPB-PON instance, and then create an
interworking VCC Termination Point; the latter would contain a reference to the
VP Network CTPB-PON instance on one hand and to the Physical Path Termination Point
CES UNI instance on the other hand.
Establishment of other connection types
Create first a VP Network CTPB-PON instance, and then create an interworking VCC Termination
Point. The latter would contain a reference to the VP Network CTPB-PON.
Relationships
One instance of this managed entity shall exist for each occurrence of transformation of a data
stream into ATM cells and vice versa. Note that the attributes "AAL Profile pointer" and
"Service Profile pointer" imply relationships to these managed entities.
Attributes
entity. The value 0xFFFF is reserved. (R, Set-by-create) (mandatory) (2 bytes)
VCI Value: This attribute identifies the VCI value associated with this Interworking
VCC Termination Point. (R, Set-by-create) (mandatory) (2 bytes)
VP/VCNetworkCTP Connectivity Pointer: This attribute provides an instance identifier of the
VP Network CTPB-PON or VC Network CTPB-PON that is associated with this Interworking
Interworking Option: This attribute identifies the type of non-ATM function that is being
interworked; the option can be CES (0x00), MAC Bridge LAN (0x01), Voice (0x02) service,
IP Router (0x03), VRP (0x04), or 802.1p mapper (0x05). (R, Set-by-create) (mandatory) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 75

Service Profile Pointer: This attribute provides the service profile type and a pointer to the
instance of a service profile, such as the CES Service ProfileB-PON (if the interworking
option = 0x00), MAC Bridge Service Profile (if the interworking option = 0x01), Voice Service
Profile AAL (if the interworking option = 0x02), IP Router Service Profile (if the interworking
option = 0x03), Video Return Path (if the interworking option = 0x04), or 802.1p mapper service
profile (if interworking option = 0x05). (R, Set-by-create) (mandatory) (2 bytes)
AAL Profile Pointer: This attribute provides the AAL profile type and a pointer to an instance
of AAL Profile such as AAL 1 ProfileB-PON if the interworking option = 0x00, AAL 1
ProfileB-PON or AAL 2 ProfileB-PON if the interworking option = 0x02, or AAL 5 ProfileB-PON if
the interworking option = 0x01, 0x03, 0x05, or 0x04 mode 1. If the interworking option is 0x04
mode 2, then this pointer is not used. (R, Set-by-create) (mandatory) (2 bytes)
Interworking Termination Point pointer: This attribute is used for in the case of Circuit
Emulation Services, and provides a pointer to the associated instance(s) of the following
managed entities (depending on the service provided):
– Physical Path Termination Point CES UNI;
– logical N × 64 kbit/s sub-port Connection Termination Point
In all other non-ATM services, the relationship between the Interworking Termination Point and
the IW VCC Termination point is derived from other managed entity relations, and this attribute
is set to 0x0000, and not used. (R, Set-by-create) (mandatory) (2 bytes)
AAL Loopback configuration: This attribute is used to set the loopback configuration: No
loopback (value 0x00), Loopback 1 (value 0x01, loopback of downstream traffic before FEC of
AAL 1), Loopback 2 (value 0x02, loopback of downstream traffic after FEC of AAL 1),
loopback after AAL (value 0x03, loopback of downstream traffic after any AAL). Loopback
after AAL is depicted in Figure 36. Upon autonomous instantiation, the value 0x00 is used.
PPTP Counter: This attribute represents the number of instances of PPTP managed entities
associated with this instance of the Interworking VCC Termination Point managed entity. If only
one instance of a PPTP managed entity is associated with this instance of the Interworking
VCC Termination Point managed entity, this attribute is set to 0x01. If multiple instances of
PPTP managed entities are associated with this instance of the Interworking VCC Termination
Point managed entity (i.e., in case of AAL 2 multiplexing), this attribute is set to 0xZZ, where
ZZ represents the number of associated PPTP instances. (R) (optional) (1 byte)
76 ITU-T Rec. G.983.2 (07/2005)

Figure 36/G.983.2 − Schematic diagram of loopback after AAL
Actions
Notifications
alarm list for this entity is given in Table 11b. See also Appendix III.
Table 11a/G.983.2 − AVC list for interworking VCC termination point

1-9 N/A
10 OpState Operational state of Interworking VCC Termination Point
11-16 Reserved
ITU-T Rec. G.983.2 (07/2005) 77

Table 11b/G.983.2 − Alarm list for interworking VCC termination point
0 End-to-end VC-AIS-LMIR End-to-end VC-AIS receiving indication (optional)
1 End-to-end VC-RDI-LMIR End-to-end VC-RDI receiving indication (optional)
2 End-to-end VC-AIS-LMIG End-to-end VC-AIS generation indication (optional)
3 End-to-end VC-RDI-LMIG End-to-end VC-RDI generation indication (optional)
4 Segment Loss of Continuity Loss of continuity is detected when the Interworking VCC
Termination Point is a segment end point (optional)
5 End-to-End Loss of Loss of continuity is detected at the Interworking VCC
Continuity Termination Point (optional)
6 CSA Cell starvation alarm
7-223 Reserved
7.3.8 AAL 1 ProfileB-PON

This managed entity organizes data that describes the AAL Type 1 processing functions of the
ONT. It is used with the Interworking VCC Termination Point managed entity.
In an ATM environment, AAL Type 1 configuration parameters are associated with an
Interworking VCC Termination Point managed entity through a pointer relationship. Each instance
of this managed entity defines a combination of parameter values that may be associated with
multiple Interworking VCC Termination Point instances.
This managed entity is instantiated/deleted on request of the OLT.
Relationships
One instance of this managed entity shall exist for each combination of AAL 1 parameter values
used within an ONT and may be associated with zero or more instances of the Interworking
VCC Termination Point.
Attributes
Subtype: This attribute identifies the AAL subtype. Valid values for this attribute are "null"
(value 0x00), "voice-band based on 64 kbit/s" (value 0x01), "Synchronous Circuit Emulation"
(value 0x02), "Asynchronous Circuit Emulation" (value 0x03), "High-quality Audio" (value
0x04) and "Video" (value 0x05). (R, Set-by-create) (mandatory) (1 byte)
CBR Rate: This attribute represents the rate of the CBR service supported by the AAL. Allowed
values are 64 kbit/s (value 0x40), 1544 kbit/s (value 0x0608), 44 736 kbit/s (value 0xAEC0),
n × 64 kbit/s (value n × 0 × 40), 2048 kbit/s (value 0 × 0800), etc. (R, Set-by-create) (mandatory)
(2 bytes)
Forward Error Correction Type: This attribute indicates the FEC method: no FEC (value
0x00), FEC for Loss Sensitive Signal Transport (value 0x01), or FEC for Delay Sensitive Signal
Transport (value 0x02). (R, Set-by-create) (optional) (1 byte)
Structured Data Transfer: This attribute indicates whether Structured Data Transfer (SDT) has
been configured at the AAL. A value of 0x01 means SDT has been selected. A value of 0x00
means that no SDT has been selected. This attribute value cannot be set to 0x01 when the
Forward Error Correction Type attribute equals 0x01. (R, Set-by-create) (optional) (1 byte)
78 ITU-T Rec. G.983.2 (07/2005)

Partially Filled Cells: This attribute identifies the number of leading octets in use.
(R, Set-by-create) (optional) (1 byte)
Clock Recovery Type: This attribute indicates whether the clock recovery type is "synchronous"
(value 0x00), which indicates that timing is derived from the physical interface, "SRTS"
(Synchronous Residual Time Stamp, value 0x01), or "ACR" (Adaptive Clock Recovery, value
0x02). (R, Set-by-create) (mandatory) (1 byte)
Cell Loss Integration Period: This attribute represents the duration in milliseconds of the cell
loss integration period. If the cell loss persists for such a period, the Interworking VCC
Termination Point managed entity associated with this entity will generate a cell starvation
alarm. (R, Set-by-create) (mandatory) (2 bytes)
Actions
Notifications
None.
7.3.9 AAL 1 protocol monitoring history DataB-PON
This managed entity contains the last completed 15-minute interval performance monitoring data
collected as a result of performing Segmentation and Reassembly (SAR) Level and Convergence
Sublayer (CS) protocol monitoring. All the attribute counters, e.g., the Header Errors, are only
updated at the end of each period. Instances of this managed entity are created by the OLT
whenever an instance of the Interworking VCC Termination Point managed entity is created that
represents AAL 1 functions. Instances of this managed entity are deleted by the OLT.
Relationships
One instance of this managed entity can exist for each instance of the Interworking
VCC Termination Point managed entity that represents AAL 1 functions.
Attributes
entity. The assigned number is the same as the Managed Entity id of the corresponding
Interworking VCC Termination Point. (R, Set-by-create) (mandatory) (2 bytes)
Interval End Time: This attribute identifies the most recently finished 15-minute interval. It is a
cyclic counter (modulo 0xFF (256)) that is incremented each time a new interval is finished and
the attribute counters are updated. The value of this attribute is 0x00 during the first 15-minute
interval that starts with the reception of the "synchronize time" action. The value is 0x01 during
the first period after this, and so on. If this managed entity is created after the reception of the
"synchronize time" action, the value of this attribute is set equal to the number of the last
completed interval. The actual counters of this managed entity start counting directly. The
attribute counters are updated at the end of the interval. (R) (mandatory) (1 byte)
Threshold DataB-PON id: This attribute provides a pointer to an instance of the Threshold
DataB-PON managed entity that contains the threshold values for the performance monitoring data
collected by this managed entity. The value 0xFFFF is interpreted as a Null pointer. (R, W,
Set-by-create) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 79

Header Errors: This attribute represents a count of the number of AAL 1 header errors
detected, including those corrected. Header errors include correctable and not correctable CRC
and parity errors. If the actual counter saturates, it remains on its maximum value. Default value
is 0x00. (R) (mandatory) (4 bytes)
Sequence Violations: This attribute represents a count of incoming AAL Type 1 SAR-PDUs
where the sequence count in the PDU header causes a transition from the SYNC state to the
OUT OF SEQUENCE state as defined by ITU-T Rec. I.363.1. If the actual counter saturates, it
remains on its maximum value. Default value is 0x00. (R) (mandatory) (4 bytes)
Cell Loss: This attribute represents a count of the number of lost cells, as detected by the AAL 1
sequence number processing, for example. This count records the number of cells detected as
lost in the network prior to the destination interworking function AAL 1 layer processing. If the
actual counter saturates, it remains on its maximum value. Default value is 0x00. (R)
Cell Misinsertion: This attribute represents a count of sequence violation events that the AAL
CS interprets as misinserted cells as defined by ITU-T Rec. I.363.1. If the actual counter
saturates, it remains on its maximum value. Default value is 0x00. (R) (mandatory) (4 bytes)
Buffer Underflows: This attribute represents a count of the number of times the reassembly
buffer underflows. In the case of a continuous underflow caused by a loss of ATM cell flow, a
single buffer underflow should be counted. If the interworking function is implemented with
multiple buffers, such as a cell level buffer and a bit level buffer, then either buffer underflow
will cause this count to be incremented. If the actual counter saturates, it remains on its
maximum value. Default value is 0x00. (R) (mandatory) (4 bytes)
Buffer Overflows: This attribute represents a count of the number of times the reassembly
buffer overflows. If the interworking function is implemented with multiple buffers, such as a
cell level buffer and a bit level buffer, then either buffer overflow will cause this count to be
incremented. If the actual counter saturates, it remains on its maximum value. Default value is
0x00. (R) (mandatory) (4 bytes)
SDT Pointer Reframes: This attribute represents a count of the number of events in which the
AAL 1 reassembler finds that a structured data pointer is not where it is expected and must be
reacquired. This count is only meaningful for structured data transfer modes as unstructured
modes do not use pointers. If the actual counter saturates, it remains on its maximum value.
Default value is 0x00. (R) (optional) (4 bytes)
SDT Pointer Parity Check Failures: This attribute represents a count of the number of times
the AAL reassembler detects a parity check failure at the point where a structured data pointer is
expected. This count is only meaningful for structured data transfer modes as unstructured
modes do not use pointers. If the actual counter saturates, it remains on its maximum value.
Default value is 0x00. (R) (optional) (4 bytes)
Actions
Get current data: This action returns the current value of one or more actual counters
associated with performance monitoring attributes and the value of the Interval End Time
attribute representing the interval in which the request is made. The values in the specific
counters are reset at the end of the interval.
80 ITU-T Rec. G.983.2 (07/2005)

NOTE – "Get" returns the statistical data stored in the attribute values; "Get current data" returns the
real-time value of the actual counters associated with those attributes.
Support of this action is optional.
Notifications
Threshold Crossing Alert: This notification is used to notify the management system when a
Threshold Crossing Alert (TCA) has been detected or cleared. The TCA change notification "on"
will be sent at the crossing of the threshold by the actual counter; the TCA change notification
"off" will be sent at the end of the 15-min period since that is when the actual counters are reset
to 0x00. The event list for this entity is given in Table 12.
Table 12/G.983.2 − Alarm list for AAL 1 Protocol Monitoring History DataB-PON
Threshold data
counter # (Note)
Threshold Crossing Alert
0 Header errors Header errors threshold crossing 1
1 Sequence Violation Sequence Violation threshold crossing 2
2 Cell loss Cell loss threshold crossing 3
3 Cell misinsertion Cell misinsertion threshold crossing 4
4 Buffer Underflows Buffer Underflows threshold crossing 5
5 Buffer Overflows Buffer Overflows threshold crossing 6
6 SDT Pointer Reframes SDT Pointer Reframes threshold crossing 7
7 SDT Pointer Parity Check SDT Pointer Parity Check Failures 8
Failures threshold crossing
8-223 Reserved
NOTE – This numbering is used with the associated Threshold Data B-PON managed entity. Threshold Data
counter 1 indicates the 1st thresholded counter, etc.
7.3.10 AAL 5 ProfileB-PON

This managed entity organizes data that describe the AAL Type 5 processing functions of the ONT.
It is used with the Interworking VCC Termination Point managed entity.
In an ATM environment, AAL Type 5 configuration parameters are associated with an
Interworking VCC Termination Point managed entity through a pointer relationship. Each instance
of the managed entity defines a combination of parameter values that may be associated with
multiple Interworking VCC Termination Point instances.
This managed entity is instantiated/deleted on request of the OLT.
Relationships
used within an ONT and may be associated with zero or more instances of the Interworking
ITU-T Rec. G.983.2 (07/2005) 81

Attributes
Max CPCS PDU Size: This multi-valued attribute represents the maximum CPCS PDU size that
will be transmitted over the connection in both the upstream and downstream direction of
transmission. (R, Set-by-create) (mandatory) (2 bytes)
AAL Mode: This attribute indicates whether the AAL for the supporting VPC is operating in
one of the following optional modes: message assured (0x00), message unassured (0x01),
streaming assured (0x02), or streaming non-assured (0x03). (R, Set-by-create) (mandatory)
(1 byte)
SSCS Type: This attribute identifies the SSCS type for the AAL. Valid values are "null" (0x00),
"Data SSCS based on SSCOP, assured operation" (0x01), "Data SSCS based on SSCOP,
non-assured operation" (0x02), or "Frame Relay SSCS" (0x03). (R, Set-by-create) (mandatory)
(1 byte)
Actions
Notifications
None.
7.3.11 AAL 5 protocol monitoring history DataB-PON
collected as a result of performing Segmentation and Reassembly (SAR) Level and Convergence
Sublayer (CS) protocol monitoring. All of the attribute counters, e.g., the CRC violations, are only
updated at the end of each period.
Instances of this managed entity are created automatically by the OLT whenever an instance of the
Interworking VCC Termination Point managed entity is created that represents the AAL 5
functions. Instances of this managed entity are deleted by the OLT.
Relationships
One instance of this managed entity can exist for each instance of the Interworking VCC
Termination Point managed entity that represents AAL 5 functions.
Attributes
82 ITU-T Rec. G.983.2 (07/2005)

collected by this managed entity. The value 0x0000 is interpreted as a Null pointer. (R, W,
Sum of Invalid CS Field Errors: This attribute provides a sum-of-errors count for invalid
Convergence Sublayer (CS) field errors. For AAL Type 5, this attribute provides a single count
of the number of CS PDUs discarded due to one of the following error conditions: Invalid
Common Part Indicator (CPI), oversized received SDU, or length violation. If the actual counter
CRC Violations: This attribute represents a count of CRC violations that were detected for the
incoming SAR PDUs. If the actual counter saturates, it remains on its maximum value. Default
value is 0x00. (R) (mandatory) (4 bytes)
Reassembly Timer Expirations: This attribute provides a count of reassembly timer
expirations. If the actual counter saturates, it remains on its maximum value. Default value is
0x00. (R) (mandatory if reassembly timer is implemented) (4 bytes)
BufferOverflows: This attribute indicates the number of times that there was not enough buffer
space for a reassembled packet. Default value is 0x00. (R) (mandatory) (4 bytes)
EncapProtocolErrors: This attribute indicates the number of times that the RFC 1483
encapsulation protocol detects a bad header. Default value is 0x00. (R) (mandatory) (4 bytes)
Actions
Notifications
threshold crossing alert (TCA) is detected or cleared. The TCA change notification "on" will be
sent at the crossing of the threshold by the actual counter; the TCA change notification "off" will
be sent at the end of the 15-minute period since that is when the actual counters are reset to 0x00.
The alarm list for this entity is given in Table 13.
ITU-T Rec. G.983.2 (07/2005) 83

Table 13/G.983.2 − Alarm list for AAL 5 protocol monitoring history dataB-PON
Threshold data
counter # (Note)
0 Invalid Fields Exceeds threshold 1
1 CRC Violation Exceeds threshold 2
2 Reassembly Timer Expirations Exceeds threshold 3
3 Buffer Overflows Exceeds threshold 4
4 Encap Protocol Errors Exceeds threshold 5
5-223 Reserved
7.3.12 CES Service ProfileB-PON

An instance of this managed entity is used to organize data that describe the CES Service functions
of the ONT. An instance of this managed entity shall be created and deleted by the OLT.
Relationships
Zero or more instances of this managed entity shall be contained in the ONTB-PON managed
entity. One instance of this managed entity may be associated with zero or more instances of the
Interworking VCC Termination Point.
Attributes
Managed Entity id: This attribute provides a unique number for the instance of this managed
CES Buffered CDV Tolerance: This attribute represents the duration of user data that must be
buffered by the CES interworking entity to offset the Cell Delay Variation. This timing will be in
10 µs increment. The default value for DS1 CES is 750 µs and 1000 µs for DS3 CES. (R, W,
Channel Associated Signalling: This attribute selects which AAL 1 format should be used. It
applies to structured interfaces only. For unstructured interfaces, this value, if present, must be
set to the default of 0x00. The valid values are basic (0x00), e1Cas (0x01), SfCas (0x02),
ds1EsfCas (0x03), and j2Cas (0x04). (R, W, Set-by-create) (optional) (1 byte)
Actions
Notifications
None.
84 ITU-T Rec. G.983.2 (07/2005)

7.3.13 This clause intentionally left blank
7.3.14 Ethernet performance monitoring history data
This managed entity contains the last completed 15-minute interval collected statistic data for an
Ethernet interface. The statistic data value is only updated at the end of each period.
Instances of this managed entity are created/deleted by the OLT after an instance of Physical Path
Termination Point Ethernet UNI managed entity is created/deleted.
Relationships
One instance of this Ethernet Performance Monitoring History Data managed entity can exist for
each instance of the Physical Path Termination Point Ethernet UNI.
Attributes
entity. This 2-byte number is the same as the id of the Physical Path Termination Point Ethernet
UNI. (R, Set-by-create) (mandatory) (2 bytes)
the statistic data values are updated. The value of this attribute is 0x00 during the first 15-minute
statistic data value is updated at the end of the interval. (R) (mandatory) (1 byte)
FCSErrors: This attribute provides a count of frames received on a particular interface that are
an integral number of octets in length but do not pass the Frame Check Sequence (FCS) check.
The count represented by an instance of this object is incremented when the MAC service returns
the frameCheckError status to the Link Layer Control (LLC) or other MAC user. Received
frames for which multiple error conditions are obtained are counted exclusively according to the
error status presented to the LLC. Default value is 0x00. (R) (mandatory) (4 bytes)
Excessive Collision Counter: This attribute provides a count of frames for which transmission
on a particular interface fails due to excessive collisions. Default value is 0x00. (R) (mandatory)
(4 bytes)
Late Collision Counter: This attribute indicates the number of times that a collision is detected
on a particular interface later than 512 bit-times into the transmission of a packet. Default value
FrameTooLongs: This attribute provides a count of frames received on a particular interface
that exceed the maximum permitted frame size. The count is incremented when the MAC service
returns the frameTooLong status to the LLC. Default value is 0x00. (R) (mandatory) (4 bytes)
BufferOverflows on Receive: This attribute provides a count of the number of times that the
buffer overflows on receive. Default value is 0x00. (R) (mandatory) (4 bytes)
BufferOverflows on Transmit: This attribute provides a count of the number of times that the
buffer overflows on transmit. Default value is 0x00. (R) (mandatory) (4 bytes)
ITU-T Rec. G.983.2 (07/2005) 85

Single Collision Frame Counter: This attribute provides a count of successfully transmitted
frames on a particular interface for which transmission is inhibited by exactly one collision.
Default value is 0x00. (R) (mandatory) (4 bytes)
Multiple Collisions Frame Counter: This attribute provides a count of successfully transmitted
frames on a particular interface for which transmission is inhibited by more than one collision.
SQECounter: This attribute provides a count of times that the SQE TEST ERROR message is
generated by the PLS sublayer for a particular interface. Default value is 0x00. (R) (mandatory)
(4 bytes)
Deferred Transmission Counter: This attribute provides a count of frames for which the first
transmission attempt on a particular interface is delayed because the medium is busy. The count
represented by an instance of this object does not include frames involved in collisions. Default
InternalMACTransmit ErrorCounter: This attribute provides a count of frames for which
transmission on a particular interface fails due to an internal MAC sublayer transmit error.
CarrierSenseError Counter: This attribute indicates the number of times that the carrier sense
condition was lost or never asserted when attempting to transmit a frame on a particular
interface. Default value is 0x00. (R) (mandatory) (4 bytes)
AlignmentError Counter: This attribute provides a count of frames received on a particular
interface that are not an integral number of octets in length and do not pass the FCS check.
InternalMACReceive ErrorCounter: This attribute provides a count of frames for which
reception on a particular interface fails due to an internal MAC sublayer receive error. Default
Actions
Notifications
be sent at the end of the 15-min period since that is when the actual counters are reset to 0x00.
The event list for this entity is given in Table 13a.
86 ITU-T Rec. G.983.2 (07/2005)

Table 13a/G.983.2 − Alarm list for Ethernet performance monitoring history data
Threshold data
counter # (Note)
0 FCS Errors Exceeds threshold 1
1 Excessive Collision Counter Exceeds threshold 2
2 Late Collision Counter Exceeds threshold 3
3 FrameTooLongs Exceeds threshold 4
4 Buffer Overflows on Receive Exceeds threshold 5
5 Buffer Overflows on Transmit Exceeds threshold 6
6 Single Collision Frame Counter Exceeds threshold 7
7 Multiple Collisions Frame Counter Exceeds threshold 8
8 SQE Counter Exceeds threshold 9
9 Deferred Transmission Counter Exceeds threshold 10
10 Internal MAC Transmit Error Counter Exceeds threshold 11
11 Carrier Sense Error Counter Exceeds threshold 12
12 Alignment Error Counter Exceeds threshold 13
13 Internal MAC Receive Error Counter Exceeds threshold 14
14-223 Reserved
7.3.15 CES physical interface monitoring history data

This managed entity contains the last completed 15-minute interval collected statistic data for a
physical interface (e.g., DS1/E1/J1/J2) of the CES UNI.
Instances of this managed entity are created/deleted by the OLT after an instance of the Physical
Path Termination Point CES UNI managed entity is created/deleted.
The performance management of the physical interfaces used by the CES UNI shall be supported.
Possible interfaces include DS1/DS3/E1/E3/J1/J2. The performance management requirements of
particular interfaces are described in the corresponding ITU-T Recommendation or other standard
document (e.g., ITU-T Rec. G.784 [1]). Failure/notifications should include threshold alerts for
unacceptable performance (error) rates. Performance data should include transmission counts of
Errored Seconds (ES), Severely Errored Seconds (SES) and Unavailable Seconds (UAS).
Notice that, because of the various operators' requirements and cost advantages, each vendor's ONT
may support different levels of performance management of the physical interfaces. It is not stated
here that the errored seconds stated below have to be generated for all the possible combinations
such as near-end path, far-end path, near-end line, far-end line, etc. Each vendor may use
vendor-specific combinations for its implemented features.
Relationships
One instance of this managed entity shall exist for each instance of the Physical Path
Termination Point CES UNI.
ITU-T Rec. G.983.2 (07/2005) 87

Attributes
entity. This 2-byte number is the same as the id of the Physical Path Termination Point CES
"synchronize time" action, the value of this attribute set equal to the number of the last
completed interval. The actual counters of this managed entity start counting directly. (R)
Error Seconds: The number of Errored Seconds encountered by a physical interface in the last
completed 15-minute interval. If the actual counter saturates, it remains on its maximum value.
Severely Error Seconds: The number of Severely Errored Seconds encountered by a physical
interface in the last completed 15-minute interval. If the actual counter saturates, it remains on its
Bursty Error Seconds: The number of Bursty Errored Seconds encountered by a physical
interface in the last completed 15-minute interval. A BES is any second that is not a UAS that
contains between 2 and 319 error events but no LOS, AIS, or OOF condition. If the actual
counter saturates, it remains on its maximum value. Default value is 0x00. (R) (Optional)
(2 bytes)
Unavailable Seconds: The number of Unavailable Seconds encountered by a physical interface
in the last completed 15-minute interval. If the actual counter saturates, it remains on its
Controlled Slip Seconds: The number of Controlled Slip Seconds encountered by a physical
interface in the last completed 15-minute interval. If the actual counter saturates, it remains on its
Actions
NOTE – "Get" returns the statistical data stored in the attribute values; "Get current data" returns the real-
time value of the actual counters associated with those attributes.
88 ITU-T Rec. G.983.2 (07/2005)

Notifications
Both ONT and OLT should know the event list used by this entity. The list of TCAs for this
entity is given in Table 14.
Table 14/G.983.2 − Alarm list for CES physical interface monitoring history data
Threshold Data
counter # (Note)
0 ES Exceeds threshold 1
1 SES Exceeds threshold 2
2 BES Exceeds threshold 3
3 UAS Exceeds threshold 4
4 CSS Exceeds threshold 5
5-223 Reserved
7.3.16 TC adapter protocol monitoring history data

This managed entity contains the last completed 15-minute interval collected performance
monitoring as a result of performing Transmission Convergence level protocol monitoring. All the
attribute counters, e.g., the discarded cells due to HEC violations, are only updated at the end of
each period.
Instances of this managed entity are created/deleted by the OLT after an instance of the
corresponding TC AdapterB-PON managed entity is created/deleted.
Relationships
One instance of this managed entity can exist for each instance of TC AdapterB-PON or PON TC
Adapter.
Attributes
entity. This 2-byte number is the same as the id of the corresponding TC AdapterB-PON or PON
TC Adapter. (R, Set-by-create) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 89

Discarded Cells due to HEC violations: This read-only attribute provides a raw, thresholded
count of the number of ATM cells that were discarded (per interface) due to an HEC violation. If
the actual counter saturates, it remains on its maximum value. Default value is 0x00.
Errored Cells due to HEC violations: This read-only attribute provides a raw, thresholded
count of the number of ATM cells that were errored (per interface) due to an HEC violation. If
the actual counter saturates, it remains on its maximum value. Default value is 0x00.
Actions
Notifications
Both ONT and OLT should know the event list, given in Table 15, used by this entity.
Table 15/G.983.2 − Alarm list for TC adapter protocol monitoring history data
Threshold data
counter # (Note)
0 Discarded Cells due to HEC violations Exceeds threshold 1
1 Errored cells due to HEC violations Exceeds threshold 2
2-223 Reserved
NOTE – This numbering is used with the associated Threshold Data B-PON managed entity. Threshold
Data counter 1 indicates the 1st thresholded counter, etc.
90 ITU-T Rec. G.983.2 (07/2005)

7.3.17 Threshold DataB-PON
An instance of this managed entity contains threshold values for the performance monitoring
parameters maintained in one or more instances of other managed entities.
Instances of this managed entity are created and deleted by request of the OLT.
Relationships
entity. This managed entity may be related to multiple instances of History Data type managed
entities, which have a Threshold DataB-PON id attribute that points to an instance of this managed
entity.
Related Managed Entities:
• AAL 1 Protocol Monitoring History DataB-PON;
• AAL 5 Protocol Monitoring History DataB-PON;
• CES Physical Interface Monitoring History Data;
• Ethernet Performance Monitoring History Data;
• TC Adapter Protocol Monitoring History Data;
• UPC Disagreement Monitoring History DataB-PON;
• AAL 2 CPS Protocol Monitoring History DataB-PON;
• AAL 2 SSCS Protocol Monitoring History DataB-PON;
• MAC Bridge PM History Data;
• MAC Bridge Port PM History Data;
• Voice PM History Data;
• VP PM History Data;
• IP Router PM History Data 1;
• IP Router PM History Data 2;
• ICMP PM History Data 1;
• ICMP PM History Data 2;
• VC PM History Data;
• Ethernet Performance Monitoring History Data 2;
• 802.11 Counters;
• ADSL ATU-C Channel Performance Monitoring History Data;
• ADSL ATU-C Performance Monitoring History Data;
• ADSL ATU-R Channel Performance Monitoring History Data;
• ADSL ATU-R Performance Monitoring History Data;
• TC Adaptor Performance Monitoring History Data ADSL;
• VDSL VTU-O Channel Performance Monitoring History Data;
• VDSL VTU-O Physical Interface Monitoring History Data;
• VDSL VTU-R Channel Performance Monitoring History Data;
• VDSL VTU-R Physical Interface Monitoring History Data.
ITU-T Rec. G.983.2 (07/2005) 91

Attributes
Threshold Value 1: This attribute provides the associated threshold value for the 1st thresholded
counter in the History Data type managed entity. (R, W, Set-by-create) (mandatory) (4 bytes)
Threshold Value 2: This attribute provides the associated threshold value for the 2nd
thresholded counter in the History Data type managed entity. (R, W, Set-by-create) (mandatory)
(4 bytes)
Threshold Value 3: This attribute provides the associated threshold value for the 3rd
(4 bytes)
Threshold Value 4: This attribute provides the associated threshold value for the 4th
(4 bytes)
(4 bytes)
(4 bytes)
(4 bytes)
thresholded counter in the History Data type managed entity. The default value is 0. (R, W)
92 ITU-T Rec. G.983.2 (07/2005)

Actions
Notifications
None.
7.3.18 AAL 2 Profile B-PON
It is used with the Interworking VCC Termination Point managed entity. In an ATM environment,
AAL Type 2 configuration parameters are associated with an Interworking VCC Termination Point
managed entity through a pointer relationship. Each instance of the managed entity defines a
combination of parameter values that may be associated with multiple Interworking VCC
Termination Point instances. This managed entity is instantiated/deleted on request of the OLT.
These attributes must be provisioned for both PVC and SVC VCCs.
Relationships
used within an ONT associated with a VCC that is either an SVC or a PVC. One instance of this
managed entity may be associated with one or more instances of an Interworking VCC
Termination Point.
Attributes
SSCSParameterProfile1Ptr: This attribute points to the SSCSParameterProfile1 instance
containing the default values for the Service Specific Convergence Sublayer parameters
associated with channels carrying control and management plane traffic (e.g., CCS, ELCP, ISDN
D-channels, and LES-EOC). (R, Set-by-create) (mandatory) (2 bytes)
SSCSParameterProfile2Ptr: This attribute points to the SSCSParameterProfile2 instance
containing the default values for the Service Specific Convergence Sublayer parameters
associated with channels carrying media streams (e.g., POTS or ISDN B-channels). (R, Set-by-
create) (mandatory) (2 bytes)
Actions
Notifications
None.
7.3.19 AAL 2 PVC ProfileB-PON
It is used with the Interworking VCC Termination Point managed entity. In an ATM environment,
AAL Type 2 configuration parameters are associated with an Interworking VCC Termination Point
managed entity through a pointer relationship. Each instance of the managed entity defines a
ITU-T Rec. G.983.2 (07/2005) 93

combination of parameter values that may be associated with multiple Interworking VCC
Termination Point instances. This managed entity is instantiated/deleted on request of the OLT.
These attributes must be provisioned for PVCs (including soft-PVCs).
Relationships
used within an ONT associated with a VCC that is a PVC. One instance of this managed entity
may be associated with one or more instances of an Interworking VCC Termination Point.
Attributes
entity. The assigned number is the same as the id of the AAL 2 ProfileB-PON with which this
AAL 2 PVC ProfileB-PON is associated. (R, Set-by-create) (mandatory) (2 bytes)
AppId: This attribute specifies the protocol combinations used between the Interworking
Functions found in the Voice Gateway and the ONT. Valid values include those provided in
Section 4.1.1 of ATM Forum Well-Known Addresses and Assigned Codes. (R, Set-by-create)
MaximumNumChan: This attribute provides the maximum number of AAL 2 channels that can
be carried by the VC Trail associated with the Interworking VCCTP. It ranges from 0x01 to
0xFF (1 to 255). (R, Set-by-create) (mandatory) (1 byte)
MinimumChanIdVal: This attribute provides the minimum value for the Channel Id allowed
for any AAL 2 channel within the connection. (R, Set-by-create) (mandatory) (1 byte).
NOTE 1 – Values from 0 to 15 are reserved.
MaximumChanIdVal: This attribute provides the maximum value for the Channel Id allowed
for the AAL 2 channel within the connection (R, Set-by-create) (mandatory) (1 byte).
NOTE 2 – Values from 224 to 255 are reserved.
MaxCPS_SDULen: This attribute provides the maximum allowed length of the Common Part
Sublayer Service Data Unit (or CPS SDU) that will be allowed over the connection in either the
upstream or downstream direction of transmission. The value is 0x2d or 0x40 (45 or 64 octets).
(R, Set-by-create) (mandatory) (1 byte)
TimerCULen: This attribute provides the value (in 10ths of a millisecond) for the "combined
use" timer Timer_CU on the ITU-T Rec. I.363.2. (R, Set-by-create) (mandatory) (2 bytes)
Actions
Notifications
None.
7.3.20 AAL 2 CPS Protocol Monitoring History DataB-PON
collected as a result of AAL 2 protocol conversion monitoring. All the attribute counters, e.g., the
CPSInPkts, are only updated at the end of each period. Instances of this managed entity are created
automatically by the OLT whenever an instance of the Interworking VCC Termination Point
managed entity is created that represents the AAL 2 functions. Instances of this managed entity are
deleted by the OLT.
94 ITU-T Rec. G.983.2 (07/2005)

Relationships
Attributes
CPSInPkts: This attribute records the number of CPS packets received by the port group
associated with the Interworking VCC Termination Point. (R) (mandatory) (4 bytes)
CPSOutPkts: This attribute records the number of CPS packets transmitted by the port group
associated with the Interworking VCC Termination Point. (R) (mandatory) (4 bytes)
ParityErrors: This attribute records the number of CPS PDUs discarded because of incorrect
parity value in the STF field. (See errnum 0 in Table 6/I.363.2 [14].) If the actual counter
saturates, it remains on its maximum value. (R) (mandatory) (4 bytes)
SeqNumErrors: This attribute records the number of CPS PDUs received with incorrect
sequence number in the STF. (See errnum 1 in Table 6/I.363.2 [14].) If the actual counter
CPS_OSFMismatchErrors: This attribute records the number of CPS PDUs received for which
the number of octets expected for a CPS Packet that overlaps into the next CPS PDU does not
match the information contained in the STF field. (See errnum 2 in Table 6/I.363.2 [14].) If the
actual counter saturates, it remains on its maximum value. (R) (mandatory) (4 bytes)
CPS_OSFErrors: This attribute records the number of CPS PDUs discarded because of an
incorrect Offset Field (OSF) value in the STF field. (See errnum 3 in Table 6/I.363.2 [14].) If the
CPS_HECErrors: This attribute records the number of CPS packets having a header value
indicating transmission errors in the header. (See errnum 4 in the Table 6/I.363.2 [14].) If the
OversizedSDUErrors: This attribute records the number of times the received CPS packet
payload exceeds the maximum length indicated in MaxCPS_SDULen attribute. (See errnum 5 in
Table 6/I.363.2 [14].) If the actual counter saturates, it remains on its maximum value.
ITU-T Rec. G.983.2 (07/2005) 95

ReassemblyErrors: This attribute records the number of times that partial CPS packets are
discarded because errors were detected before reassembly could be completed. (See errnum 6 in
Table 6/I.363.2 [14].) If the actual counter saturates, it remains on its maximum value.
HECOverlapErrors: This attribute records the number of times that a CPS packet is received
with a HEC that overlaps a CPS PDS boundary. (See errnum 7 in Table 6/I.363.2 [14].) If the
UUIErrors: This attribute records the number of times that a UUI is received with a value that is
reserved for future use. (See errnum 8 in Table 6/I.363.2 [14].) If the actual counter saturates, it
remains on its maximum value. (R) (mandatory) (4 bytes)
CIDErrors: This attribute records the number of times that a CPS PDU is received with an
incorrect CID value. (See errnum 9 in Table 6/I.363.2 [14].) If the actual counter saturates, it
remains on its maximum value. (R) (mandatory) (4 bytes)
Actions
Notifications
be sent at the end of the 15-min period since then the actual counters are reset to 0x00. The event
list for this entity is given in Table 15a.
Table 15a/G.983.2 − Alarm list for AAL 2 CPS protocol monitoring history dataB-PON
Threshold data
counter # (Note)
0 Reserved
1 Reserved
2 ParityErrors Exceeds threshold 1
3 SeqNumErrors Exceeds threshold 2
4 CPS_OSFMismatchErrors Exceeds threshold 3
5 CPS_OSFErrors Exceeds threshold 4
6 CPS_HECErrors Exceeds threshold 5
96 ITU-T Rec. G.983.2 (07/2005)

Table 15a/G.983.2 − Alarm list for AAL 2 CPS protocol monitoring history dataB-PON
Threshold data
counter # (Note)
7 OversizedSDUErrors Exceeds threshold 6
8 ReassemblyErrors Exceeds threshold 7
9 HECOverlapErrors Exceeds threshold 8
10 UUIErrors Exceeds threshold 9
11 CIDErrors Exceeds threshold 10
12-223 Reserved
NOTE – This numbering is used with the associated Threshold DataB-PON managed entity. Threshold Data
7.3.21 AAL 2 SSCS Protocol Monitoring History DataB-PON

collected as a result of AAL 2 protocol conversion monitoring. All of the attribute counters are
updated only at the end of each period. Instances of this managed entity are created automatically
by the OLT whenever an instance of the Interworking VCC Termination Point managed entity is
created that represents AAL 2 functions. Instances of this managed entity are deleted by the OLT.
Relationships
Attributes
OversizedSSSARSDU Errors: This attribute records the number of times that an SSSAR SDU
exceeds the maximum length allowed for an SSSAR-SDU of the Segmentation and Reassembly
Service Specific Convergence sublayer. See "MaxSSSARSDULen" attribute of AAL 2 SSCS
Parameter Profile1 managed entity. (See errnum 10 in Table 3/I.366.1 [15].) If the actual counter
saturates, it remains on its maximum value. (R) (optional – used when LES EOC is carried all
the way to the ONT) (4 bytes)
ITU-T Rec. G.983.2 (07/2005) 97

RASTimerExpiry Errors: This attribute records the number of times that the reassembly timer
has expired. See "RASTimer" attribute of AAL 2 SSCS Parameter Profile1 managed entity. (See
errnum 11 in Table 3/I.366.1 [15].) If the actual counter saturates, it remains on its maximum
value. (R) (optional – used when LES EOC is carried all the way to the ONT) (4 bytes)
UndersizedSSTEDPDUErrors: This attribute records the number of times that an SSTED-PDU
of length 8 or less has been received. (See errnum 20 in Table 5/I.366.1 [15].) If the actual
counter saturates, it remains on its maximum value. (R) (optional – used when LES EOC is
carried all the way to the ONT) (4 bytes)
PDULengthMismatchErrors: This attribute records the number of times that the value of the
Length field in the SSTED-PDU does not match the length of the received SSTED-PDU. (See
errnum 21 in Table 5/I.366.1 [15].) If the actual counter saturates, it remains on its maximum
value. (R) (optional – used when LES EOC is carried all the way to the ONT) (4 bytes)
CRCMismatchErrors: This attribute records the number of times that the value of the CRC
field is not equal to the CRC calculated over the received information. If the actual counter
saturates, it remains on its maximum value. (R) (optional – used when LES EOC is carried all
the way to the ONT) (4 bytes)
Actions
Notifications
be sent at the end of the 15-min period since then the actual counters are reset to 0x00. The event
list for this entity is given in Table 15b.
Table 15b/G.983.2 − Alarm list for AAL 2 SSCS protocol monitoring history dataB-PON
Threshold data
counter # (Note)
0 OversizedSSSARSDUErrors Exceeds threshold 1
1 RASTimerExpiryErrors Exceeds threshold 2
2 UndersizedSSTEDPDUErrors Exceeds threshold 3
3 PDULengthMismatchErrors Exceeds threshold 4
4 CRCMismatchErrors Exceeds threshold 5
98 ITU-T Rec. G.983.2 (07/2005)

Table 15b/G.983.2 − Alarm list for AAL 2 SSCS protocol monitoring history dataB-PON
Threshold data
counter # (Note)
5-223 Reserved
7.3.22 AAL 2 SSCS Parameter Profile1

This managed entity groups default values for Service Specific Convergence Sublayer parameters
for channels carried in an AAL 2 VCC that provide control and management plane traffic. These
parameters are defined in ITU-T Rec. I.366.1 [15]. Instances of this managed entity are created and
deleted by request of the OLT.
Relationships
Zero or more instances of this managed entity shall exist for each instance of the AAL 2
ProfileB-PON used within an ONT. One instance of this managed entity may be associated with
one or more instances of an Interworking VCC Termination Point.
Attributes
SegmentLength: This attribute provides the segment length for the Segmentation and
Reassembly Service Specific Convergence sublayer. It ranges from 0 to the maximum value
provided by MaxCPS_SDULen attribute. (R, Set-by-create) (mandatory) (1 byte)
RASTimer: This attribute provides the reassembly time (in seconds) of the Segmentation and
Reassembly Service Specific Convergence sublayer for ITU-T Rec. I.366.1 [15].
MaxSSSARSDULen: This attribute provides the maximum length allowed for an SSSAR-SDU
of the Segmentation and Reassembly Service Specific Convergence sublayer. It ranges from
0x01 to 0x010020 (1 to 65 568). (R, Set-by-create) (mandatory) (3 bytes)
SSTEDInd: This Boolean attribute indicates whether or not the transmission error detection
mechanisms have been selected, with value TRUE indicating selection. (R, Set-by-create)
SSADTInd: This Boolean attribute indicates whether or not the assured data transfer mechanism
has been selected, with value TRUE indicating selection. (R, Set-by-create) (mandatory) (1 byte)
Actions
Notifications
None.
ITU-T Rec. G.983.2 (07/2005) 99

7.3.23 AAL 2 SSCS Parameter Profile2
This managed entity groups default values for Service Specific Convergence Sublayer parameters
for channels carried in an AAL 2 VCC that provide media streams. These parameters are defined in
ITU-T Rec. I.366.2 [17]. Instances of this managed entity are created and deleted by request of the
OLT.
Relationships
Zero or more instances of this managed entity shall exist for each instance of the AAL 2
ProfileB-PON used within an ONT. One instance of this managed entity may be associated with
one or more instances of an Interworking VCC Termination Point.
Attributes
ServiceCatType: This attribute indicates the type of service category provided by AAL 2. Valid
values include but are not limited to "Audio" (value is 0x01) and "Multirate" (value is 0x02).
EncSrcType: This attribute indicates the source for the encoding profile format. Valid values
include but are not limited to "ITU-T" predefined (value 0x01) and "ATM Forum" predefined
(value 0x02). (R, Set-by-create) (mandatory) (1 byte)
EncProfileIndex: This attribute indicates the specific predefined encoding profile used.
Table 15c provides a list of possible values. (R, Set-by-create) (mandatory) (1 byte)
AudioServInd: This Boolean attribute indicates whether or not audio service is transported,
where the value TRUE implies the presence of this service. (R, Set-by-create) (mandatory)
(1 byte)
PCMEncType: This attribute indicates the type of PCM coding. Valid values include but are not
limited to "mu-law PCM coding" (value 0x01) and "alpha-law PCM coding" (value 0x02).
CMDataInd: This Boolean attribute indicates whether or not Circuit Mode Data is carried on
this connection, where the value TRUE implies its presence. (R, Set-by-create) (mandatory)
(1 byte)
CMMultiplierNum: This attribute provides the N value in N × 64 kbit/s circuit mode data.
FMDataInd: This Boolean attribute indicates whether or not Frame Mode Data is carried on this
connection, where the value TRUE implies its presence. (R, Set-by-create) (mandatory) (1 byte)
FMMaxFrameLen: This attribute indicates the maximum length of a frame mode data unit. It
ranges from 0x01 to 0xFFFF (1 to 65535). (R, Set-by-create) (mandatory) (2 bytes)
CASInd: This Boolean attribute indicates whether or not Channel Associated Signalling is
enabled on the connection, where the value TRUE implies it is enabled. (R, Set-by-create)
DTMFInd: This Boolean attribute indicates whether or not Dual Tone Multi-Frequency dialed
digits are transported on the connection, where the value TRUE implies their presence. (R, Set-
by-create) (mandatory) (1 byte)
MFR1Ind: This Boolean attribute indicates whether or not Multi-Frequency R1 dialed digits are
transported on the connection, where the value TRUE implies their presence. (R, Set-by-create)
100 ITU-T Rec. G.983.2 (07/2005)

MFR2Ind: This Boolean attribute indicates whether or not Multi-Frequency R2 dialed digits are
transported on the connection, where the value TRUE implies their presence. (R, Set-by-create)
RateControlInd: This Boolean attribute indicates whether or not rate control is transported on
the connection, where the value TRUE implies its presence. (R, Set-by-create) (mandatory)
(1 byte)
SynchChangeInd: This Boolean attribute indicates whether or not synchronization of change in
SSCS operation is transported on the connection, where the value TRUE implies its presence.
FaxDemodulationInd: This Boolean attribute indicates whether fax demodulation is enabled or
disabled on the connection, where the value TRUE implies it is enabled. (R, Set-by-create)
Actions
Notifications
None.
Table 15c/G.983.2 − Coding of the EncProfileIndex attribute

EncSrcType EncProfileIndex
1: ITU-T predefined 0: Not used.
1: PCM-64 ITU-T Rec. I.366.2
2: PCM-64 and silence ITU-T Rec. I.366.2
3: ADPCM and silence ITU-T Rec. I.366.2
4: G.728 with higher efficiency ITU-T Rec. I.366.2
5: G.728 with lower delay ITU-T Rec. I.366.2
6: G.729 with higher efficiency and G.726 for ITU-T Rec. I.366.2
voiceband data
7: G.729 with lower delay ITU-T Rec. I.366.2
8: G.729 with lower delay and G.726-32 for ITU-T Rec. I.366.2
voiceband data at lower rates.
9: G.729 with lower delay and G.726-40 for ITU-T Rec. I.366.2
voiceband data at higher rates.
10: G.729 with full variable bit rates ITU-T Rec. I.366.2
11: AMR ITU-T Rec. I.366.2
12: G.723 ITU-T Rec. I.366.2
13: PCM 64 kbits/s and ADPCM 32 kbits/s ITU-T Rec. I.366.2
14-255: Reserved for future ITU-T assignment
ITU-T Rec. G.983.2 (07/2005) 101

Table 15c/G.983.2 − Coding of the EncProfileIndex attribute
EncSrcType EncProfileIndex
2: ATM Forum predefined 0: Not used.
1: LPC-10 (High efficiency) af-vtoa-0113.000
2: LPC-10 (Low delay) af-vtoa-0113.000
3: CVSD-32 af-vtoa-0113.000
4: CVSD-16 af-vtoa-0113.000
5: CVSD-12 af-vtoa-0113.000
6: G.723.1 af-vtoa-0113.000
7: PCM-64, ADPCM-32, 44 octet packets, af-vmoa-0145.000
and silence.
8: PCM-64, 44 octet packets, and silence. af-vmoa-0145.000
9: PCM-64, 44 octet packets, without silence. af-vmoa-0145.000
10: PCM-64 and ADPCM-32, 44 octet packets, af-vmoa-0145.000
without silence.
without silence.
with silence.
13-255: Reserved for future ATM Forum af-vmoa-0145.000
assignment.
7.3.24 Voice service profile AAL

This managed entity is used to organize data that describes the Voice Service functions of the ONT
if supported by AAL 2 or AAL 1. Instances of this managed entity are created and deleted by
request of the OLT.
Relationships
Interworking VCC Termination Point carrying voice services.
Attributes
AnnouncementType: This attribute provides the announcement to the customer going off-hook
when no call has been attempted. Valid values include but are not limited to "silence" (0x01),
"reorderTone" (0x02), "fastBusy" (0x03), "voiceAnnouncement" (0x04), and "N/A" (0xFF).
JitterTarget: This attribute provides the target value of the jitter buffer. The system will try to
maintain the jitter buffer at the target value. Units are in milliseconds. (R, W, Set-by-create)
(mandatory for AAL 2) (2 bytes)
JitterBufferMax: This attribute provides the maximum depth of the jitter buffer associated with
this service. Units are in milliseconds. (R, W, Set-by-create) (mandatory for AAL 2) (2 bytes)
102 ITU-T Rec. G.983.2 (07/2005)

EchoCancelInd: This Boolean attribute indicates whether echo cancellation is on or off, where
the value TRUE implies that it is on. (R, Set-by-create) (mandatory) (1 byte)
PSTNProtocolVariant: This attribute controls which variant of POTS signalling shall be used
on the associated UNIs. The value used is equal to the 'country code'. (R, Set-by-Create)
(optional) (2 bytes)
Actions
Notifications
None.
7.3.25 LES service profile
This managed entity is used to organize data that describes voice grade Loop Emulation Service
functions of the ONT associated with AAL 2 interworking. Instances of this managed entity shall be
created and deleted by the OLT.
Relationships
Interworking VCC Termination Point.
Attributes
entity. The assigned number is the same as the id of the Voice Service Profile AAL with which
this LES Service Profile is associated. (R, Set-by-create) (mandatory) (2 bytes)
ELCPInd: This Boolean attribute indicates whether or not Emulated Loop Control Protocol is in
use. The value TRUE means enabled. (R, Set-by-create) (mandatory) (1 byte)
POTSSignalling: This attribute selects which signalling format should be used for POTS
service. Valid values include but are not limited to CCS (value 0x01), CAS (value 0x02), and
other (0xFF). (R, Set-by-create) (mandatory) (1 byte)
BRISignalling: This attribute selects which signalling format should be used for Basic Rate
ISDN. Valid values include but are not limited to DSS1 (0x01), and other (0xFF). The default
value is 0x01. (R, W) (mandatory) (1 byte)
MaxNumCIDs: This attribute specifies the maximum number of channels within the VCC that
can be active. (R, Set-by-create) (mandatory) (1 byte)
MaxPacketLength: This attribute specifies the maximum packet length (in bytes). (R, Set-by-
create) (mandatory) (1 byte)
Actions
ITU-T Rec. G.983.2 (07/2005) 103

Notifications
None.
7.3.26 Physical path termination point POTS UNI
This managed entity represents the point at the POTS UNI in the ONT where physical paths
terminate and physical path level functions (e.g., analog telephony, facsimile function) are
performed. An instance of this managed entity shall be automatically created/deleted by the ONT
upon the creation/deletion of a Subscriber Line Card with POTS type.
Relationships
One or more instances of this managed entity shall be contained in an instance of the ONTB-PON
or a Subscriber Line Card managed entity classified as POTS type.
Attributes
byte is the slot id (defined in 7.1.3). If the UNI is integrated, this value is 0x00. The second byte
is the port id with value range from 0x01 to 0xFF (1 to 255), 0x01 is used for the leftmost/lowest
port on a Subscriber Line Card, 0x02 is used for the next right/upper port, and so forth. (R)
Interworking VCC Pointer: This attribute provides a pointer to the instance of the Interworking
VCC managed entity to which this instance is connected. The value 0x0000 is interpreted as a
Null pointer. (R, W) (optional) (2 bytes)
Impedance: This attribute allows the impedance for the Physical Path Termination Point POTS
UNI to be configured by the user. Valid values include 600 Ohm Impedance (value 0x00) and
900 Ohm Impedance (value 0x01). In addition, the following parameter sets from ETSI TS 101
270-1 (1999-10), Annex C, are valid:
– value 0x02: C1=150 nF, R1=750 Ohm, R2=270 Ohm;
– value 0x03: C1=115 nF, R1=820 Ohm, R2=220 Ohm;
– value 0x04: C1=230 nF, R1=1050 Ohm, R2=320 Ohm,
where C1, R1, and R2 are related as shown below. Upon autonomous instantiation, the value
0x00 is used. (R,W) (optional) (1 byte)
104 ITU-T Rec. G.983.2 (07/2005)

C1
R2
R1
Transmission Path: This attribute allows for setting the Physical Path Termination Point POTS
UNI to be put in either full-time or part-time on-hook transmission mode. Valid values include
full-time on-hook transmission (value 0x00) and part-time on-hook transmission (value 0x01)
Upon autonomous instantiation, the value 0x00 is used. (R,W) (optional) (1 byte)
Rx Gain: This attribute provides a gain value for the received signal. Valid values are –12 dB to
+6 dB in 0.1 dB increments. (value –120 to +60, 0 = 0 dB gain, –120 = –12.0 dB, etc.) Upon
autonomous instantiation, the value 0x00 is used. (R,W) (optional) (1 byte)
Tx Gain: This attribute provides a gain value for the transmit signal. Valid values are –6 dB to
+12 dB in 0.1 dB increments. (value –60 to +120, 0 = 0 dB gain, 60 = +6.0 dB, etc.). Upon
autonomous instantiation, the value 0x00 is used. (R,W) (optional) (1 byte)
Actions
Test: Request that the ONT perform one or more MLT tests or a dial tone make/break test.
See "Test" and "Test result" message layouts in II.2.27 and II.2.45 respectively.
Notifications
alarm list for this entity is given in Table 15d. See also Appendix III.
Table 15d/G.983.2 − Alarm list for physical path termination point POTS UNI
0-223 Reserved
7.3.27 Voice CTP

This managed entity is used to represent the point in the ONT where the voice channel is
terminated/originated. Instances of this managed entity are created and deleted by request of
the OLT.
Relationships
Zero or more instances of this managed entity shall be contained in an instance of the ONTB-PON
or Subscriber Line Card managed entity classified as a POTS type.
Attributes
InterworkingVCCTPPtr: This attribute points to the instance of the Interworking
VCC Termination Point carrying this voice channel. (R, Set-by-create) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 105

InterworkingPPTPPtr: This attribute provides a pointer to the associated instance of the
Termination Point managed entity for the case of POTS or ISDN services. When this Voice CTP
is associated with a Subscriber Line Card managed entity classified as a POTS type, this attribute
points to the instance of the Physical Path Termination Point POTS UNI. When this Voice CTP
is associated with a Subscriber Line Card managed entity classified as ISDN type, this attribute
points to the instance of the Physical Path Termination Point ISDN UNI. (R, Set-by-create)
ChannelId: This attribute identifies the logical Channel Id for this service if AAL 2 is
employed. This attribute is null (not used) if another type of adaptation is employed. (R,
Set-by-create) (mandatory) (1 byte)
SignallingCode: This attribute specifies whether "loop start" (0x01), "ground start" (0x02),
"loop reverse battery" (0x03), "coin first" (0x04), "dial tone first" (0x05), or "multi-party" (0x06)
signalling is employed. (R, Set-by-create) (mandatory) (1 byte)
RobbedBitSignalling: This attribute describes the robbed bit signalling in use on the telephony
port. Valid values include "a" (value 0x01), "ab" (value 0x02), "abcd" (value 0x03),
"transparent" (value 0x04), and "other" (value 0xFF). (R, Set-by-create) (mandatory) (1 byte)
SilenceSuppression Ind: This Boolean attribute indicates whether silence suppression is on or
off. The value TRUE means on. (R, Set-by-create) (mandatory) (1 byte)
VoiceCompression Type: This attribute identifies the voice compression applied to the voice
channel. Valid values include but are not limited to the following: PCM-64 (value 0x01),
ADPCM-32 (value 0x02), LD-CELP16 (value 0x03), CS-ACELP8 (value 0x04), and unknown
(value 0xFF). (R, Set-by-create) (mandatory) (1 byte)
Actions
Notifications
None.
7.3.28 Voice PM history data
collected as a result of monitoring a voice port on an ONT. The statistic data value is only updated
at the end of each period. Instances of this managed entity are created/deleted by the OLT after an
instance of a Physical Path Termination Point POTS UNI or Physical Path Termination Point ISDN
UNI managed entity is created/deleted.
Relationships
One instance of this managed entity can exist for each instance of a Physical Path Termination
Point POTS UNI or Physical Path Termination Point ISDN UNI.
Attributes
entity. This 2-byte number is the same as the id of a Physical Path Termination Point POTS UNI
or Physical Path Termination Point ISDN UNI. (R, Set-by-create) (mandatory) (2 bytes)
106 ITU-T Rec. G.983.2 (07/2005)

VoicePortBufferOverflows: This attribute provides the total number of payload octets dropped
due to buffer overflow at this port (NOTE – this number does not include octets that are dropped
because they arrived late and had already been substituted by a filler octet). If the actual counter
VoicePortBufferUnderflows: This attribute provides the total number of filler octets injected
into the active media stream on this port due to playout buffer underflow. If the actual counter
ActiveSeconds: This attribute provides the total length of time, in seconds, that the AAL 2
channel associated with this port has been active. If the counter saturates, it remains on its
maximum value. (R) (mandatory) (4 bytes)
DchannelBufferOverflows: This attribute provides the total number of payload octets for the
D channel that are dropped due to buffer overflow at this port (NOTE – this number does not
include octets that are dropped because they arrived late and had already been substituted by a
filler octet). If the actual counter saturates, it remains on its maximum value. (R) (mandatory, if
this voice port carries ISDN traffic) (4 bytes)
B1ChannelBufferOverflows: This attribute provides the total number of payload octets for the
B1 channel that are dropped due to buffer overflow at this port (NOTE – this number does not
B2ChannelBufferOverflows: This attribute provides the total number of payload octets for the
B2 channel that are dropped due to buffer overflow at this port (NOTE – this number does not
DchannelBufferUnderflows: This attribute provides the total number of filler octets injected
into the D channel of the active media stream on this port due to playout buffer underflow. If the
actual counter saturates, it remains on its maximum value. (R) (mandatory, if this voice port
carries ISDN traffic) (4 bytes)
B1ChannelBufferUnderflows: This attribute provides the total number of filler octets injected
into the B1 channel of the active media stream on this port due to playout buffer underflow. If
the actual counter saturates, it remains on its maximum value. (R) (mandatory, if this voice port
B2ChannelBufferUnderflows: This attribute provides the total number of filler octets injected
into the B2 channel of the active media stream on this port due to playout buffer underflow. If
the actual counter saturates, it remains on its maximum value. (R) (mandatory, if this voice port
ITU-T Rec. G.983.2 (07/2005) 107

DchannelActiveSeconds: This attribute provides the total length of time, in seconds, that the
D channel associated with this port has been active. If the counter saturates, it remains on its
maximum value. (R) (mandatory, if this voice port carries ISDN traffic) (4 bytes)
B1ChannelActiveSeconds: This attribute provides the total length of time, in seconds, that the
B1 channel associated with this port has been active. If the counter saturates, it remains on its
B2ChannelActiveSeconds: This attribute provides the total length of time, in seconds, that the
B2 channel associated with this port has been active. If the counter saturates, it remains on its
Actions
Notifications
The event list for this entity is given in Table 15e.
Table 15e/G.983.2 − Alarm list for voice PM history data

Threshold data
counter # (Note)
0 Reserved
1 Reserved
2 VoicePortBufferOverflows Exceeds threshold 1
3 VoicePortBufferUnderflows Exceeds threshold 2
4 B1ChannelBufferOverflows Exceeds threshold 3
5 B2ChannelBufferOverflows Exceeds threshold 4
6 DchannelBufferUnderflows Exceeds threshold 5
7 B1ChannelBufferUnderflows Exceeds threshold 6
8 B2ChannelBufferUnderflows Exceeds threshold 7
9-223 Reserved
108 ITU-T Rec. G.983.2 (07/2005)

7.3.29 MAC Bridge service profile
This managed entity is used to organize data that affects all ports on a MAC Bridge at a bridged
LAN Ethernet UNI interface on the ONT. Instances of this managed entity are created and deleted
by request of the OLT.
Relationships
Zero or more instances of this managed entity shall be referred to by the Physical Path
Termination Point Ethernet UNI managed entity.
Attributes
entity. The first byte is the slot id (defined in 7.1.3). If the UNI is integrated, this value is 0x00.
The second byte is the bridge group id. (R) (mandatory) (2 bytes)
SpanningTreeInd: This Boolean attribute indicates whether or not a spanning tree algorithm is
enabled. The value TRUE means enabled. (R, W, Set-by-create) (mandatory) (1 byte)
LearningInd: This Boolean attribute indicates whether or not the learning functions of the
bridge are enabled. The value TRUE means enabled. (R, W, Set-by-create) (mandatory) (1 byte)
ATMPortBridgingInd: This Boolean attribute indicates whether or not bridging between ATM
ports on this bridge service is enabled. The value TRUE means enabled. (R, W, Set-by-create)
Priority: This attribute indicates the bridge priority set on the LAN card. The range is 0x00 to
0xFFFF (0 to 65535). The value of this attribute is copied to the BridgePriority attribute of the
MAC Bridge Configuration Data managed entity. (R, W, Set-by-create) (mandatory) (2 bytes)
MaxAge: This attribute indicates the maximum age (in 256ths of a second) for an entry in the
spanning tree listing. It indicates the maximum age in 256ths of a second for received protocol
information before it is discarded. The range is 0x0600 to 0x2800 (6 s to 40 s) in accordance
with IEEE 802.1D [13]. (R, W, Set-by-create) (mandatory) (2 bytes)
HelloTime: This attribute provides the time interval (in 256ths of a second) between hello
packets. It is the time interval, in 256ths of a second, that a bridge advertises its presence while
as a root or attempting to become a root. The range is 0x0100 to 0x0a00 (1 s to 10 s) in
accordance with IEEE 802.1D [13]. (R, W, Set-by-create) (mandatory) (2 bytes)
ForwardDelay: This attribute gives the time (in 256ths of a second) that the bridge on the
Ethernet card in the ONT retains a packet before forwarding it. (It indicates the value in 256ths
of a second that the bridge uses for Forward Delay when the bridge acts as the root.) The range is
0x0400 to 0x1e00 (4 s to 30 s) in accordance with IEEE 802.1D [13]. (R, W, Set-by-create)
Actions
Notifications
None.
ITU-T Rec. G.983.2 (07/2005) 109

7.3.30 MAC Bridge configuration data
This managed entity is used to organize and record data that is associated with bridged LAN
configurations. Some of the data is volatile. Instances of this managed entity shall be automatically
created/deleted by the ONT upon the creation/deletion of a MACBridgeServiceProfile.
Relationships
This managed entity is associated with one instance of a MACBridgeServiceProfile.
Attributes
entity. The assigned number is the same as the id of the MACBridgeServiceProfile with which
this MACBridgeConfigurationData is associated. (R) (mandatory) (2 bytes)
BridgeMACAddress: This attribute indicates the MAC address used by the bridge. Upon
autonomous instantiation, this attribute consists of all 0x00. (R) (mandatory) (6 bytes)
BridgePriority: This attribute denotes the priority of the bridge and is positive integer-valued.
Upon autonomous instantiation, the value 0x8000 is used. The value of this attribute follows the
value of the associated MAC Bridge Service Profile: Priority attribute, if present. (R)
DesignatedRoot: This attribute provides the bridge identifier for the root of the spanning tree.
This attribute consists of Bridge Priority (2 bytes) and MAC address (6 bytes). (R) (mandatory)
(8 bytes)
RootPathCost: This attribute provides the cost of the best path to the root as seen from the
bridge. Upon autonomous instantiation, the value 0x00 is used. (R) (mandatory) (4 bytes)
BridgePortCount: This attribute provides the number of existing ports controlled by this bridge.
RootPortNum: This attribute provides the port number that has the lowest cost from the bridge
to the root bridge. The value 0x00 means that the bridge itself is the root. Upon autonomous
instantiation, the value 0x00 is used. (R) (mandatory) (2 bytes)
HelloTime: This attribute provides the time interval (in 256ths of a second) between hello
packets. It is the "HelloTime" received from the designated root. The range is 0x0100 to 0x0a00
(1 s to 10 s) in accordance with IEEE 802.1D [13]. (R) (optional) (2 bytes)
ForwardDelay: This attribute gives the time (in 256ths of a second) that the bridge on the
Ethernet card in the ONT retains a packet before forwarding it. It is the "ForwardDelay" time
received from the designated root. The range is 0x0400 to 0x1e00 (4 s to 30 s) in accordance
with IEEE 802.1D [13]. (R) (optional) (2 bytes)
Actions
Notifications
None.
110 ITU-T Rec. G.983.2 (07/2005)

7.3.31 MAC Bridge port configuration data
This managed entity is used to organize and record data that is associated with a bridge port. Some
of the data is volatile. Instances of this managed entity are created and deleted by request of the
OLT.
Relationships
Zero or more instances of this managed entity shall be contained in an instance of the
MACBridgeServiceProfile.
Attributes
BridgeIdPointer: This attribute identifies the MAC bridge controlling the port. This attribute
points to the instance of the MACBridgeServiceProfile. (R, Set-by-create) (mandatory) (2 bytes)
PortNum: This attribute provides the port number. (R, Set-by-create) (mandatory) (1 byte)
TPType: This attribute identifies the type of the termination point associated with this MAC
bridge port. The value is set to 0x01 if this bridge port is associated with the LAN side's
termination point. The value is set to 0x02 if this bridge port is associated with the ATM side's
termination point. The value is set to 0x03 if this bridge port is associated with an ATM
side 802.1p mapper service profile. (R, Set-by-create) (mandatory) (1 byte)
TPPointer: This attribute points to the termination point associated with this MAC bridge port.
If the TPType = 0x01, the value of this attribute is the same as the id of the Physical Path
Termination Point Ethernet UNI associated with this MAC bridge port. If the TPType = 0x02,
the value of this attribute is the same as the id of the Interworking VCC Termination Point
associated with this MAC bridge port. If the TPType = 0x03, the value of this attribute is the
same as the id of the 802.1p mapper service profile associated with this MAC bridge port.
(R, Set-by-create) (mandatory) (2 bytes)
PortPriority: This attribute denotes the priority of the port. The range is 0x00 to 0x00FF (0 to
255). (R, W, Set-by-create) (mandatory) (2 bytes)
PortPathCost: This attribute provides the cost contribution of the port to the path cost towards
the spanning tree root bridge. The range is 0x0001 to 0xFFFF (1 to 65535). (R, W,
PortSpanningTreeInd: This Boolean attribute indicates whether or not STP LAN topology
change detection is enabled at this port. The value TRUE means enabled. (R, W, Set-by-create)
EncapsulationMethod: This attribute identifies the frame encapsulation method that is used.
Value 0x00: identification by ATM VC; value 0x01: LLC encapsulation. This attribute is
effective only for ports towards the ANI side of the MAC bridge. Upon autonomous
instantiation, the value 0x00 is used. (R,W, Set-By-Create) (mandatory) (1 byte)
LANFCSInd: This attribute indicates whether LAN FCS (Frame Check Sequence) bytes are
forwarded (value 0x00) or discarded (value 0x01). This applies in both directions of
transmission, and applies regardless of EncapsulationMethod. This attribute is effective only for
ports towards the ANI side of the MAC bridge. Upon autonomous instantiation, the value 0x00
is used. (R, W, Set-By-Create) (optional) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 111

Actions
Notifications
None.
7.3.32 MAC Bridge port designation data
of the data is volatile. Instances of this managed entity shall be automatically created/deleted by the
ONT upon the creation/deletion of a MACBridgePortConfigurationData.
Relationships
This managed entity is associated with one instance of a MACBridgePortConfigurationData.
Attributes
entity. The assigned number is the same as the id of the MACBridgePortConfigurationData with
which this MACBridgePortDesignationData is associated. (R) (mandatory) (2 bytes)
DesignatedBridgeRootCostPort: This attribute provides the Designated Root, Designated Cost,
Designated Bridge, and Designated Port outputs of the "Read port parameters" operation defined
in 14.8.2.1 of IEEE 802.1D [13], i.e.,
– bridge identifier of the designated bridge for the port's segment (8 bytes);
– bridge identifier of the root transmitted by the designated bridge for the segment (8 bytes);
– port number of the designated port on the designated bridge considered to be part of this
port's segment (4 bytes);
– path cost contribution of the designated port to this port's segment (4 bytes).
Upon autonomous instantiation, this attribute consists of all 0x00. (R) (mandatory) (24 bytes).
PortState: This attribute provides status information on the port. Valid values include "disabled"
(value 0x00), "listening" (value 0x01), "learning" (value 0x02), "forwarding" (0x03), "blocking"
(value 0x04), "linkdown" (value 0x05), and "stp_off" (value 0x06) in accordance with
IEEE 802.1D [13].
NOTE – The value "linkdown" is introduced to denote the port status where the Ethernet link state is
down. This value is necessary to distinguish the case where Ethernet is physically down and the case
where Ethernet is administratively down, which can be denoted by "disabled." The value "stp_off" is
introduced to denote the port status where Spanning Tree Protocol is disabled, by setting
"PortSpanningTreeInd" of "MAC Bridge Port Configuration Data" to FALSE, and Ethernet link state is
up. This value is used to distinguish whether or not a bridge port forwarding frames is under control of
STP.
Upon autonomous instantiation, the value 0x00 is used. (R) (mandatory) (1 byte)
Actions
Notifications
None.
112 ITU-T Rec. G.983.2 (07/2005)

7.3.33 MAC Bridge port filter table data
ONT upon the creation/deletion of a MACBridgePortConfigurationData managed entity.
NOTE – Alternative schemes for this managed entity may be included in future Recommendations. Caution
must be exercised when writing to the table attribute when learning is active, as the contents of the table is
volatile. If OLT plans to write to the table, learning mode should be off at that time.
Relationships
This managed entity is associated with one instance of a MACBridgePortConfigurationData
managed entity.
Attributes
which this MACBridgePortFilterTableData is associated. (R) (mandatory) (2 bytes)
MACFilterTable: This attribute lists destination MAC Addresses associated with the bridge
port and an allow/disallow forwarding indicator for each of inbound traffic (towards the LAN
physical port) and outbound (towards the ATM side) traffic. One entry provides the Entry
number (1 byte) which is an index in this attribute list, Filter byte (1 byte), and MAC address
(6 bytes). Moreover, the bits of the Filter byte are assigned as described in Table 15f. Upon
autonomous instantiation, this attribute is a null list. An OMCI set message can carry a
maximum of 3 entries at the same time. (R, W) (mandatory) (N × 8 bytes, N is the number of
entries in the list.)
Table 15f/G.983.2 − Coding of filter byte in the MACFilterTable attribute

Bit Name Setting
8 Add/remove 0: remove this entry
1: add this entry
7-2 Reserved (0)
1 Filter/forward 0: forward
1: filter
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current MACFilterTable and
respond with the size of data (4 bytes), which should be obtained using the "Get next" command.
Get next: Get the latched attribute values of the managed entity within the current snapshot.
Set: Generally, this action is used to set one or more entire attribute values. When used on the
"MACFilterTable" attribute, the "Set" action either adds or deletes table entries from
"MACFilterTable". A maximum of 3 table entries can be added/deleted by a single "Set" action.
Notifications
None.
7.3.34 MAC Bridge port bridge table data
ONT upon the creation/deletion of a MACBridgePortConfigurationData.
ITU-T Rec. G.983.2 (07/2005) 113

Relationships
Attributes
which this MACBridgePortBridgeTableData is associated. (R) (mandatory) (2 bytes).
BridgeTable: This attribute lists the destination MAC Addresses, whether they are learned or
statically assigned, whether packets having them as destination addresses are filtered or
forwarded, and their ages. One entry provides Information (2 bytes) and MAC address (6 bytes).
Moreover, the Information bits are assigned as described in Table 15g. Upon autonomous
instantiation, this attribute is a null list. (R) (mandatory) (M × 8 bytes, M is the number of entries
in the list.)
Table 15g/G.983.2 − Coding of information in the BridgeTable attribute

Bit Name Setting
16-5 Age Age in seconds (1 s to 4095 s)
4 Reserved (0)
3 Dynamic/static 0: this entry is statically assigned.
1: this entry is dynamically learned.
2 Reserved (0)
1 Filter/forward 0: forward
1: filter
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current MACFilterTable and
respond with the size of the data (4 bytes) that should be obtained using the "Get next"
command.
Notifications
None.
7.3.35 MAC Bridge PM history data
This managed entity contains the past performance monitoring data collected at a MAC bridging
function supporting bridging interfaces on the ONT. Instances of this managed entity are
created/deleted by the OLT after/before an instance of the MACBridgeServiceProfile managed
entity is created/deleted.
Relationships
This managed entity is associated with one instance of a MACBridgeServiceProfile.
Attributes
entity. The assigned number is the same as the id of the MACBridgeServiceProfile with which
this MACBridgePMHistoryData is associated. (R, Set-by-create) (mandatory) (2 bytes)
114 ITU-T Rec. G.983.2 (07/2005)

BridgeLearningEntryDiscardCount: This attribute records the number of forwarding database
entries that have been or would have been learned but were discarded or replaced due to lack of
space in the database table. (R) (mandatory) (4 bytes)
Actions
Notifications
will be sent at the crossing of the threshold by the actual counter; the TCA change notification "off"
will be sent at the end of the 15-min period since that is when the actual counters are reset to 0x00.
The event list for this managed entity is given in Table 15g1.
Table 15g1/G.983.2 − Alarm list for MAC Bridge PM history data

Threshold data
counter # (Note)
0 BridgeLearningEntryDiscard BridgeLearningEntryDiscard threshold 1
crossing
1-223 Reserved
ITU-T Rec. G.983.2 (07/2005) 115

7.3.36 MAC Bridge port PM history data
This is a managed entity that contains the past performance monitoring data collected at the port
bridging function on the ONT. Instances of this managed entity are created/deleted by the OLT after
an instance of the MACBridgePortConfigurationData managed entity is created/deleted.
Relationships
Attributes
which this MACBridgePortPMHistoryData is associated. (R, Set-by-create) (mandatory)
(2 bytes)
ForwardedFrameCounter: This attribute provides a count of successfully transmitted frames
on this port. (R) (mandatory) (4 bytes)
DelayExceededDiscardCounter: This attribute provides a count of frames discarded on this
port because transmission is delayed. (R) (mandatory) (4 bytes)
MTUExceededDiscardCounter: This attribute provides a count of frames discarded on this port
because MTU is exceeded. (R) (mandatory) (4 bytes)
ReceivedFrameCounter: This attribute provides a count of frames received on this port.
ReceivedAndDiscardedCounter: This attribute provides a count of frames received on this port
that have been discarded due to errors. (R) (mandatory) (4 bytes)
Actions
116 ITU-T Rec. G.983.2 (07/2005)

Notifications
to 0x00. The event list for this managed entity is given in Table 15g2.
Table 15g2/G.983.2 − Alarm list for MAC Bridge port PM history data
Threshold data
counter # (Note)
0 Reserved
1 DelayExceededDiscard DelayExceededDiscard threshold crossing 1
2 MTUExceededDiscard MTUExceededDiscard threshold crossing 2
3 Reserved
4 ReceivedAndDiscarded ReceivedAndDiscarded threshold 3
crossing
5-223 Reserved
7.3.37 IP Port configuration data

This managed entity is used to organize data that is associated with IP address and IP port
provisioning. Instances of this managed entity are created and deleted by request of the OLT.
Relationship
Zero or one instances of this managed entity may exist for each instance of the Interworking
VCC Termination Point managed entity and a Subscriber Line Card managed entity classified as
a native LAN type (e.g., Ethernet).
Attributes
PortNum: This attribute identifies the port at which IP provisioning takes place. (R,
TPType: This attribute identifies the type of the termination point associated with this IP port.
The value is set to 0x01 if this IP port is associated with the LAN side's TP. The value is set to
0x02 if this IP port is associated with the ATM side's TP. (R, Set-by-create) (mandatory) (1 byte)
TPPointer: This attribute points to the instance of the TP associated with this port. When this
IP port is associated with the LAN side's TP, this attribute points to the instance of the
PPTP Ethernet UNI. When this IP port is associated with the ATM side's TP, this attribute points
to the instance of the Interworking VCC Termination Point. (R, Set-by-create) (mandatory)
(2 bytes)
ITU-T Rec. G.983.2 (07/2005) 117

PortAddress: This attribute identifies the provisioned IP address. When an IP address is not
assigned, this attribute consists of all 0x00. (R, Set-by-create) (mandatory) (4 bytes)
PortMask: This attribute identifies the address mask associated with the provisioned IP address.
When an IP address mask is not assigned, this attribute consists of all 0x00. (R, Set-by-create)
Unnumbered: This boolean attribute indicates whether or not this IP port has an IP address. The
value TRUE means unnumbered. (For future use by IP router function.) (R, Set-by-create)
AdministrativeState: This boolean attribute is used to activate (unlock, value 0x00) and
deactivate (lock, value 0x01) the functions performed by instances of this managed entity.
(R, W, Set-by-create) (1 byte)
PortState: This boolean attribute provides status information on the port. Valid values include
"up" (value 0x00) and "down" (value 0x01). (R, Set-by-create) (mandatory) (1 byte)
AllowRemoteAccess: This boolean attribute indicates whether or not this IP port may be
accessed remotely. The value TRUE means remote access is enabled. (R, Set-by-create)
Router Id Pointer: This attribute identifies the IP router controlling the port, if it exists. This
attribute points to the instance of the IP Router Service Profile. If no IP router controls the port,
this attribute consists of a null pointer (0xFFFF). (R, Set-by-create) (mandatory) (2 bytes)
ARP Pointer: This attribute identifies the instance of ARP Service Profile associated with the
IP port. (R, Set-by-create) (mandatory) (2 bytes)
EncapsulationMethod: This attribute identifies the frame encapsulation method that is used.
Value 0x00: identification by ATM VC; value 0x01: LLC encapsulation. Upon autonomous
instantiation, the value 0x00 is used. (R. W) (mandatory) (1 byte)
Actions
Notifications
None.
7.3.38 IP router service profile
This managed entity is used to organize data that affects all ports on an IP router on a routed LAN
UNI interface on the ONT. Instances of this managed entity are created and deleted by request of
the OLT.
Relationship
Zero or more instances of this managed entity shall be contained in an instance of a Subscriber
Line Card managed entity classified as a native LAN type (e.g., Ethernet).
Attributes
The second byte is the router group id. (R, Set-by-create) (mandatory) (2 bytes)
118 ITU-T Rec. G.983.2 (07/2005)

ForwardingInd: This boolean attribute indicates whether or not forwarding of IP packets as a
whole is enabled. The value TRUE means enabled. The initial value is enabled. (R, W,
Set by-create) (mandatory) (1 byte)
ProxyARPInd: This boolean attribute indicates whether or not proxy ARP is enabled. The value
TRUE means enabled. The initial value is enabled. (R, W, Set-by-create) (mandatory) (1 byte)
DirectedBroadcastInd: This boolean attribute indicates whether or not relaying of directed
broadcast packets is enabled. The value TRUE means enabled. The initial value is disabled.
(R, W, Set-by-create) (mandatory) (1 byte)
UpstreamMulticastFiltering: This attribute indicates whether upstream IP multicast packets are
forwarded (value 0x00) or filtered (value 0x01). The initial value is 0x01. (R,W, Set-by-create)
DownstreamMulticastFiltering: This attribute indicates whether downstream IP multicast
packets are forwarded (value 0x00) or filtered (value 0x01). The initial value is 0x01. (R,W,
Actions
Notifications
None.
7.3.39 IP router configuration data
This managed entity is used to record data that is associated with IP router configurations. An
instance of this managed entity shall be automatically created/deleted by the ONT upon
creation/deletion of the associated instance of IP Router Service Profile.
Relationship
An instance of this managed entity is associated with one instance of IP Router Service Profile.
Attributes
entity. The assigned number is the same as the id of the IP Router Service Profile with which this
IP Router Configuration Data is associated. (R) (mandatory) (2 bytes)
IpReasmTimeout: This attribute indicates the maximum number of seconds that received
fragments are held while they are awaiting reassembly at this router. (R) (mandatory) (4 bytes)
Actions
Notifications
None.
7.3.40 IP router PM history data 1
This managed entity contains some IP-related past performance monitoring data collected at
IP router function. Instances of this managed entity are created/deleted by the OLT after/before an
instance of IP Router Service Profile is created/deleted.
ITU-T Rec. G.983.2 (07/2005) 119

Relationship
Attributes
IP Router PM History Data 1 is associated. (R, Set-by-create) (mandatory) (2 bytes)
IpInReceivesCounter: This attribute provides a count of packets received from interfaces,
including those with errors. If the actual counter saturates, it remains on its maximum value.
IpInHdrErrorsCounter: This attribute provides a count of packets discarded due to errors in
their IP headers, including bad checksums, version number mismatch, other format errors,
time-to-live exceeded, errors discovered in processing their IP options, etc. If the actual counter
IpInAddrErrorsCounter: This attribute provides a count of packets discarded because the
IP address in their IP header's destination field was not a valid address to be received at this
router. This counter includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported
Classes (e.g., Class E). If the actual counter saturates, it remains on its maximum value. Default
IpForwPacketsCounter: This attribute provides a count of packets for which this router was not
their final IP destination, as a result of which an attempt was made to find a route to forward
them to that final destination. If the actual counter saturates, it remains on its maximum value.
IpInUnknownProtosCounter: This attribute provides a count of packets which were
locally-addressed and received successfully but discarded because of an unknown or
unsupported protocol. If the actual counter saturates, it remains on its maximum value. Default
IpInDiscardsCounter: This attribute provides a count of input packets for which no problems
were encountered to prevent their continued processing, but which were discarded (e.g., for lack
of buffer space). Note that this counter does not include any packets discarded while awaiting
reassembly. If the actual counter saturates, it remains on its maximum value. Default value is
IpInDeliversCounter: This attribute provides a count of input packets successfully delivered to
IP user-protocols (including ICMP). If the actual counter saturates, it remains on its maximum
value. Default value is 0x00. (R) (mandatory) (4 bytes)
120 ITU-T Rec. G.983.2 (07/2005)

IpOutRequestsCounter: This attribute provides a count of packets that local IP user-protocols
(including ICMP) supplied to IP in requests for transmission. Note that this counter does not
include any packets counted in ipForwPacketsCounter. If the actual counter saturates, it remains
on its maximum value. Default value is 0x00. (R) (mandatory) (4 bytes)
IpOutDiscardsCounter: This attribute provides a count of output packets for which no problem
was encountered to prevent their transmission to their destination, but which were discarded
(e.g., for lack of buffer space). Note that this counter would include packets counted in
ipForwPacketsCounter if any such packets met this (discretionary) discard criterion. If the actual
counter saturates, it remains on its maximum value. Default value is 0x00. (R) (mandatory)
(4 bytes)
IpOutNoRoutesCounter: This attribute provides a count of packets discarded because no route
could be found to transmit them to their destination. Note that this counter includes any packets
counted in ipForwPacketsCounter which meet this 'no-route' criterion. Note that this includes
any packets that a host cannot route because all of its default gateways are down. If the actual
(4 bytes)
Actions
Notifications
to 0x00. The event list for this entity is given in Table 15h/G.983.2.
Table 15h/G.983.2 − Alarm list for IP router PM history data 1

Threshold data
counter # (Note)
0 IpInReceives Exceeds threshold 1
1 IpInHdr Exceeds threshold 2
2 IpInAddr Exceeds threshold 3
3 IpForwPackets Exceeds threshold 4
4 IpInUnknownProtos Exceeds threshold 5
ITU-T Rec. G.983.2 (07/2005) 121

Table 15h/G.983.2 − Alarm list for IP router PM history data 1
Threshold data
counter # (Note)
5 IpInDiscards Exceeds threshold 6
6 IpInDelivers Exceeds threshold 7
7 IpOutRequests Exceeds threshold 8
8 IpOutDiscards Exceeds threshold 9
9 IpOutNoRoutes Exceeds threshold 10
10-223 Reserved
7.3.41 IP router PM history data 2

This managed entity contains other IP-related past performance monitoring data collected at
Relationship
Attributes
IP Router PM History Data 2 is associated. (R, Set-by-create) (mandatory) (2 bytes)
IpReasmReqdsCounter: This attribute provides a count of received packets that needed to be
reassembled at this entity. Default value is 0x00. (R) (mandatory) (4 bytes)
IpReasmOKsCounter: This attribute provides a count of packets successfully reassembled.
IpReasmFailsCounter: This attribute provides a count of failures detected by the IP reassembly
algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count
of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose
track of the number of fragments by combining them as they are received. Default value is 0x00.
122 ITU-T Rec. G.983.2 (07/2005)

IpFragOKsCounter: This attribute provides a count of packets that have been successfully
fragmented at this entity. Default value is 0x00. (R) (mandatory) (4 bytes)
IpFragFailsCounter: This attribute provides a count of packets that have been discarded
because they needed to be fragmented at this router but could not be, e.g., because their Don't
Fragment flag was set. Default value is 0x00. (R) (mandatory) (4 bytes)
IpFragCreatesCounter: This attribute provides a count of IP fragments that have been
generated as a result of fragmentation at this entity. Default value is 0x00. (R) (mandatory)
(4 bytes)
Actions
Notifications
to 0x00. The event list for this entity is given in Table 15i.
Table 15i/G.983.2 − Alarm list for IP router PM history data 2

Threshold data
counter # (Note)
0 IpReasmReqds Exceeds threshold 1
1 IpReasmOKs Exceeds threshold 2
2 IpReasmFails Exceeds threshold 3
3 IpFragOKs Exceeds threshold 4
4 IpFragFails Exceeds threshold 5
5 IpFragCreates Exceeds threshold 6
6-223 Reserved
ITU-T Rec. G.983.2 (07/2005) 123

7.3.42 ICMP PM history data 1
This managed entity contains some ICMP-related past performance monitoring data collected at
Relationship
Attributes
ICMP PM History Data 1 is associated. (R, Set-by-create) (mandatory) (2 bytes)
IcmpInMsgsCounter: This attribute provides a count of received ICMP messages. Note that
this counter includes all those counted by IcmpInErrorsCounter. Default value is 0x00.
IcmpInErrorsCounter: This attribute provides a count of ICMP messages that were received
but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.). Default
IcmpInDestUnreachsCounter: This attribute provides a count of received ICMP Destination
Unreachable messages. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpInTimeExcdsCounter: This attribute provides a count of received ICMP Time Exceeded
messages. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpInParmProbsCounter: This attribute provides a count of received ICMP Parameter
Problem messages. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpInSrcQuenchsCounter: This attribute provides a count of received ICMP Source Quench
IcmpInRedirectsCounter: This attribute provides a count of received ICMP Redirect messages.
IcmpInEchosCounter: This attribute provides a count of received ICMP Echo (request)
IcmpInEchoRepsCounter: This attribute provides a count of received ICMP Echo Reply
IcmpInTimestampsCounter: This attribute provides a count of received ICMP Timestamp
(request) messages. Default value is 0x00. (R) (mandatory) (4 bytes)
124 ITU-T Rec. G.983.2 (07/2005)

IcmpInTimestampRepsCounter: This attribute provides a count of received ICMP Timestamp
Reply messages. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpInAddrMasksCounter: This attribute provides a count of received ICMP Address Mask
IcmpInAddrMaskRepsCounter: This attribute provides a count of received ICMP Address
Mask Reply messages. Default value is 0x00. (R) (mandatory) (4 bytes)
Actions
Notifications
to 0x00. The event list for this entity is given in Table 15j.
Table 15j/G.983.2 − Alarm list for ICMP PM history data 1

Threshold data
counter # (Note)
0 IcmpInMsgs Exceeds threshold 1
1 IcmpInErrors Exceeds threshold 2
2 IcmpInDestUnreachs Exceeds threshold 3
3 IcmpInTimeExcds Exceeds threshold 4
4 IcmpInParmProbs Exceeds threshold 5
5 IcmpInSrcQuenchs Exceeds threshold 6
6 IcmpInRedirects Exceeds threshold 7
7 IcmpInEchos Exceeds threshold 8
8 IcmpInTimestamps Exceeds threshold 9
9 IcmpInTimestampReps Exceeds threshold 10
10 IcmpInAddrMasks Exceeds threshold 11
11 IcmpInAddrMaskReps Exceeds threshold 12
12-223 Reserved
ITU-T Rec. G.983.2 (07/2005) 125

Table 15j/G.983.2 − Alarm list for ICMP PM history data 1
Threshold data
counter # (Note)
7.3.43 ICMP PM history data 2

This managed entity contains other ICMP-related past performance monitoring data collected at
Relationship
Attributes
ICMP PM History Data 2 is associated. (R, Set-by-create) (mandatory) (2 bytes)
IcmpOutMsgsCounter: This attribute provides a count of ICMP messages that this router
attempted to send. Note that this counter includes all those counted by IcmpOutErrorsCounter.
IcmpOutErrorsCounter: This attribute provides a count of ICMP messages that this router did
not send due to problems discovered within ICMP such as a lack of buffers. This value should
not include errors discovered outside the ICMP layer such as the inability of IP to route the
resultant packet. In some implementations, there may be no types of error that contribute to this
counter's value. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpOutDestUnreachsCounter: This attribute provides a count of sent ICMP Destination
Unreachable messages. Default value is 0x00. (R) (mandatory) (4 bytes)
IcmpOutTimeExcdsCounter: This attribute provides a count of sent ICMP Time Exceeded
IcmpOutParmProbsCounter: This attribute provides a count of sent ICMP Parameter Problem
126 ITU-T Rec. G.983.2 (07/2005)

IcmpOutSrcQuenchsCounter: This attribute provides a count of sent ICMP Source Quench
IcmpOutRedirectsCounter: This attribute provides a count of sent ICMP Redirect messages.
IcmpOutEchosCounter: This attribute provides a count of sent ICMP Echo (request) messages.
IcmpOutEchoRepsCounter: This attribute provides a count of sent ICMP Echo Reply
IcmpOutTimestampsCounter: This attribute provides a count of sent ICMP Timestamp
IcmpOutTimestampRepsCounter: This attribute provides a count of sent ICMP Timestamp
IcmpOutAddrMasksCounter: This attribute provides a count of sent ICMP Address Mask
IcmpOutAddrMaskRepsCounter: This attribute provides a count of sent ICMP Address Mask
Actions
Notifications
to 0x00. The event list for this entity is given in Table 15k.
Table 15k/G.983.2 − Alarm list for ICMP PM history data 2

Threshold data
counter # (Note)
0 IcmpOutMsgs Exceeds threshold 1
1 IcmpOutErrors Exceeds threshold 2
2 IcmpOutDestUnreachs Exceeds threshold 3
ITU-T Rec. G.983.2 (07/2005) 127

Table 15k/G.983.2 − Alarm list for ICMP PM history data 2
Threshold data
counter # (Note)
3 IcmpOutTimeExcds Exceeds threshold 4
4 IcmpOutParmProbs Exceeds threshold 5
5 IcmpOutSrcQuenchs Exceeds threshold 6
6 IcmpOutRedirects Exceeds threshold 7
7 IcmpOutEchos Exceeds threshold 8
8 IcmpOutTimestamps Exceeds threshold 9
9 IcmpOutTimestampReps Exceeds threshold 10
10 IcmpOutAddrMasks Exceeds threshold 11
11 IcmpOutAddrMaskReps Exceeds threshold 12
12-223 Reserved
7.3.44 IP route table

This managed entity is used to record data that is associated with IP routes. Some of the data is
volatile. Instances of this managed entity shall be automatically created/deleted by the ONT upon
creation/deletion of the associated instances of IP Router Service Profile.
Relationship
Attributes
IP Route Table is associated. (R) (mandatory) (2 bytes)
IpRouteNumber: This attribute indicates the number of current routes in the route table. Default
IpRouteTableMaxSize: This attribute indicates the maximum number of routes that can be
stored in the route table. (R) (mandatory) (2 bytes)
IpRouteTable: This attribute lists current routes in the route table. A route consists of route-id,
destination-address, destination-address-mask, tos, next-hop, output-port, route-type,
route-protocol, route-age, and metric, which are further described below. (R) (mandatory)
(N × 30 bytes. N is the number of routes.)
– route-id: a unique identifier of a route within the route table (2 bytes);
– destination-address: the destination IP address of this route (4 bytes);
– destination-address-mask: the address mask associated with the destination address
(4 bytes);
– tos: TOS value defined in RFC 2096 [17] (ipCidrRouteTos) for use with policy routing;
otherwise, 0; (1 byte)
– next-hop: the address of the next router on remote routes (4 bytes);
128 ITU-T Rec. G.983.2 (07/2005)

– output-port: the port number of the IP port through which the next hop of this route should
be reached (1 byte);
– route-type: the type of route as defined in RFC 2096 [17] (ipCidrRouteType) (1 byte);
– route-protocol: the routing mechanism via which this route was learned, as defined in
RFC 2096 [17] (ipCidrRouteProto). For example, static route is 3 (1 byte);
– route-age: the number of seconds since this route was last updated or otherwise determined
to be correct. Static routes can return the maximum value (4 bytes);
– metric: the primary (first 4 bytes) and secondary (second 4 bytes) routing metrics for this
route. The semantics of this metric are determined by the routing-protocol specified in the
route's route-protocol value. If part of this metric is not used, its value should be set to –1
(2 × 4 bytes).
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current ipRouteTable and
respond with the size of data (4 bytes) that should be obtained using the Get next command.
Notifications
None.
7.3.45 IP static routes
This managed entity is used to set or delete IP static routes. Instances of this managed entity shall
be automatically created/deleted by the ONT upon creation/deletion of the associated instances of
IP Router Service Profile.
Relationship
Attributes
IP Static Routes is associated. (R) (mandatory) (2 bytes)
IpStaticRouteTableMaxSize: This attribute indicates the maximum number of routes that can
be set as static routes. (R) (mandatory) (2 bytes)
IpStaticRouteTable: This attribute is used to set or delete static routes in the route table. A route
consists of route-id, action, destination-address, destination-address-mask, next-hop, output-port,
and metric, which are further described below. (The same scenario is used for the MAC Filter
Table attribute of the MAC Bridge Port Filter Table Data managed entity. See I.1.3 and I.1.4.)
When this attribute is used to set a static route through the parameter action:add(1), the route
table is searched for the route-id parameter associated with the static route that is to be added. If
the same route-id is found, the route is overwritten. (R, W) (mandatory) (N × 21 bytes. N is the
number of routes.)
– route-id: a unique identifier of a route within the static route table (1 byte);
– action: remove (0) or add (1) this route. When a static route is being removed, only
static-route-id field is used to identify the route (1 byte);
– destination-address: the destination IP address of this route. This field may be set at the
default route address (0.0.0.0) (4 bytes);
– destination-address-mask: the address mask associated with the destination address
(4 bytes);
ITU-T Rec. G.983.2 (07/2005) 129

– next-hop: the address of the next router on remote routes. This field is not used when the
next-hop is reached through an unnumbered link (4 bytes, 0xFFFFFFFF when not used);
– output-port: the port number of the IP port through which the next hop of this route should
be reached. This field is used when the next-hop is reached through an unnumbered link
and when a static route is set to support a fully meshed network over ATM (1 byte, 0xFF
when not used);
– iVCCTPointer: the pointer to the instance of Interworking VCC Termination Point which
identifies one of the ATM links of the fully meshed network which is being set by this
attribute. The value 0x0000 is interpreted as a Null pointer. (optional, 2 bytes);
– metric: the routing metric for this route (4 bytes).
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current IpStaticRouteTable
and respond with the size of data (4 bytes) that should be obtained using the Get next command.
"IpStaticRouteTable" attribute, the "Set" action either adds or deletes table entries from
"IpStaticRouteTable". Only one entry can be added/deleted by a single "Set" action.
Notifications
None.
7.3.46 ARP service profile
This managed entity is used to organize data that is associated with the ARP function used by an
IP router function that contains an IP port of native LAN type. Instances of this managed entity are
created/deleted by the OLT after/before an instance of IPPortConfigurationData is created/deleted.
Relationship
An instance of this managed entity is associated with one instance of IP Port Configuration Data
of native LAN type.
Attributes
The second byte is the ARP group id. (R, Set-by-create) (mandatory) (2 bytes)
ARP Timer: This attribute indicates the maximum number of seconds that IP packets are held
while they are awaiting address resolution by ARP at this router. (R) (mandatory) (4 bytes)
ARP Cache Clear: This boolean attribute is used by the management system to initialize the
ARP cache associated with an instance of this entity. This attribute is used only to trigger the
"Cache Clear" action. The value TRUE means clear, and the value FALSE has no significance.
As the value of this attribute has no physical meaning, the action "Get" will always return the
value FALSE for this attribute. (R, W, Set-by-create) (mandatory) (1 byte)
Actions
130 ITU-T Rec. G.983.2 (07/2005)

Notifications
None.
7.3.47 ARP configuration data
This managed entity is used to organize data that is associated with the ARP function related to an
IP router that contains an IP port of native LAN type. Some of the data is volatile. Instances of this
managed entity shall be automatically created/deleted by the ONT upon creation/deletion of the
associated instance of ARP Service Profile.
Relationship
An instance of this managed entity is associated with one instance of ARP Service Profile.
Attributes
entity. The assigned number is the same as the id of the ARP Service Profile with which this
ARP Configuration Data is associated. (R) (mandatory) (2 bytes)
ARPTableMaxSize: This attribute indicates the maximum number of ARP entries that can be
set in the ARP table. (R) (mandatory) (2 bytes)
ARP Table: This attribute lists current entries in the ARP cache. An ARP cache entry consists of
port, IP-address, MAC-address, and type, which are further described below. (R) (mandatory)
(N × 12 bytes. N is the number of entries.)
– port: the port number of the IP port associated with the entry (1 byte);
– IP-address: an IP address (4 bytes);
– MAC-address: an equivalent MAC-address resolved by the ARP procedure (6 bytes);
– type: the entry type such as dynamic (3) or static (4) (1 byte).
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current ARP Table and
respond with the size of data (4 bytes) that should be obtained using the Get next command.
Notifications
None.
7.3.48 Physical path termination point ISDN UNI
This managed entity represents the point at the ISDN UNI in the ONT where physical paths
terminate and physical path level functions (e.g., analog telephony, facsimile function) are
performed. An instance of this managed entity shall be automatically created/deleted by the ONT
upon the creation/deletion of a Subscriber Line Card with ISDN type.
Relationships
One or more instances of this managed entity shall be contained in an instance of the ONTB-PON
or a Subscriber Line Card managed entity classified as ISDN type.
Attributes
ITU-T Rec. G.983.2 (07/2005) 131

port on a Subscriber Line Card, 0x02 is used for the next right/upper port, and so forth.
Interworking VCC Pointer: This attribute provides a pointer to the instance of the Interworking
VCC Termination Point managed entity to which this instance is connected. The value 0x0000 is
interpreted as a Null pointer. (R, W) (optional) (2 bytes)
DchannelID: This attribute provides the channel identifier of the AAL 2 connection transporting
the D channel associated with this ISDN BRI port. (R, W) (mandatory) (1 byte)
B1ChannelID: This attribute provides the channel identifier of the AAL 2 connection
transporting the B1 channel associated with this ISDN BRI port. (R, W) (mandatory) (1 byte)
B2ChannelID: This attribute provides the channel identifier of the AAL 2 connection
transporting the B2 channel associated with this ISDN BRI port. (R, W) (mandatory) (1 byte)
ISDN Loopback Configuration: This attribute represents the loopback configuration of this
physical interface. Value 0x00: no loopback; value 0x01: simultaneous loopback of all channels;
value 0x01: loopback of D channel only; value 0x02: loopback of B1 channel only; value 0x03:
loopback of B2 channel only. Upon autonomous instantiation, the value 0x00 is used. (R, W)
Actions
Test: Request that the ONT perform one or more MLT tests. See "Test" and "Test result"
message layouts in II.2.27 and II.2.45.
Notifications
alarm list for this entity is given in Table 15l.
Table 15l/G.983.2 − Alarm list for physical path termination point ISDN UNI
0 AIS Alarm indication signal
1 RDI Remote defect indication
2-223 Reserved
132 ITU-T Rec. G.983.2 (07/2005)

7.3.49 VLAN tagging operation configuration data
This managed entity is used to organize data associated with VLAN tagging. Instances of this
managed entity are created/deleted at the request of the OLT.
Relationship
Zero or one instance of this managed entity may exist for each instance of Physical Path
Termination Point Ethernet UNI.
Attributes
entity. The assigned number is the same as the id of the Physical Path Termination Point
Ethernet UNI with which this VLAN Tagging Operation Configuration Data instance is
associated. (R, Set-by-create) (mandatory) (2 bytes)
Upstream VLAN Tagging Operation Mode: This attribute selects whether or not upstream
VLAN tagging is sent. Valid values are 0x00 (upstream frame is sent "as is", regardless of
whether or not the received frame is tagged) and 0x01 (The upstream frame is sent as tagged
whether or not the received frame is tagged. TCI, consisting of VID, CFI and user priority, is
attached or overwritten by using the Upstream VLAN Tag TCI Value.). (R, W, Set-by-create)
Upstream VLAN Tag TCI Value: This attribute indicates the TCI value for upstream VLAN
tagging. It is used when the Upstream VLAN Tagging Operation Mode is 0x01. Any 2-byte
value is acceptable. (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream VLAN Tagging Operation Mode: This attribute selects whether or not
downstream VLAN tagging is sent. Valid values are 0x00 (downstream frame is sent "as is",
regardless of whether or not the received frame is tagged) and 0x01 (The downstream frame is
sent as untagged whether or not the received frame is tagged). (R, W, Set-by-create) (mandatory)
(1 byte)
Actions
Notifications
None.
7.3.50 VLAN tagging filter data
This managed entity is used to organize data associated with VLAN tagging. Instances of this
managed entity are created/deleted at the request of the OLT.
Relationships
Zero or one instance of this managed entity may exist for each instance of MAC Bridge Port
Configuration Data which is associated with Interworking VCC Termination Point (PON side) or
Physical Path Termination Point Ethernet UNI.
Attributes
ITU-T Rec. G.983.2 (07/2005) 133

which this VLAN Tagging Filter Data instance is associated. (R, Set-by-create) (mandatory)
(2 bytes)
VLAN Filter Table: This attribute lists TCI values which are provisioned at a bridging port.
Since a TCI value (consisting of user priority, CFI and VID) is represented by 16 bits, 2 bytes
are reserved for this attribute per VLAN. Twelve separate VLAN entries are supported. The first
N are valid, where N is given by the NumberOfEntries attribute. (R, W, Set-by-create)
Forward Operation: When a frame is received, the frame is processed according to the
following Forward Operations. The operations are invoked based on the value of VID, user
priority, or the entire TCI or whether or not the TCI field exists. This attribute indicates the
received frame is treated as indicated below. (R,W, set-by-create) (mandatory) (1 byte)
NumberOfEntries: This attribute provides the number of entries in the VLAN Filter Table that
are valid. (R, W, Set-by-Create) (mandatory) (1 byte)
Actions
Notifications
None.
Supplementary explanation
1) Ethernet frame and fields format for VLAN services
The detailed format of Ethernet frame for VLAN services is described in IEEE 802.1Q [18]
and is depicted in Figure 37.
Figure 37/G.983.2 – Detailed format for Ethernet frame with VLAN tag
2) Operations
Operations specified in the attribute "Forward Operation" are explained. Forward
Operations are specified by a combination of the basic actions mentioned.
a) Basic MAC bridge operation: As shown in Figure 38, if DA (Destination MAC
Address) in the received frame is listed in one or more ports with MAC Bridge Port
Bridge Table Data, this frame is forwarded to the indicated ports. Otherwise, it is
broadcasted to all of the ports excepting for its receiving port.
134 ITU-T Rec. G.983.2 (07/2005)

Figure 38/G.983.2 – Basic MAC Bridge operation
b) Unconditional forwarding for Tagged frame: If a tagged frame is received, it is
forwarded without investigation of TCI.
c) Unconditional discarding for Tagged frame: If a tagged frame is received, it is
discarded without investigation of TCI.
d) Unconditional forwarding for Untagged frame: If an untagged frame is received, it
is forwarded without investigation of TCI.
e) Unconditional discarding for Untagged frame: If an untagged frame is received, it is
discarded without investigation of TCI.
f) Positive filtering by TCI: If a part or all of the fields in the TCI of the received frame
are included in VLAN Tag Filter Data, it is forwarded according to Action a) to the
indicted ports as shown in Figure 39. Otherwise, its TCI is ignored and it is controlled
by Action a).
Figure 39/G.983.2 – Positive filtering by TCI operation

g) Negative filtering by TCI: If a part or all of the fields in the TCI of the received frame
are included in VLAN Tag Filter Data, it is discarded. Otherwise, it is forwarded
according to Action a) as shown in Figure 40.
ITU-T Rec. G.983.2 (07/2005) 135

Figure 40/G.983.2 – Negative filtering by TCI operation
The Forwarding Operation is specified by a combination of these actions.
The type of received frame

Tagged Untagged
0x00 Action a) Action a)
0x01 Action c) Action a)
0x02 Action a) Action e)
0x03 Action f) (VID investigation) Action a)
0x04 Action f) (VID investigation) Action e)
0x05 Action g) (VID investigation) Action a)
0x06 Action g) (VID investigation) Action e)
0x07 Action f) (user priority investigation) Action a)
0x08 Action f) (user priority investigation) Action e)
0x09 Action g) (user priority investigation) Action a)
0x0A Action g) (user priority investigation) Action e)
0x0B Action f) (TCI investigation) Action a)
0x0C Action f) (TCI priority investigation) Action e)
0x0D Action g) (TCI investigation) Action a)
0x0E Action g) (TCI investigation) Action e)
7.3.51 MAC Bridge port filter preassign table

This managed entity provides an alternate approach to address filtering than that supported through
MACBridgePortFilterTableData. This alternate approach is useful when all the groups of addresses
are stored beforehand in the line card, and this managed entity is used to designate which groups are
valid or invalid for filtering. The MAC addresses and Ether types for various protocols are provided
in Appendix VI. Instances of this managed entity are created/deleted autonomously after
creation/deletion of a Subscriber Line Card ME of Ethernet type in which all groups of addresses
are preassigned and stored in the card.
136 ITU-T Rec. G.983.2 (07/2005)

Relationships
This managed entity is associated with one instance of a MACBridgePortConfigurationData
managed entity.
Attributes
which this MAC Bridge Port Filter Preassign Table instance is associated. (R) (mandatory)
(2 bytes)
IPv4MulticastFiltering: This attribute indicates whether IPv4Multicast Ether types are
forwarded (value 0x00) or filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory)
(1 byte)
IPv6MulticastFiltering: This attribute indicates whether Ipv6Multicast Ether types are
(1 byte)
IPv4BroadcastFiltering: This attribute indicates whether IPv4Broadcast Ether types are
(1 byte)
RARPFiltering: This attribute indicates whether RARP Ether types are forwarded (value 0x00)
or filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
IPXFiltering: This attribute indicates whether IPX Ether types are forwarded (value 0x00) or
filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
NetBEUIFiltering: This attribute indicates whether NetBEUI Ether types are forwarded (value
0x00) or filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
AppleTalkFiltering: This attribute indicates whether AppleTalk Ether types are forwarded
(value 0x00) or filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
BridgeManagementInformationFiltering: This attribute indicates whether
BridgeManagementInformation Ether types are forwarded (value 0x00) or filtered (value 0x01).
Initial value is 0x00. (R,W) (mandatory) (1 byte)
Note that some MAC addresses should not be handled, considering the following rules of
IEEE 802.1D [13]:
1) Addresses from 0x0180C2000000 to 0x0180C200000F are reserved;
2) Addresses from 0x0180C2000020 to 0x0180C20002F are used for GARP Application
Address.
ARPFiltering: This attribute indicates whether ARP Ether types are forwarded (value 0x00) or
filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
PPPoEFiltering: This attribute indicates whether PPPoE Ether types are forwarded (value 0x00)
or filtered (value 0x01). Initial value is 0x00. (R,W) (mandatory) (1 byte)
Actions
Notifications
None.
ITU-T Rec. G.983.2 (07/2005) 137

7.3.52 Physical path termination point video UNI
This managed entity represents the point at the video UNI in the ONT where physical paths
terminate and physical path level functions are performed.
An instance of this managed entity shall be automatically created/deleted by the ONT upon
creation/deletion of a Subscriber Line Card of Video type.
Relationships
Line Card managed entity classified as Video type.
Attributes
is the port id with value range from 0x01 to 0xFF (1 to 255); 0x01 is used for the leftmost/lowest
(lock: value 0x01) functions performed by instances of this managed entity. Selection of a
default value for this attribute is outside the scope of this Recommendation, as it is normally
handled through supplier-operator negotiations. (R,W) (mandatory) (1 byte)
Power control: This attribute controls whether power is provided to an external equipment over
the video PPTP. Value 0x01 enables power over co-ax. The default value 0x00 disables power
feed. (R, W) (optional) (1 byte)
Actions
Notifications
Table 15m.
detected or cleared. Both ONT and OLT should know the alarm ist used by this entity. The alarm
list for this entity is given in Table 15n.
138 ITU-T Rec. G.983.2 (07/2005)

Table 15m/G.983.2 − AVC list for physical path termination point video UNI
1 N/A
2 OpState Operational state of video UNI
3-16 Reserved Reserved for AVCs of vendor-specific attributes
Table 15n/G.983.2 − Alarm list for physical path termination point video UNI
0 Video-LOS No signal at the video UNI
1-223 Reserved Reserved for vendor-specific alarms
7.3.53 Physical path termination point video ANI

This managed entity represents the point at the video ANI in the ONT where physical paths
terminate and physical path level functions are performed.
creation/deletion of a Subscriber Line Card of Video type.
Relationships
Line Card managed entity classified as Video type.
Attributes
entity. There is only one instance, and it has the number 0x0000. (R) (mandatory) (2 bytes)
FrequencyRangeLow: This attribute indicates the lower of the possibly two frequency ranges
supported. Different frequency ranges are indicated by code points, as given below:
– 0 indicates no low band is supported;
– 1 indicates 50-550 MHz is supported;
– 4..255 are reserved for future use.
ITU-T Rec. G.983.2 (07/2005) 139

FrequencyRangeHigh: This attribute indicates the higher of the two frequency ranges
supported. Different frequency ranges are indicated by code points, as given below:
– 0 indicates no high band is supported;
SignalCapability: This attribute indicates the capability of the ONT to measure the video signal
level. Different capabilities are indicated by code points, as given below:
– 0 indicates no signal level capability is supported;
– 1 indicates total optical power level is supported;
– 2 indicates fixed frequency pilot tone power level is supported;
– 3 indicates total optical power level and fixed frequency pilot tone power level are
supported;
– 4 indicates variable frequency pilot tone power level is supported;
– 5 indicates total optical power level and variable frequency pilot tone power level are
supported;
– 6 indicates broadband RF power level is supported;
– 7 indicates total optical power level and broadband RF power level is supported;
OpticalSignalLevel: This attribute indicates the current measurement of the total optical signal
level. The unit of this attribute is dBµW optical.
If SignalCapability = 0, 2, or 4 then this attribute is undefined.
If SignalCapability = 1, 3, 5, or 7, then this attribute describes the total optical power that is
generating photocurrent on the receiver.
(R) (optional) (1 byte)
PilotSignalLevel: This attribute indicates the current measurement of the pilot signal level or
broadband RF level. The unit of this attribute is dBµV at the RF video service port.
If SignalCapability = 0 or 1, then this attribute is undefined.
If SignalCapability = 2, 3, 4, or 5, then this attribute describes the pilot signal level at the output
of the video UNI.
If SignalCapability = 6, or 7, then this attribute describes the total RF power level at the output
of the video UNI.
140 ITU-T Rec. G.983.2 (07/2005)

SignalLevelMin: This attribute indicates the minimum optical RF power per channel that will
result in a CNR of 47 dBc for a channel of 4.5 MHz in bandwidth at a receive optical power of
–5 dBm. The unit of this attribute is dBµW optical.
SignalLevelMax: This attribute indicates the maximum optical RF power per channel that will
result in a CTB of –57 dBc for an 80-channel ensemble of carriers at a per-channel optical
modulation index of 3.5%. The units of the attributes are in dBµW optical.
PilotFrequency: This attribute indicates the frequency of the pilot channel receiver. This unit of
this attribute is Hz.
If SignalCapability = 0 or 1, this attribute is undefined;
If SignalCapability = 2 or 3, this attribute is functionally read only;
If SignalCapability = 4 or 5, this attribute is read-write.
(R, W) (optional) (4 bytes)
AGCmode: This attribute allows the discovery and configuration of the ONT's AGC
capabilities. The attribute contains a codepoints for the several AGC types. The ONT displays
the currently used AGC mode. The OLT can discover new modes via the set command. The
code points are:
– 0, no AGC is used;
– 1, broadband RF AGC is used;
– 2, optical AGC is used;
– 3-255, reserved for future use.
(R, W) (optional) (1 byte)
AGCsetting This attribute indicates the measurement offset that the ONT should use if using
broadband RF signal level or total optical power as a basis for AGC. The theoretical nominal
RF signal is 80-channels of NTSC video, each having a per-channel optical modulation index of
3.5%. An ONT presented with such a signal should produce its specified output when this
attribute is set to zero. The attribute will have a step-size of 0.1 dB, represented as a signed
integer. The usage of the attribute depends on the signal capability used for the AGC.
If total optical power is used for AGC, then this attribute provides the ONT with the OMI offset
for any NTSC carriers present from the theoretical 3.5% value. So, if the actual signal uses an
OMI of 7.0% per channel (3 dB higher), then the ONT should be given an AGC setting of 30.
(Coded 0x1E).
If broadband RF power is used for AGC, then this attribute provides the ONT with the total
power offset for any NTSC carriers present from the theoretical 80 channel value. So, if an
actual signal contains 40 NTSC channels (3 dB lower), then the ONT should be given an
AGC setting of –30. (Coded 0xE2).
(R, W) (optional) (1 byte)
Actions
ITU-T Rec. G.983.2 (07/2005) 141

Notifications
Table 15o.
alarm list for this entity is given in Table 15p.
Table 15o/G.983.2 − AVC list for physical path termination point video ANI
1 N/A
2 OpState Operational state of video ANI
3-16 Reserved Reserved for AVCs of vendor-specific attributes
Table 15p/G.983.2 − Alarm list for physical path termination point video ANI
0 Video-LOS No signal at the video ANI
1-223 Reserved Reserved for vendor-specific alarms
7.3.54 Physical path termination point LCT UNI

This managed entity represents the point at the local craft terminal UNI in the ONT where physical
paths terminate and physical path level functions are performed.
creation/deletion of a Subscriber Line Card of LCT type. However, this instance will not be
reported during a MIB upload.
Relationships
Line Card managed entity classified as LCT type.
Attributes
is the port id with value range from 0x01 to 0xFF (1 to 255); 0x01 is used for the leftmost/lowest
Actions
142 ITU-T Rec. G.983.2 (07/2005)

Notifications
None.
7.3.55 Ethernet performance monitoring history data 2
This managed entity contains the last completed 15-minute interval collected statistic data for an
Ethernet interface. The statistic data value is only updated at the end of each period.
Instances of this managed entity are created/deleted by the OLT after an instance of Physical Path
Termination Point Ethernet UNI managed entity is created/deleted.
Relationships
One instance of this Ethernet Performance Monitoring History Data 2 managed entity can exist
for each instance of the Physical Path Termination Point Ethernet UNI.
Attributes
entity. This 2-byte number is the same as the id of the Physical Path Termination Point Ethernet
the statistic data values are updated. The value of this attribute is 0x00 during the first 15-minute
statistic data value is updated at the end of the interval. (R) (mandatory) (1 byte)
PPPoEFilteredFrame Counter: This attribute provides a count of the number of frames that
have been discarded due to PPPoE filtering. Default value is 0x00. (R) (mandatory) (4 bytes)
Actions
Get Current Data: This action returns the current value of one or more actual counters
counters would be reset at the end of the interval.
Notifications
ITU-T Rec. G.983.2 (07/2005) 143

The event list for this entity is given in Table 15q.
Table 15q/G.983.2 − Alarm list for Ethernet performance monitoring history data 2
Threshold data
counter # (Note)
0 PPPoEFilteredFrameCounter Exceeds threshold 1
1-223 Reserved
7.3.56 Physical path termination point 802.11 UNI

Relationships
One instance of this managed entity may exist for each instance of an IEEE 802.11 interface. An
instance of this entity is created/deleted by the ONU whenever an IEEE 802.11 UNI card is
inserted/removed from the ONU.
Attributes
dot11SupportedDataRatesTx: This attribute shall specify the set of data rates (maximum of
8 data rates) at which the station is capable of transmitting data. Each octet contains a value
representing a rate. Each rate shall be within the range from 2 to 127, corresponding to data rates
in increments of 500 kbit/s from 1 Mbit/s to 63.5 Mbit/s, and shall be supported (as indicated in
the supported rates table) for transmitting data. If fewer than 8 data rates are specified, each of
the remaining bytes shall use the value 0x00. (R) (mandatory) (8 bytes)
dot11SupportedDataRatesRx: This attribute shall specify the set of data rates (maximum of
8 data rates) at which the station is capable of receiving data. Each octet contains a value
representing a rate. Each rate shall be within the range from 2 to 127, corresponding to data rates
in increments of 500 kbit/s from 1 Mbit/s to 63.5 Mbit/s, and shall be supported (as indicated in
the supported rates table) for receiving data. If fewer than 8 data rates are specified, each of the
remaining bytes shall use the value 0x00. (R) (mandatory) (8 bytes)
144 ITU-T Rec. G.983.2 (07/2005)

dot11TxPowerLevels: This attribute shall specify the set of transmit power levels (maximum
of 8 power levels) which the station is capable of using. Each 16 bit word contains an integer
representation of the power setting, in units of mW. If fewer than 8 power levels are specified,
each of the remaining words shall use the value 0x0000. (R) (mandatory) (16 bytes)
Actions
Notifications
attributes of this managed entity. The attribute value change notification shall identify the
attribute changed and its new value. The list of AVCs for this managed entity is given in
Table 16.
Table 16/G.983.2 − AVC list for physical path termination point 802.11 UNI
(reproduced from Table 2/G.983.9)
1 N/A
2 OpState Operational state of Physical Path Termination
Point 802.11 UNI
3-9 N/A
10-16 Reserved
7.3.57 UNI 802.11 station management data 1

Relationships
One instance of this managed entity may exist for each instance of an IEEE 802.11 interface.
The ONU automatically creates an instance of this entity whenever a PPTP 802.11 UNI instance
is created.
Attributes
entity. This ME id shall be the same as that of the related instance of Physical Path Termination
Point 802.11 UNI. (R) (mandatory) (2 bytes)
dot11MediumOccupancyLimit: This attribute shall indicate the maximum amount of time, in
TU, that a point coordinator may control the usage of the wireless medium without relinquishing
control for long enough to allow at least one instance of DCF access to the medium. The default
value of this attribute shall be 100, and the maximum value shall be 1000. (R, W) (mandatory)
(2 bytes)
dot11CFPollable: When this Boolean attribute is true, it shall indicate that the STA is able to
respond to a CF-Poll with a data frame within a SIFS time. This attribute shall be false if the
STA is not able to respond to a CF-Poll with a data frame within a SIFS time. (R) (mandatory)
(1 byte)
ITU-T Rec. G.983.2 (07/2005) 145

dot11CFPPeriod: This attribute shall describe the number of DTIM intervals between the start
of CFPs. (R,W) (mandatory) (1 byte)
dot11CFPMaxDuration: This attribute shall describe the maximum duration of the CFP in TU
that may be generated by the PCF. (R, W) (mandatory) (2 bytes)
dot11AuthenticationResponseTimeOut: This attribute shall specify the number of TU that a
responding STA should wait for the next frame in the authentication sequence. (R, W)
dot11PrivacyOptionImplemented: This Boolean attribute, when true, shall indicate that the
IEEE 802.11 WEP option is implemented. The default value of this attribute shall be false.
dot11PowerManagementMode: This attribute shall specify the power management mode of the
STA. When set to active (0x00), it shall indicate that the station is not in power-save mode.
When set to powersave (0x01), it shall indicate that the station is in power-save mode. (R, W)
dot11DesiredSSID1: This attribute contains the first half of the Service Set ID used in the
DesiredSSID parameter of the most recent MLME_Scan.request. This value may be modified by
an external management entity and used by the local SME to make decisions about the scanning
process. (R, W) (mandatory) (16 bytes)
dot11DesiredSSID2: This attribute contains the second half of the Service Set ID used in the
DesiredSSID parameter of the most recent MLME_Scan.request. This value may be modified by
an external management entity and used by the local SME to make decisions about the scanning
process. (R, W) (mandatory) (16 bytes)
dot11DesiredBSSType: This attribute shall specify the type of BSS the station shall use when
scanning for a BSS with which to synchronize. This value is used to filter Probe Response
frames and Beacons. When set to infrastructure (0x00), the station shall only synchronize with a
BSS whose Capability Information field has the ESS subfield set to 1. When set to independent
(0x01), the station shall only synchronize with a BSS whose Capability Information field has the
IBSS subfield set to 1. When set to any (0x02), the station may synchronize to either type of
BSS. (R, W) (mandatory) (1 byte)
dot11OperationalRateSet: This attribute shall specify the set of data rates (maximum of 8 data
rates) at which the station may transmit data. Each octet contains a value representing a rate.
Each rate shall be within the range from 2 to 127, corresponding to data rates in increments of
500 kbit/s from 1 Mbit/s to 63.5 Mbit/s, and shall be supported (as indicated in the supported
rates table) for receiving data. If fewer than 8 data rates are specified, each of the remaining
bytes shall use the value 0x00. This value is reported in transmitted Beacon, Probe Request,
Probe Response, Association Request, Association Response, Reassociation Request, and
Reassociation Response frames, and is used to determine whether a BSS with which the station
desires to synchronize is suitable. (R, W) (mandatory) (8 bytes)
dot11BeaconPeriod: This attribute shall specify the number of TU that a station shall use for
scheduling Beacon transmissions. This value is transmitted in Beacon and Probe Response
frames. (R, W) (mandatory) (2 bytes)
dot11DTIMPeriod: This attribute shall specify the number of beacon intervals that shall elapse
between transmission of Beacons frames containing a TIM element whose DTIM Count field
is 0. This value is transmitted in the DTIM Period field of Beacon frames. (R, W) (mandatory)
(1 byte)
146 ITU-T Rec. G.983.2 (07/2005)

dot11AssociationResponseTimeOut: This attribute shall specify the number of TU that a
requesting STA should wait for a response to a transmitted association-request MMPDU. (R, W)
dot11AuthenticationAlgorithm: This attribute shall indicate all of the authentication algorithms
supported by the STAs. The attribute is a bit-mapped coding, formatted as follows:
0000 0000 0000 0000 0000 0000 0000 00yx,
where
0 = reserved, must be set to zero
x = Open System (1=Supported, 0=Not supported)
y = Shared Key Supported (1=Supported, 0=Not supported)
dot11AuthenticationAlgorithmsEnable: This attribute shall indicate the enable status of the
authentication algorithms supported by the STAs. The attribute is a bit-mapped coding,
formatted as follows:
0000 0000 0000 0000 0000 0000 0000 00yx,
where
0 = reserved, must be set to zero
x = Open System (1=Enabled, 0=Not Enabled)
y = Shared Key (1=Enabled, 0=Not Enabled)
Actions
Notifications
None.
7.3.58 802.11 station management data 2
Relationships
is created.
Attributes
dot11DisassociateReason: This attribute holds the most recently transmitted Reason Code in a
disassociation frame. If no Disassociation frame has been transmitted, the value of this attribute
shall be 0. (R) (mandatory) (2 bytes)
dot11DisassociateStation: This attribute holds the MAC address from the Address 1 field of the
most recently transmitted Disassociation frame. If no Disassociation frame has been transmitted,
the value of this attribute shall be 0. (R) (mandatory) (6 bytes)
ITU-T Rec. G.983.2 (07/2005) 147

dot11DeauthenticateReason: This attribute holds the most recently transmitted Reason Code in
a Deauthentication frame. If no Deauthentication frame has been transmitted, the value of this
attribute shall be 0. (R) (mandatory) (2 bytes)
dot11DeauthenticateStation: This attribute holds the MAC address from the Address 1 field of
the most recently transmitted Deauthentication frame. If no Deauthentication frame has been
transmitted, the value of this attribute shall be 0. (R) (mandatory) (6 bytes)
dot11AuthenticateFailStatus: This attribute holds the most recently transmitted Status Code in
a failed Authentication frame. If no failed Authentication frame has been transmitted, the value
of this attribute shall be 0. (R) (mandatory) (2 bytes)
dot11AuthenticateFailStation: This attribute holds the MAC address from the Address 1 field
of the most recently transmitted failed Authentication frame. If no failed Authentication frame
has been transmitted, the value of this attribute shall be 0. (R) (mandatory) (6 bytes)
dot11WEPDefaultKeyValue1: This attribute holds WEP Default Key #1. The WEP default
secret keys are logically WRITE-ONLY. Attempts to read the entries in this table shall return
unsuccessful status and values of null or zero. The default value of each WEP default key shall
be null. (W) (mandatory) (5 bytes)
dot11WEPDefaultKeyValue2: This attribute holds WEP Default Key #2. (W) (mandatory)
(5 bytes)
(5 bytes)
(5 bytes)
dot11PrivacyInvoked&dot11ExcludeUnencrypted: This attribute holds two truth values. It is
coded 0000 00yx, where x indicates the dot11PrivacyInvoked value, and y indicates the
dot11ExcludeUnencrypted value. When dot11PrivacyInvoked is true, it shall indicate that the
IEEE 802.11 WEP mechanism is used for transmitting frames of type Data. The default value of
this attribute shall be false. When dot11ExcludeUnencrypted is true, the STA shall not indicate
at the MAC service interface received MSDUs that have the WEP subfield of the Frame Control
field equal to zero. When this attribute is false, the STA may accept MSDUs that have the WEP
subfield of the Frame Control field equal to zero. The default value of this attribute shall be false.
dot11WEPDefaultKeyID: This attribute shall indicate the use of the first, second, third, or
fourth WEPDefaultKey when set to values of zero, one, two, or three. The default value of this
attribute shall be 0. (R, W) (mandatory) (1 byte)
dot11WEPKeyMappingLength: The maximum number of tuples that dot11WEPKeyMappings
can hold. (R, W) (mandatory) (4 bytes)
dot11WEPICVErrorCount: This counter shall increment when a frame is received with the
WEP subfield of the Frame Control field set to one and the value of the ICV as received in the
frame does not match the ICV value that is calculated for the contents of the received frame.
dot11WEPExcludedCount: This counter shall increment when a frame is received with the
WEP subfield of the Frame Control field set to zero and the value of dot11ExcludeUnencrypted
causes that frame to be discarded. (R) (mandatory) (4 bytes)
Actions
148 ITU-T Rec. G.983.2 (07/2005)

Notifications
attributes of this managed entity. The attribute value change notification shall identify the
attribute changed and its new value. The list of AVCs for this managed entity is given in
Table 17. Notifications should be sent when a Disassociate, Deauthenticate, or
AuthenticationFail event occurs. These events will normally coincide with a change in the
DisassociateStation, DeauthenticateStation, or AuthenticationFailStation attributes.
Table 17/G.983.2 − AVC list for 802.11 station management data 2

1 N/A
2 dot11DisassociateStation MAC address from the Address 1 field of the most
recently transmitted Disassociation frame
3 N/A
4 dot11DeauthenticateStation MAC address from the Address 1 field of the most
recently transmitted Deauthentication frame
5 N/A
6 dot11AuthenticateFailStation MAC address from the Address 1 field of the most
recently transmitted failed Authentication frame
7-15 N/A
16 Reserved
7.3.59 802.11 general purpose object

Relationships
Many instances of this managed entity may exist for each instance of an IEEE 802.11 interface.
This object is used to contain the following IEEE 802.11 data: WEP Key Mappings, Group
Addresses, Reg Domain Supported, and Antennas List. Each of these uses has its own attributes
defined, and a type attribute indicates which subset of attributes is active for each instance.
Regardless of which attributes are active, each attribute shall be numbered (in attribute mask)
according to the ordering of the full attribute set indicated below.
For object types 0 and 1, the OLT may create and delete instances of this object. For object
types 2 and 3, the ONU instantiates as many instances as required to model the UNI's
capabilities.
Attributes
ObjectType: This attribute indicates how this entity is to be used, defined as:
– 0: WEP Key Mapping;
– 1: Group Addresses;
– 2: Reg Domain Supported;
– 3: Antennas List.
ITU-T Rec. G.983.2 (07/2005) 149

For any given type, only the relevant attributes have valid contents. The other attributes are
unspecified. (R, Set-by-create) (mandatory) (1 byte)
PhysicalPathTerminationPoint802.11Pointer: This attribute indicates the specific Physical
Path Termination Point to which this object corresponds. (R, Set-by-create) (mandatory)
(2 bytes)
dot11WEPKeyMappingAddress: Valid if ObjectType = 0. The MAC address of the STA for
which the values from this key mapping entry are to be used. (R, W, Set-by-create) (mandatory)
(6 bytes)
dot11WEPKeyMappingWEPOn: Valid if ObjectType = 0. Boolean as to whether WEP is to be
used when communicating with the dot11WEPKeyMappingAddress STA (R, W, Set-by-create)
dot11WEPKeyMappingValue: Valid if ObjectType = 0. A WEP secret key value.
(W, Set-by-create) (mandatory) (5 bytes)
dot11Address: Valid if ObjectType = 1. MAC address identifying a multicast addresses from
which this STA will receive frames (R, Set-by-create) (mandatory) (6 bytes)
dot11RegDomainsSupportValue: Valid if ObjectType = 2. There are different operational
requirements dependent on the regulatory domain. This attribute list describes the regulatory
domains the PLCP and PMD support in this implementation. Currently defined values and their
corresponding Regulatory Domains are: FCC (USA) = X'10', DOC (Canada) = X'20', ETSI
(most of Europe) = X'30', Spain = X'31', France = X'32', MKK (Japan) = X'40' (R) (mandatory)
(1 byte)
dot11SupportedTxAntenna: Valid if ObjectType = 3. When true, this Boolean object indicates
that the antenna represented by this managed entity id can be used as a transmit antenna.
dot11SupportedRxAntenna: Valid if ObjectType = 3. When true, this Boolean object indicates
that the antenna represented by this managed entity id can be used as a receive antenna.
dot11DiversitySelection Rx: Valid if ObjectType = 3. When true, this Boolean object indicates
that the antenna represented by managed entity id can be used for receive diversity. This object
may only be true if the antenna can be used as a receive antenna, as indicated by
dot11SupportedRxAntenna (R, W) (mandatory) (1 byte)
Actions
Notifications
None.
7.3.60 802.11 MAC&PHY operation and antenna data
Relationships
is created.
150 ITU-T Rec. G.983.2 (07/2005)

Attributes
dot11MACAddress: Unique MAC Address assigned to the STA. (R) (mandatory) (6 bytes)
dot11RTSThreshold: This attribute shall indicate the number of octets in an MPDU, below
which an RTS/CTS handshake shall not be performed. An RTS/CTS handshake shall be
performed at the beginning of any frame exchange sequence where the PDU is of type Data or
Management, the MPDU has an individual address in the address1 field, and the length of the
MPDU is greater than this threshold. Setting this attribute to be larger than the maximum MSDU
size shall have the effect of turning off the RTS/CTS handshake for frames of Data or
Management type transmitted by this STA. Setting this attribute to zero shall have the effect of
turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by
this STA. The default value of this attribute shall be 2347. (R, W) (mandatory) (2 bytes)
dot11ShortRetryLimit: This attribute shall indicate the maximum number of transmission
attempts of a frame, the length of which is less than or equal to dot11RTSThreshold, that shall be
made before a failure condition is indicated. The default value of this attribute shall be 7. (R, W)
dot11LongRetryLimit: This attribute shall indicate the maximum number of transmission
attempts of a frame, the length of which is greater than dot11RTSThreshold, that shall be made
before a failure condition is indicated. The default value of this attribute shall be 4. (R, W)
dot11FragmentationThreshold: This attribute shall specify the current maximum size, in
octets, of the MPDU that may be delivered to the PHY. An MSDU shall be broken into
fragments if its size exceeds the value if this attribute after adding MAC headers and trailers. An
MSDU or MMPDU shall be fragmented when the resulting frame has an individual address in
the Address1 field, and the length of the frame is larger than this threshold. The default value for
this attribute shall be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and shall
never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of
this attribute shall never be less than 256. (R, W) (mandatory) (2 bytes)
dot11MaxTransmitMSDULifetime: The MaxTransmitMSDULifetime shall be the elapsed
time in TU, after the initial transmission of an MSDU, after which further attempts to transmit
the MSDU shall be terminated. The default value of this attribute shall be 512. (R, W)
dot11MaxReceiveLifetime: The MaxReceiveLifetime shall be the elapsed time in TU, after the
initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble
the MMPDU or MSDU shall be terminated. The default value shall be 512. (R, W) (mandatory)
(4 bytes)
dot11PHYType: This is an 8-bit integer value that identifies the PHY type supported by the
attached PLCP and PMD. Currently defined values and their corresponding PHY types are:
FHSS 2.4 GHz = 0x01, DSSS 2.4 GHz = 0x02, IR Baseband = 0x03. (R) (mandatory) (1 byte)
dot11CurrentRegDomain: The current regulatory domain this instance of the PMD is
supporting. This object corresponds to one of the RegDomains listed in
dot11RegDomainsSupported. (R, W) (mandatory) (4 bytes)
dot11TempType: There are different operating temperature requirements dependent on the
anticipated environmental conditions. This attribute describes the current PHY's operating
temperature range capability. Currently defined values and their corresponding temperature
ITU-T Rec. G.983.2 (07/2005) 151

ranges are: Type 1 = 0x01: Commercial range of 0 to 40 degrees C, Type 2 = 0x02: Industrial
range of –30 to 70 degrees C. (R) (mandatory) (1 byte)
dot11CurrentTxAntennaPointer: The current antenna being used to transmit. This value is one
of the values appearing in the dot11SupportedTxAntenna attribute of a General Purpose Object
ME instance of ObjectType = 3. This may be used by a management agent to control which
antenna is used for transmission. The value 0x0000 is interpreted as a Null pointer. (R, W)
dot11DiversitySupport: This implementation's support for diversity, encoded as: 0x01:
diversity is available and is performed over the fixed list of antennas defined by the
dot11DiversitySelectionRx attribute values of the set of General Purpose Object ME instances of
ObjectType = 3. 0x02: diversity is not supported. 0x03: diversity is supported and control of
diversity is also available, in which case the attribute dot11DiversitySelectionRx can be
dynamically modified by the LME. (R) (mandatory) (1 byte)
dot11CurrentRxAntennaPointer: The current antenna being used to receive, if the
dot11DiversitySupport indicates that diversity is not supported. The selected antenna shall be
one of the antennae marked for receive via the dot11SupportedRxAntenna attribute of a General
Purpose Object ME instance of ObjectType = 3. The value 0x0000 is interpreted as a Null
pointer. (R, W) (mandatory) (2 bytes)
dot11CurrentTxPowerLevel: The TxPowerLevel currently being used to transmit data. Some
PHYs also use this value to determine the receiver sensitivity requirements for CCA. Valid
values range from 0 to 7 and indicate which word in the dot11TxPowerLevels attribute of the
Physical Path Termination Point 802.11 UNI object shall be the current power level. (R, W)
Actions
Notifications
None.
7.3.61 802.11 counters
Relationships
One instance of this managed entity may exist for each instance of an IEEE 802.11 interface. An
instance of this managed entity is created/deleted by the OLT after an instance of a Physical Path
Termination Point 802.11 UNI managed entity is created/deleted.
Attributes
cyclic counter (modulo 0x0100 (256)) that is incremented each time a new interval is finished
and the attribute counters are updated. The value of this attribute is 0x00 during the first
15-minute interval that starts with the reception of the "synchronize time" action. The value is
0x01 during the first period after this, and so on. If this managed entity is created after the
reception of the "synchronize time" action, the value of this attribute is set equal to the number of
152 ITU-T Rec. G.983.2 (07/2005)

the last completed interval. The actual counters of this managed entity start counting directly.
The attribute counters are updated at the end of the interval. (R) (mandatory) (1 byte)
Threshold DataB-PON id: This attribute provides a pointer to an instance of the Threshold Data
managed entity that contains the threshold values for the performance monitoring data collected
by this managed entity. The value 0x0000 is interpreted as a Null pointer. (R, W, Set-by-create)
dot11TransmittedFragmentCount: This counter shall be incremented for an acknowledged
MPDU with an individual address in the address 1 field or an MPDU with a multicast address in
the address 1 field of type Data or Management. If the actual counter saturates, it remains on its
dot11MulticastTransmittedFrame Count: This counter shall increment only when the
multicast bit is set in the destination MAC address of a successfully transmitted MSDU. When
operating as a STA in an ESS, where these frames are directed to the AP, this implies having
received an acknowledgment to all associated MPDUs. If the actual counter saturates, it remains
on its maximum value. Default value is 0x00. (R) (mandatory) (4 bytes)
dot11FailedCount: This counter shall increment when an MSDU is not transmitted successfully
due to the number of transmit attempts exceeding either the dot11ShortRetryLimit or
dot11LongRetryLimit (specified in the corresponding attributes of the associated 802.11
MAC&PHY Operation and Antenna Data managed entity). If the actual counter saturates, it
dot11RetryCount: This counter shall increment when an MSDU is successfully transmitted
after one or more retransmissions. If the actual counter saturates, it remains on its maximum
value. Default value is 0x00. (R) (mandatory) (4 bytes)
dot11MultipleRetryCount: This counter shall increment when an MSDU is successfully
transmitted after more than one retransmission. If the actual counter saturates, it remains on its
dot11FrameDuplicateCount: This counter shall increment when a frame is received that the
Sequence Control field indicates is a duplicate. If the actual counter saturates, it remains on its
dot11RTSSuccessCount: This counter shall increment when a CTS is received in response to an
RTS. If the actual counter saturates, it remains on its maximum value. Default value is 0x00. (R)
dot11RTSFailureCount: This counter shall increment when a CTS is not received in response
to an RTS. If the actual counter saturates, it remains on its maximum value. Default value is
dot11ACKFailureCount: This counter shall increment when an ACK is not received when
expected. If the actual counter saturates, it remains on its maximum value. Default value is 0x00.
dot11ReceivedFragmentCount: This counter shall be incremented for each successfully
received MPDU of type Data or Management. If the actual counter saturates, it remains on its
dot11MulticastReceivedFrameCount: This counter shall increment when a MSDU is received
with the multicast bit set in the destination MAC address. If the actual counter saturates, it
dot11FCSErrorCount: This counter shall increment when an FCS error is detected in a
received MPDU. If the actual counter saturates, it remains on its maximum value. Default value
ITU-T Rec. G.983.2 (07/2005) 153

dot11TransmittedFrameCount: This counter shall increment for each successfully transmitted
MSDU. If the actual counter saturates, it remains on its maximum value. Default value is 0x00.
dot11WEPUndecryptableCount: This counter shall increment when a frame is received with
the WEP subfield of the Frame Control field set to one and the WEPOn value for the key
mapped to the TA's MAC address indicates that the frame should not have been encrypted or that
frame is discarded due to the receiving STA not implementing the privacy option. If the actual
(4 bytes)
Actions
Get current data: This action returns the current value of one or more actual counters associated
with performance monitoring attributes and the value of the Interval End Time attribute
representing the interval in which the request is made. The values in the specific counters are
reset at the end of the interval. Support of this action is optional.
Notifications
will be sent at the crossing of the threshold by the actual counter; the TCA change notification "off"
will be sent at the end of the 15-min period since that is when the actual counters are reset to 0x00.
The event list for this entity is given in Table 18.
Table 18/G.983.2 − Alarm list for 802.11 counters (reproduced from Table 4/G.983.9)
Threshold data
counter # (Note)
Threshold crossing alert
0 dot11Failed MSDU transmit failure threshold 1
crossing
1 dot11RTSFailure RTS failure count threshold crossing 2
2 dot11ACKFailure ACK failure count threshold crossing 3
3 dot11FCSError FCS error count threshold crossing 4
4 dot11WEPUndecryptable WEP undecryptable count threshold 5
crossing
5-223 Reserved
NOTE – This numbering is used with the associated Threshold Data managed entity. Threshold Data
counter 1 indicates the 1st thresholded counter that is associated with the Threshold Value 1 attribute of
the Threshold DataB-PON managed entity.
154 ITU-T Rec. G.983.2 (07/2005)

7.3.62 802.11 PHY FHSS DSSS IR tables
Relationships
One instance of this managed entity may exist for each instance of an IEEE 802.11 interface. The
ONU automatically creates an instance of this entity whenever a PPTP 802.11 UNI instance is
created.
Attributes
dot11HopTime: The time in microseconds for the PMD to change from channel 2 to channel 80.
dot11CurrentChannelNumber: The current channel number of the frequency output by the
RF synthesizer. (R, W) (mandatory) (1 byte)
dot11MaxDwellTime: The maximum time in TU that the transmitter is permitted to operate on
a single channel. (R) (mandatory) (2 bytes)
dot11CurrentDwellTime: The current time in TU that the transmitter shall operate on a single
channel, as set by the MAC. Default is 19 TU. (R, W) (mandatory) (2 bytes)
dot11CurrentSet: The current set of patterns the PHY LME is using to determine the hopping
sequence. (R, W) (mandatory) (1 byte)
dot11CurrentPattern: The current pattern the PHY LME is using to determine the hop
sequence. (R, W) (mandatory) (1 byte)
dot11CurrentIndex: The current index value the PHY LME is using to determine the
CurrentChannelNumber. (R, W) (mandatory) (1 byte)
dot11CurrentChannel: The current operating frequency channel of the DSSS PHY. Valid
channel numbers are as defined in [B-13] Section 15.4.6.2. (R, W) (mandatory) (1 byte)
dot11CCAModeSupported: dot11CCAModeSupported is a bit-significant value, representing
all of the CCA modes supported by the PHY. Valid values are: energy detect only (ED_ONLY)
= 0x01, carrier sense only (CS_ONLY) = 0x02, carrier sense and energy detect (ED_and_CS)
= 0x04 or the logical sum of any of these values. (R) (mandatory) (1 byte)
dot11CurrentCCAMode: The current CCA method in operation. Valid values are: energy
detect only (edonly) = 0x01, carrier sense only (csonly) = 0x02, carrier sense and energy detect
(edandcs)= 0x04. (R, W) (mandatory) (1 byte)
dot11EDThreshold: The current Energy Detect Threshold being used by the DSSS PHY.
dot11CCAWatchdogTimerMax: This parameter, together with CCAWatchdogCountMax,
determines when energy detected in the channel can be ignored. Units are in time ticks. (R, W)
dot11CCAWatchdogCountMax: This parameter, together with CCAWatchdogTimerMax,
determines when energy detected in the channel can be ignored. Units are in time ticks. (R, W)
dot11CCAWatchdogTimerMin: The minimum value to which CCAWatchdogTimerMax can
be set. Units are in time ticks. (R, W) (mandatory) (4 bytes)
dot11CCAWatchdogCountMin: The minimum value to which CCAWatchdogCount can be
set. Units are in time ticks. (R, W) (mandatory) (4 bytes)
ITU-T Rec. G.983.2 (07/2005) 155

Actions
Notifications
None.
7.3.63 Physical path termination point ADSL UNI part 1
This managed entity represents the point at an ATM UNI in the ONU where physical paths
terminate to an ADSL CO Modem.
One or more instances of this managed entity shall be automatically created/deleted by the ONU
upon the creation/deletion of a Subscriber Line Card of ADSL type.
Establishment of a "Physical Path Termination Point ADSL UNI"
The Physical Path Termination Point ADSL UNI is auto created when the Subscriber Line Card of
type ADSL is created. On auto creation, the 5 profile pointers within the Managed Entity are set to
their default values of 0x00. However, the PPTP ADSL UNI Part 1 must refer to 5 valid profiles
before it can be operational.
Relationships
Line Card managed entity classified as ADSL type.
Attributes
Managed Entity ID: This attribute provides a unique number for each instance of this managed
byte is the slot ID (defined in 7.1.3). The second byte is the port ID with a value range from 0x01
interface. Value 0x00: no loopback; value 0x01: loopback2 ("Loopback2") refers to a loopback
at the ONU to the OLT. The OLT can execute a physical level loopback test after loopback2 is
set. Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
ADSL Line Configuration Profile: This attribute contains the Managed Entity ID of the ADSL
Line Configuration Profiles (parts 1, 2, and 3) managed entities that contains the data necessary
for initializing an ADSL MODEM. The value 0x00 is used to indicate that this ME does not
point to an ADSL Line Configuration Profile. The value 0x00 is the default value, which is set
when this ME is auto-created. (R, W) (mandatory) (2 bytes)
156 ITU-T Rec. G.983.2 (07/2005)

ADSL Subcarrier Masking Downstream Profile: This attribute provides a pointer to an
instance of the ADSL Subcarrier Masking Downstream Profile managed entity that contains the
data necessary for initializing an ADSL MODEM. The value 0x00 is used to indicate that this
ME does not point to an ADSL Subcarrier Masking Downstream Profile. The value 0x00 is the
default value, which is set when this ME is auto-created. (R, W) (mandatory) (2 bytes)
ADSL Subcarrier Masking Upstream Profile: This attribute provides a pointer to an instance
of the ADSL Subcarrier Masking Upstream Profile managed entity that contains the data
necessary for initializing an ADSL MODEM. The value 0x00 is used to indicate that this ME does
not point to an ADSL Subcarrier Masking Upstream Profile. The value 0x00 is the default value,
which is set when this ME is auto-created. (R, W) (mandatory) (2 bytes)
ADSL Downstream PSD Mask Profile: This attribute provides a pointer to an instance of the
ADSL Downstream PSD Mask Profile managed entity that contains the data necessary for
initializing an ADSL MODEM. The value 0x00 is used to indicate that this ME does not point to
an ADSL Downstream PSD Mask Profile. The value 0x00 is the default value, which is set when
this ME is auto-created. (R, W) (mandatory) (2 bytes)
ADSL Downstream RFI Bands Profile: This attribute provides a pointer to an instance of the
ADSL Downstream RFI Bands Profile managed entity that contains the data necessary for
initializing an ADSL MODEM. The value 0x00 is used to indicate that this ME does not point to
an ADSL Downstream RFI Bands Profile. The value 0x00 is the default value, which is set when
this ME is auto-created. (R, W) (mandatory) (2 bytes)
Actions
Notifications
this managed entity are given in Table 19.
Table 19/G.983.2 – AVC list for physical path termination point ADSL UNI
Number AVC Description
1-2 N/A
4-10 N/A
11-16 Reserved
detected or cleared. Both ONU and OLT should know the alarm list used by this entity. The
alarms for this entity are given in Table 20.
ITU-T Rec. G.983.2 (07/2005) 157

Table 20/G.983.2 – Alarm list for physical path termination point ADSL UNI
Alarm
0 NE_LOF Near End Loss of Frame
1 NE_LOS Near End Loss of Signal
2 NE_LOL Near End Loss of Link
3 NE_LPR Near End Loss of Power
4 CARD_ALM Card in Alarm
5 FE_LOF Far End Loss of Frame
6 FE_LOS Far End Loss of Signal
7 FE_LOL Far End Loss of Link
8 FE_LPR Far End Loss of Power
9 DRT_UP Data Rate Threshold Up-shift alarm
10 DRT_DOWN Data Rate Threshold Down-shift alarm
11-223 reserved
7.3.64 Physical path termination point ADSL UNI part 2

This managed entity represents the point at an ATM UNI in the ONU where physical paths
terminate to an ADSL CO Modem.
Establishment of a "Physical Path Termination Point ADSL UNI"
The Physical Path Termination Point ADSL UNI is auto created when the Subscriber Line Card of
type ADSL is created. On auto creation the 8 profile pointers within the Managed Entity are set to
their default values of 0x00. However, the PPTP ADSL UNI Part 2 must refer to at least 2 valid
profiles before it can be operational.
Relationships
One or more instances of this managed entity shall be contained in an instance of a Subscriber Line
Card managed entity classified as ADSL type.
Attributes
ADSL Channel Configuration Profile (For Bearer Channel 0 Downstream): This attribute
provides a pointer to an instance of the ADSL Channel Configuration Profile managed entity for
Bearer Channel 0 Downstream that contains the data necessary for initializing an ADSL
MODEM. The value 0x00 is used to indicate that this ME does not point to an ADSL Channel
Configuration Profile. The value 0x00 is the default value, which is set when this ME is auto
created. (R, W) (optional) (2 bytes)
158 ITU-T Rec. G.983.2 (07/2005)

ADSL Channel Configuration Profile (For Bearer Channel 0 Upstream): This attribute
Bearer Channel 0 Upstream that contains the data necessary for initializing an ADSL MODEM.
The value 0x00 is used to indicate that this ME does not point to an ADSL Channel
Actions
Actions
None.
ITU-T Rec. G.983.2 (07/2005) 159

7.3.65 ADSL line inventory and status data part 1
This managed entity contains Part 1 of the Line Inventory and Status Data for an ADSL line. One or
more instances of this managed entity shall be automatically created/deleted by the ONU upon the
creation/deletion of a Subscriber Line Card of ADSL type.
Relationships
Line Card managed entity classified as ADSL type. All attributes other than Managed Entity ID
will default to zero.
Attributes
entity. The assigned number is the same as the ID of the Physical Path Termination Point ADSL
UNI with which this ADSL Line Inventory Data is associated. (R) (mandatory) (2 bytes)
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.
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 (R) (mandatory) (8 bytes)
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 (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. (R) (mandatory) (8 bytes)
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 (ITU-T Recs 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. (R) (mandatory) (8 bytes)
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. (R) (mandatory)
(16 bytes)
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. (R) (mandatory) (16 bytes)
ATU-C Serial Number Part 1: The ATU-C serial number is the serial number as inserted by
the ATU-C in the 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. This attribute contains the first
16 characters. (R) (mandatory) (16 bytes)
ATU-C Serial Number Part 2: The ATU-C serial number is the serial number as inserted by
the ATU-C in the 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. This attribute contains the second 16
characters. (R) (mandatory) (16 bytes)
ATU-R Serial Number Part 1: 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
160 ITU-T Rec. G.983.2 (07/2005)

consists of up to 32 ASCII characters. This attribute contains the first 16 characters. (R)
ATU-R Serial Number Part 2: 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. This attribute contains the second 16 characters.
ATU-C Self Test Results: 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 ITU-T Rec. G.994.1 and system Vendor IDs. (R) (mandatory)
(4 bytes)
ATU-R Self Test Results: 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 ITU-T Rec. G.994.1 and system Vendor IDs. (R) (mandatory)
(4 bytes)
ATU-C Transmission System Capability: 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 Table 21. (R) (mandatory) (7 bytes)
ATU-R Transmission System Capability: 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 Table 21. (R) (mandatory) (7 bytes)
Initialization – Success/Failure Cause: This parameter represents the success or 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 e.g., 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.
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.
ITU-T Rec. G.983.2 (07/2005) 161

Actions
Notifications
None.
The following is an explanation of the ATU Transmission System Capability Attributes in the
ADSL Managed entity. It is coded in a bit-map representation (0 if not allowed, 1 if allowed) with
following definition:
Table 21/G.983.2 – ATU transmission system table (reproduced from Table 4/G.983.10)
Bit Representation
Octet 1
1 ANSI T1.413
2 Annex C of TS 101 388 v1.3.1
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
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
23 Reserved
24 Reserved
162 ITU-T Rec. G.983.2 (07/2005)

Bit Representation
Octet 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
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
45 Reserved
46 Reserved
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)
53 Reserved
ITU-T Rec. G.983.2 (07/2005) 163

Bit Representation
54 Reserved
55 Reserved
56 Reserved
7.3.66 ADSL line inventory and status data part 2

This managed entity contains Part 2 of the Line Inventory and Status Data for an ADSL line. One or
more instances of this managed entity shall be automatically created/deleted by the ONU upon the
creation/deletion of a Subscriber Line Card of ADSL type.
Relationships
Attributes
UNI with which this ATU-R Physical Data is associated. (R) (mandatory) (2 bytes)
ADSL Transmission System: This parameter defines the transmission system in use. It is coded
in bitmap representation with the bits defined in Table 21. (R) (mandatory) (7 bytes)
Line Power Management State: The Line has four possible power management states,
numbered 0 to 3 and corresponding to respectively:
0 = L0 – Synchronized – This Line state (L0) is when the Line has full transmission
(i.e., showtime).
1 = 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 ITU-T
Rec. G.992.2 only.
2 = 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 ITU-T
Recs G.992.3 and G.992.4 only.
3 = L3 – No-power – This Line state (L3) is when there is No Power transmitted on the
line at all.
Downstream Line Attenuation: 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 (0) to +127
(1270) dB with 0.1 dB steps. A special value (0xFFFF) indicates the line attenuation is out of
range to be represented. (R) (mandatory) (2 bytes)
Upstream Line Attenuation: 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 (0) to +127
(1270) dB with 0.1 dB steps. A special value (0xFFFF) indicates the line attenuation is out of
164 ITU-T Rec. G.983.2 (07/2005)

Downstream Signal Attenuation: 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 (0) to +127 (1270) dB with 0.1 dB
steps. A special value (0xFFFF) indicates the line attenuation is out of range to be represented.
Upstream Signal Attenuation: 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 attenuation ranges from 0 (0) to +127 (1270) dB with
0.1 dB steps. A special value (0xFFFF) indicates the line attenuation is out of range to be
represented. (R) (mandatory) (2 bytes)
Downstream Signal-to-Noise Ratio Margin: 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 (0) dB to +63 (1280) dB with 0.1 dB steps. A special value (0xFFFF) indicates the
parameter is out of range to be represented. (R) (mandatory) (2 bytes)
Upstream Signal-to-Noise Ratio Margin: 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 (0) dB to +63 (1280) dB with 0.1 dB steps. A special value (0xFFFF) indicates the
parameter is out of range to be represented. (R) (mandatory) (2 bytes)
Downstream Maximum Attainable Data Rate: 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. (R) (mandatory) (4 bytes)
Upstream Maximum Attainable Data Rate: 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. (R) (mandatory) (4 bytes)
Downstream Actual Power Spectrum Density: 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 (0) dBm/Hz to 0
(900) dBm/Hz with 0.1 dB steps. A special value (0xFFFF) indicates the parameter is out of
Upstream Actual Power Spectrum Density: 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 (0) dBm/Hz to 0 (900) dBm/Hz with 0.1 dB steps.
A special value (0xFFFF) indicates the parameter is out of range to be represented. (R)
Downstream Actual Aggregate Transmit Power: 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 (0) dBm to +31 (620) dBm with 0.1
dB steps. A special value (0xFFFF) indicates the parameter is out of range to be represented.
NOTE – The downstream nominal aggregate transmit power may be taken as a best estimate of the
parameter.
Upstream Actual Aggregate Transmit Power: 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
ITU-T Rec. G.983.2 (07/2005) 165

total output power level ranges from –31 (0) dBm to +31 (620) dBm with 0.1 dB steps. A special
value (0xFFFF) 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.
Initialization – Last State Transmitted Downstream: 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 ITU-T Rec. G.994.1 is used) or 1 (if ITU-T Rec. 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. (R) (mandatory) (1 byte)
Initialization – Last State Transmitted Upstream: 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 ITU-T Rec. G.994.1 is used) or 1 (if ITU-T Rec. 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. (R) (mandatory) (1 byte)
Actions
Notifications
None.
7.3.67 ADSL channel downstream status data
This managed entity contains the ADSL Channel Downstream Status Data. One or more instances
of this managed entity shall be automatically created/deleted by the ONU upon the creation/deletion
of a Subscriber Line Card of ADSL type.
Relationships
Attributes
entity. This 2-byte number is directly associated with the physical position of the UNI. The two
most significant bits of the first byte is the Bearer Channel ID. The six least significant bits of the
first byte is the slot ID (defined in 7.1.3). The second byte is the port ID with a value range from
0x01 to 0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card, 0x02
is used for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
Actual Interleaving Delay: This parameter is the actual one-way interleaving delay introduced
by the PMS-TC between the alpha 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
166 ITU-T Rec. G.983.2 (07/2005)

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. 0-255 ms.
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. (R) (mandatory) (4 bytes)
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. (R) (mandatory) (4 bytes)
Actions
Notifications
None.
7.3.68 ADSL channel upstream status data
This managed entity contains the ADSL Channel Upstream Status Data.
Relationships
Attributes
most significant bits of the first byte is the Bearer Channel ID. The six least significant bits of the
first byte is the slot ID (defined in 7.1.3). The second byte is the port ID with a value range from
0x01 to 0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card, 0x02
is used for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
Actual Interleaving Delay: This parameter is the actual one-way interleaving delay introduced
by the PMS-TC between the alpha 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). (R) (mandatory)
(1 byte)
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. (R) (mandatory) (4 bytes)
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,
ITU-T Rec. G.983.2 (07/2005) 167

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. (R) (mandatory) (4 bytes)
Actions
Notifications
None.
7.3.69 ADSL line configuration profile part 1
This managed entity contains part 1 of the Line Configuration Profile for an ADSL line. An
instance of this managed entity is created/deleted on request of the OLT.
Relationships
Zero or more instances of this managed entity shall exist and may be associated with zero or
more instances of the Physical Path Termination Point ADSL UNI.
Attributes
entity. The value 0x00 is reserved. (R, Set-by-create) (mandatory) (2 bytes)
ATU Transmission System Enabling: 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 with the bits defined in Table 21.
(R, W, Set-by-create) (mandatory) (7 bytes)
Power Management State Forced: 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 an 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.
Power Management State Enabling: 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).
168 ITU-T Rec. G.983.2 (07/2005)

Downstream Target Noise Margin: 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 (0) to 31 (310) dB
with 0.1 dB steps. (R, W, Set-by-create) (mandatory) (2 bytes)
Upstream Target Noise Margin: 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 (0) to 31 (310) dB
with 0.1 dB steps. (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream Maximum Noise Margin: 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). The maximum noise margin ranges from 0 (0) to 31 (310) dB with 0.1 dB steps. A
special value of 0xFFFF is used to indicate that no Maximum Noise Margin limit is to be
applied. (R, W, Set-by-create) (mandatory) (2 bytes)
Upstream Maximum Noise Margin: 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). The maximum noise margin ranges from 0 (0) to 31 (310) dB with
0.1 dB steps. A special value of 0xFFFF is used to indicate that no Maximum Noise Margin limit
is to be applied. (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream Minimum Noise Margin: 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 (0) to 31 (310) dB with 0.1 dB
steps. (R, W, Set-by-create) (mandatory) (2 bytes)
Upstream Minimum Noise Margin: 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 (0) to 31 (310) dB with 0.1 dB
steps. (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream Rate Adaptation Mode: This parameter specifies the mode of operation of a
rate-adaptive ATU-C in the transmit direction. The parameter can take three values.
1 = 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.
At showtime
The ATU-C transmitter shall maintain the specified Downstream Minimum Data Rate
for each of the bearer channels.
ITU-T Rec. G.983.2 (07/2005) 169

2 = 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 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 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.
3 = 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. (R, W, Set-by-create) (mandatory) (1 byte)
170 ITU-T Rec. G.983.2 (07/2005)

Upstream Rate Adaptation Mode: 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:
1 = MANUAL
2 = AT_INIT
3 = 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).
Downstream Up-shift Noise Margin: 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 Up-shift Noise Margin ranges from 0 (0) to 31 (310) dB with
0.1 dB steps. (R, W, Set-by-create) (optional) (2 bytes)
Upstream Up-shift Noise Margin: If the upstream noise margin is above the Upstream Up-shift
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 Up-shift Noise Margin ranges from 0 (0) to 31 (310) dB with 0.1 dB steps. (R, W,
Set-by-create) (optional) (2 bytes)
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 Annex J of ITU-T Annex M of ITU-T
mask selection value Rec. G.992.3/5 Rec. G.992.3/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

Minimum Overhead Rate Upstream: This attribute defines the minimum rate of the
message-based overhead that shall be maintained by the ATU in upstream direction. MSGMINus
is expressed in bits per second and ranges from 4000 to 64000 bit/s. This attribute is only valid
for ITU-T Recs G.992.3, G.992.4 and G.992.5. (R, W, Set-by-create) (optional) (2 bytes)
Minimum Overhead Rate Downstream: This attribute defines the minimum rate of the
message based overhead that shall be maintained by the ATU in downstream direction.
MSGMINds is expressed in bits per second and ranges from 4000 to 64000 bit/s. This attribute is
ITU-T Rec. G.983.2 (07/2005) 171

only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. (R, W, Set-by-create) (optional)
(2 bytes)
Actions
Notifications
None.
Relationships
Zero or more instances of this managed entity shall exist and may be associated with zero or more
instances of the Physical Path Termination Point ADSL UNI.
Attributes
Downstream Minimum Time Interval for Up-shift Rate Adaptation: This parameter defines
the interval of time the downstream noise margin should stay above the Downstream Up-shift
Noise Margin before the ATU-R shall attempt to increase the downstream net data rate. The time
interval ranges from 0 to 16 383 s. (R, W, Set-by-create) (optional) (2 bytes)
Upstream Minimum Time Interval for Up-shift Rate Adaptation: This parameter defines the
interval of time the upstream noise margin should stay above the Upstream Up-shift Noise
Margin before the ATU-C shall attempt to increase the upstream net data rate. The time interval
ranges from 0 to 16 383 s. (R, W, Set-by-create) (optional) (2 bytes)
Downstream Down-shift Noise Margin: If the downstream noise margin is below the
Downstream Down-shift 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 Down-shift Noise Margin ranges from
0 (0) to 31 (310) dB with 0.1 dB steps. (R, W, Set-by-create) (optional) (2 bytes)
Upstream Down-shift Noise Margin: If the upstream noise margin is below the Upstream
Down-shift 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 Down-shift Noise Margin ranges from 0 (0) to 31 (310) dB
with 0.1 dB steps. (R, W, Set-by-create) (optional) (2 bytes)
Downstream Minimum Time Interval for Downshift Rate Adaptation: This parameter
defines the interval of time the downstream noise margin should stay below the Downstream
Down-shift Noise Margin before the ATU-R shall attempt to decrease the downstream net data
rate. The time interval ranges from 0 to 16 383 s. (R, W, Set-by-create) (optional) (2 bytes)
Upstream Minimum Time Interval for Downshift Rate Adaptation: This parameter defines
the interval of time the upstream noise margin should stay below the Upstream Downshift Noise
172 ITU-T Rec. G.983.2 (07/2005)

Margin before the ATU-C shall attempt to decrease the upstream net data rate. The time interval
ranges from 0 to 16 383 s. (R, W, Set-by-create) (optional) (2 bytes)
ATU Impedance State forced: 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 only valid
for Annex A/G.992.3, Annex A/G.992.4 and Annex A/G.992.5. 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.
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 is only valid for ITU-T Recs G.992.3, G.992.4
and G.992.5. It ranges from 0 to 255 s. (R, W, Set-by-create) (mandatory) (1 byte)
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 is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It ranges from 0 to
255 s. (R, W, Set-by-create) (mandatory) (1 byte)
Downstream Maximum Nominal Power Spectral Density: 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 is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It
ranges from –60 (0) to –30 (900) dBm/Hz, with 0.1 dB steps. (R, W, Set-by-create) (mandatory)
(2 bytes)
Upstream Maximum Nominal Power Spectral Density: 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 is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It ranges
from –60 (0) to –30 (900) dBm/Hz, with 0.1 dB steps. (R, W, Set-by-create) (mandatory)
(2 bytes)
Downstream Maximum Nominal Aggregate Transmit Power: This parameter represents the
maximum nominal aggregate transmit power in the downstream direction during initialization
and showtime (in dBm). It is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It ranges
from 0 (0) to 25.5 (255) dBm, with 0.1 dB steps. (R, W, Set-by-create) (mandatory) (1 byte)
Upstream Maximum Nominal Aggregate Transmit Power: This parameter represents the
maximum nominal aggregate transmit power in the upstream direction during initialization and
showtime (in dBm). It is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It ranges
from 0 (0) to 25.5 (255) dBm, with 0.1 dB steps. (R, W, Set-by-create) (mandatory) (1 byte)
Upstream Maximum Aggregate Receive Power: 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 is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It ranges from –25.5 (0) to
25.5 (510) dBm, with 0.1 dB steps. A special value of 0xFFFF is used to indicate that no
Upstream Maximum Aggregate Receive Power limit is to be applied. (R, W Set-by-create)
ITU-T Rec. G.983.2 (07/2005) 173

Actions
Notifications
None.
Relationships
Attributes
Loop Diagnostics Mode Forced: 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 only valid for
ITU-T Recs G.992.3, G.992.4 and G.992.5. 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 before it can be forced to the loop diagnostics mode.
Only while the line power management state is the L3 state, 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 returns
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. 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. (R, W, Set-by-create) (mandatory) (1 byte)
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 ITU-T Rec. G.994.1), but depends also on achievable data rates
under given loop conditions. (R, W, Set-by-create) (mandatory) (1 byte)
174 ITU-T Rec. G.983.2 (07/2005)

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 is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5. It
ranges from 0 (0) dB to 31 (31) dB (R, W, Set-by-create) (mandatory) (1 byte)
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 (0) dB to 31 (31)dB. (R, W,
Actions
Notifications
None.
7.3.72 ADSL channel configuration profile
This managed entity contains the Channel Configuration Profile for an ADSL line. An instance of
this managed entity is created/deleted on request of the OLT.
Relationships
Attributes
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. (R, Set-by-create)
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.
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%.
Maximum Interleaving Delay: This parameter is the maximum one-way interleaving delay
introduced by the PMS-TC between the alpha 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.
ITU-T Rec. G.983.2 (07/2005) 175

The ATUs shall choose the S and D values such that the actual one-way interleaving delay 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 G.992.2, G.992.3 and G.992.4 operating modes. Value
range: 2-255. (R, Set-by-create) (mandatory) (1 byte)
Data Rate Threshold Up-shift: This parameter is a threshold on the net data rate up-shift
achieved over one or more bearer channel data rate adaptations. An up-shift 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. (R, Set-by-create)
Data Rate Threshold Down-shift: This parameter is a threshold on the net data rate down-shift
achieved over one or more bearer channel data rate adaptations. A down-shift 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. (R, Set-by-create)
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.
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. (R, Set-by-create)
Minimum Impulse Noise Protection: This parameter specifies the minimum impulse noise
protection for the bearer channel. It is only valid for ITU-T Recs G.992.3, G.992.4 and G.992.5.
The impulse noise protection is expressed in symbols and can take the following integer values:
1 = 0 symbol
2 = ½ symbol
3 = 1 symbol
4 = 2 symbol
Maximum Bit Error Ratio: This parameter specifies the maximum bit error ratio for the bearer
channel as desired by the operator of the system. It is only valid for ITU-T Recs G.992.3,
G.992.4 and G.992.5. The bit error ratio can take the following integer values:
1 = 1E-3
2 = 1E-5
3 = 1E-7
Actions
176 ITU-T Rec. G.983.2 (07/2005)

Notifications
None.
7.3.73 ADSL subcarrier masking downstream profile
This managed entity contains the Subcarrier Masking Downstream Profile for an ADSL line. An
Relationships
Zero or more instances of this managed entity shall exist and may be associated with zero or more
instances of the Physical Path Termination Point ADSL UNI.
Attributes
Downstream Subcarrier Mask1: This configuration parameter is a bitmap representing the
downstream mask values for subcarriers 1 to 128. The MSB of the first byte corresponds to
subcarrier 1, and the LSB of the last byte corresponds to subcarrier 128.
Each bit position defines whether the corresponding subcarrier is masked on this line in the
downstream direction. It is coded as 1 if masked and 0 if not masked (default).
Subcarrier number 1 is the lowest, and subcarrier number NSCds is the highest subcarrier that
can be transmitted in the downstream direction.
NOTE – For ITU-T Recs G.992.3 and G.992.4, the number of subcarrier downstream (NSCds) is defined
in the corresponding Recommendations. For ITU-T Rec. G.992.1, NSCds = 256, for ITU-T Rec. G.992.2,
NSCds = 128, and for ITU-T Rec. G.992.5, NSCds = 512.
subcarrier 129, and the LSB of the last byte corresponds to entry 256.
(R, W) (mandatory for modems that support NSCds > 128) (16 bytes)
subcarrier 257, and the LSB of the last byte corresponds to entry subcarrier 384.
ITU-T Rec. G.983.2 (07/2005) 177

subcarrier 385, and the LSB of the last byte corresponds to entry subcarrier 512.
TableValid: This boolean attribute controls and reports the operational status of this downstream
subcarrier mask attributes.
If this attribute is true (coded as 0x01), then the downstream subcarrier mask represented in this
ME has been impressed on the DSL equipment.
If this attribute is false (coded as 0x00), then the downstream subcarrier mask represented in this
ME has not been impressed on the DSL equipment. Default value is false.
The value of this attribute can be modified by the ONU and OLT, as follows:
If the OLT changes any of the four mask attributes or sets TableValid to false, then TableValid is
set to false.
If the TableValid is false and OLT sets TableValid to true, then the ONU will impress the
downstream subcarrier mask data to the DSL equipment.
Actions
Set: Set one or more attributes. Note that setting the mask attributes does not directly change the
DSL equipment operating mode, because of the TableValid attribute.
Notifications
None.
7.3.74 ADSL subcarrier masking upstream profile
This managed entity contains the Subcarrier Masking Upstream Profile for an ADSL line. An
Relationships
Attributes
Upstream Subcarrier Mask: This configuration parameter is a bitmap representing the
upstream mask values for subcarriers 1 to 64. The MSB of the first byte corresponds to
subcarrier 1, and the LSB of the last byte corresponds to subcarrier 64.
178 ITU-T Rec. G.983.2 (07/2005)

upstream direction. It is coded as 1 if masked and 0 if not masked (default).
Subcarrier number 1 is the lowest, and subcarrier number NSCus is the highest subcarrier that
can be transmitted in the upstream direction.
NOTE – For ITU-T Recs G.992.3 and G.992.4, the number of subcarrier upstream (NSCus) is defined in
the corresponding Recommendations. For Annex A/G.992.1 and ITU-T Rec. G.992.2, NSCus = 32, for
Annex B/G.992.1, NSCus = 64, and for ITU-T Rec. G.992.5, NSCus = 64.
Actions
Set: Set one or more attributes. Note that in this case, setting this attribute will result in the mask
information being impressed on the DSL equipment immediately.
Notifications
None.
7.3.75 ADSL downstream PSD mask profile
This managed entity contains the Downstream PSD Mask Profile for an ADSL line. An instance of
Relationships
Attributes
Downstream PSD Mask: This configuration parameter is a table where each entry consists of
an Entry Number (1 byte, first entry numbered 1) field, Subcarrier Index (2 bytes) field, and a
MIB PSD Mask Level (1 byte) field. This table 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 i (using the same definition of 'i' as given in 7.3.73)
and a MIB PSD mask level (expressed in dBm/Hz) at that subcarrier. The set of breakpoints can
then be represented as [(i1, PSD-1), (i2, PSD-2), ... , (iN, PSD-N)]. The MIB PSD Mask Level
field shall be coded as an unsigned integer representing the MIB PSD mask levels 0 (0) dBm/Hz
to –95 (190) dBm/Hz, in steps of 0.5 dBm/Hz. The maximum number of breakpoints is 32.
This attribute is only valid for ITU-T Rec. G.992.5.
The requirements for a valid set of breakpoints are defined in the relevant Recommendations
(e.g., ITU-T Rec. G.992.5). The entries will have default value of 0x00 for Subcarrier Index and
0x0 for MIB PSD Mask Level (i.e., no breakpoints). Table entries for this attribute are added or
modified using the Set action. Setting an entry with a non-zero Subcarrier Index and MIB PSD
Mask Level implies insertion into the table. Setting an entry's Subcarrier Index and MIB PSD
Mask Level to 0 implies deletion from the table, if present.
(R, W) (mandatory) (N × 4 bytes where N is the number of breakpoints)
ITU-T Rec. G.983.2 (07/2005) 179

TableValid: This boolean attribute controls and reports the operational status of this
Downstream PSD Mask attribute.
If this attribute is true (coded as 0x01), then the downstream PSD mask represented in this ME
has been impressed on the DSL equipment.
If this attribute is false (coded as 0x00), then the downstream PSD mask represented in this ME
has not been impressed on the DSL equipment. Default value is false.
If the OLT changes any of the PSD mask table entries or sets TableValid to false, then
TableValid is set to false.
downstream PSD mask data to the DSL equipment.
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current Downstream PSD
Mask and use 4 bytes to respond with the size of data which should be obtained using the "Get
next" command.
Downstream PSD Mask attribute, the Set action either adds, modifies, or deletes table entries in
Downstream PSD Mask. A maximum of 7 table entries can be added/modified/deleted by a
single Set action.
Notifications
None.
7.3.76 ADSL downstream RFI bands profile
This managed entity contains the Downstream RFI Bands Profile for an ADSL line. An instance of
Relationships
Attributes
Downstream RFI Bands: This configuration parameter is a table where each entry consists of
an Entry Number (1 byte, first entry numbered 1) field, Subcarrier Index1 (2 bytes) field, and
Subcarrier Index2 (2 bytes) field. The subcarrier indices are defined in 7.3.73. This table defines
the subset of downstream RFI Bands breakpoints, as specified in Downstream PSD Mask ME,
that shall be used to notch an RFI band. This subset consists of couples of consecutive subcarrier
indices belonging to breakpoints [i1;i2], corresponding to the low level of the notch. The
maximum number of RFI bands is 32. This attribute is only valid for ITU-T Rec. G.992.5.
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 the
Downstream PSD Mask ME as specified in the relevant Recommendations (e.g., ITU-T
Rec. G.992.5).
180 ITU-T Rec. G.983.2 (07/2005)

The entries will have default value of 0x00 for Subcarrier Index1 and Subcarrier Index2. Table
entries for this attribute are added or modified using the Set action. Setting an entry with a non-
zero Subcarrier Index1 and Subcarrier Index2 implies insertion into the table. Setting an
entry's Subcarrier Index1 and Subcarrier Index2 to 0 implies deletion from the table, if present.
(R, W) (mandatory) (N × 5 bytes where N is the number of RFI bands)
TableValid: This boolean attribute controls and reports the operational status of this
Downstream RFI Bands attribute.
If this attribute is true (coded as 0x01), then the downstream RFI bands represented in this ME
has been impressed on the DSL equipment.
If this attribute is false (coded as 0x00), then the downstream RFI bands represented in this ME
has not been impressed on the DSL equipment. Default value is false.
If the OLT changes any of the RFI bands table entries or sets TableValid to false, then
TableValid is set to false.
downstream RFI bands data to the DSL equipment.
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current Downstream
RFI Bands and use 4 bytes to respond with the size of data which should be obtained using the
"Get next" command.
Downstream RFI Bands attribute, the Set action either adds, modifies, or deletes table entries in
Downstream RFI Bands. A maximum of 6 table entries can be added/modified/deleted by a
single Set action.
Notifications
None.
7.3.77 ADSL ATU-C performance monitoring history data
This managed entity represents the last completed 15-minute interval collected performance
monitoring of the ATU-C – ATU-R ADSL modem path as seen from the ATU-C.
corresponding Physical Path Termination Point ADSL UNI managed entity is created/deleted.
Relationships
Point ADSL UNI.
Attributes
UNI with which this ATU-C Performance Monitoring History Data is associated. (R, W,
ITU-T Rec. G.983.2 (07/2005) 181

Interval End Time: This attribute identifies the most recently finished 15-minute interval. It is
a cyclic counter (modulo 0xFF (256)) that is incremented each time a new interval is finished
and the attribute counters are updated. The value of this attribute is 0x00 during the first
15-minute interval that starts with the reception of the "synchronize time" action. The value is
0x01 during the first period after this, and so on. If this managed entity is created after the
reception of the "synchronize time" action, the value of this attribute is set equal to the number of
the last completed interval. The actual counters of this managed entity start counting directly.
Threshold DataB-PON ID: This attribute provides a pointer to an instance of the Threshold
Loss of Frame Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Framing. (R) (mandatory) (2 bytes)
Loss of Signal Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Signal. (R) (mandatory) (2 bytes)
Loss of Link Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Link. (R) (mandatory) (2 bytes)
Loss of Power Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Power. (R) (mandatory) (2 bytes)
Errored Seconds: This attribute is the count of Errored Seconds in the previous 15-minute
interval. (R) (mandatory) (2 bytes)
Severely Errored Seconds: This attribute is the count of Severely Errored Seconds in the
previous 15-minute interval. (R) (mandatory) (2 bytes)
Line Initializations: This attribute is the count of Line Initializations in the previous 15-minute
Failed Line Initializations: This attribute is a count of the total number of failed full
initializations in the previous 15-minute interval. (R) (mandatory) (2 bytes)
Short Initializations: This attribute is a count of the total number of fast retrains or short
initializations attempted on the line (successful and failed) in the previous 15-minute interval.
(R) (optional) (2 bytes)
Failed Short Initializations: This attribute is a count of the total number of failed fast retrains or
short initializations in the previous 15-minute interval. (R) (optional) (2 bytes)
FEC Seconds: This attribute is the count of seconds in the previous 15-minute interval when
there was a Forward Error Correction anomaly. (R) (mandatory) (2 bytes)
Unavailable Seconds: This attribute is the count of seconds in the previous 15-minute interval
the ATU-C was unavailable. (R) (mandatory) (2 bytes)
Actions
Get Current Data: Get the current value of one or more attributes.
182 ITU-T Rec. G.983.2 (07/2005)

Notifications
Table 22/G.983.2 – Alarm list for ADSL performance monitoring history data
Threshold data
counter number (Note)
0 Loss of Frame Seconds Loss of Frame Seconds threshold 1
crossing
1 Loss of Signal Seconds Loss of Signal Seconds threshold 2
crossing
2 Loss of Link Seconds Loss of Link Seconds threshold 3
crossing
3 Loss of Power Seconds Loss of Power seconds threshold 4
crossing
4 Errored Seconds Errored seconds threshold crossing 5
5 Severely Errored Seconds Severely Errored seconds threshold 6
crossing
6 Line Initializations Line Initializations threshold 7
crossing
7 Failed Line Initializations Failed Line Initializations threshold 8
crossing
8 Short Initializations Short Initializations threshold 9
crossing
9 Failed Short Initializations Failed Short Initializations 10
threshold crossing
10 FEC Seconds FEC Seconds threshold crossing 11
11 Unavailable Seconds Unavailable Seconds threshold 12
crossing
12-223 Reserved
7.3.78 ADSL ATU-R performance monitoring history data

monitoring of the ATU-C-ATU-R ADSL modem path as seen from the ATU-R.
ITU-T Rec. G.983.2 (07/2005) 183

Relationships
Point ADSL UNI.
Attributes
UNI with which this ATU-R Performance Monitoring History Data is associated.
completed interval. The actual counters of this managed entity start counting directly.
Loss of Frame Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Framing. (R) (mandatory) (2 bytes)
Loss of Signal Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Signal. (R) (mandatory) (2 bytes)
Loss of Power Seconds: This attribute is the count of seconds in the previous 15-minute interval
when there was Loss of Power. (R) (mandatory) (2 bytes)
Errored Seconds: This attribute is the count of Errored Seconds in the previous 15-minute
Severely Errored Seconds: This attribute is the count of Severely Errored Seconds in the
FEC Seconds: This attribute is the count of seconds in the previous 15-minute interval when
there was a Forward Error Correction anomaly. (R) (mandatory) (2 bytes)
Unavailable Seconds: This attribute is the count of seconds in the previous 15-minute interval
the ATU-R was unavailable. (R) (mandatory) (2 bytes)
Actions
184 ITU-T Rec. G.983.2 (07/2005)

Notifications
Table 23/G.983.2 – Alarm list for ATU-R performance monitoring history data
(Reproduced from Table 6/G.983.10)
Threshold Data
Number Event Description Counter Number
(Note)
0 Loss of Frame Seconds Loss of Frame Seconds threshold 1
crossing
1 Loss of Signal Seconds Loss of Signal Seconds threshold 2
crossing
2 Loss of Power Seconds Loss of Power seconds threshold 3
crossing
3 Errored Seconds Errored seconds threshold crossing 4
4 Severely Errored Seconds Severely Errored seconds threshold 5
crossing
5 FEC Seconds FEC Seconds threshold crossing 6
6 Unavailable Seconds Unavailable Seconds threshold crossing 7
7-223 Reserved
7.3.79 ADSL ATU-C channel performance monitoring history data

monitoring of the ATU-C – ATU-R ADSL channel as seen from the ATU-C.
Relationships
Point ADSL UNI.
Attributes
most significant bits of the first byte are the Bearer Channel ID. The six least significant bits of
the first byte are the slot ID (defined in 7.1.3). The second byte is the port ID with a value range
from 0x01 to 0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card,
0x02 is used for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 185

Corrected blocks: This attribute is the count of all blocks received with errors that were
corrected on this channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Uncorrected Blocks: This attribute is the count of all blocks received with uncorrectable errors
on this channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Transmitted Blocks: This attribute is the count of all encoded blocks transmitted on this
channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Received Blocks: This attribute is the count of all encoded blocks received on this channel
within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Code Violations: This attribute is the count of CRC-8 anomalies in the bearer channel in the
Forward Error Corrections: This attribute is the count of FEC anomalies in the bearer channel
in the previous 15-minute interval. (R) (mandatory) (2 bytes)
Actions
Notifications
186 ITU-T Rec. G.983.2 (07/2005)

Table 24/G.983.2 – Alarm list for ATU-C channel performance monitoring history data
Threshold data counter
number (Note)
0 Corrected Blocks Corrected Blocks threshold crossing 1
1 Uncorrected Blocks Uncorrected Blocks threshold 2
crossing
2 Code Violations Code Violation threshold crossing 3
3 Forward Error Corrections FEC threshold crossing 4
4-223 Reserved
7.3.80 ADSL ATU-R channel performance monitoring history data

monitoring of the ATU-C – ATU-R ADSL channel as seen from the ATU-R.
Relationships
Point ADSL UNI.
Attributes
most significant bits of the first byte are the Bearer Channel ID. The six least significant bits of
the first byte are the slot ID (defined in 7.1.3). The second byte is the port ID with a value range
from 0x01 to 0xFF (1 to 255): 0x01 is used for the leftmost/lowest port on a subscriber line card,
0x02 is used for the next right/upper port, and so forth. (R) (mandatory) (2 bytes)
Corrected blocks: This attribute is the count of all blocks received with errors that were
corrected on this channel within the previous 15-minute interval. (R) ( mandatory) (4 bytes)
ITU-T Rec. G.983.2 (07/2005) 187

Uncorrected Blocks: This attribute is the count of all blocks received with uncorrectable errors
on this channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Transmitted Blocks: This attribute is the count of all encoded blocks transmitted on this
channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Received Blocks: This attribute is the count of all encoded blocks received on this channel
within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Code Violations: This attribute is the count of CRC-8 anomalies in the bearer channel in the
Forward Error Corrections: This attribute is the count of FEC anomalies in the bearer channel
in the previous 15-minute interval. (R) (mandatory) (2 bytes)
Actions
Notifications
Table 25/G.983.2 – Alarm list for ATU-R channel performance monitoring history data
Threshold Data
Counter Number (Note)
0 Corrected Blocks Corrected Blocks threshold crossing 1
1 Uncorrected Blocks Uncorrected Blocks threshold 2
crossing
2 Code Violations Code Violation threshold crossing 3
3 Forward Error Corrections FEC threshold crossing 4
4-223 Reserved
7.3.81 TC adaptor performance monitoring history data ADSL

monitoring of the ATU-C-ATU-R ATM Data Path.
188 ITU-T Rec. G.983.2 (07/2005)

Relationships
Point ADSL UNI.
Attributes
UNI with which this ATU-R Channel Performance Monitoring History Data is associated.
Near-end HEC violation count: 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.
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.
Near-end User total cell count: 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. (R) (mandatory) (4 bytes)
Near-end Idle Cell Bit Error Count: 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. (R) (mandatory) (2 bytes)
Far-end HEC violation count: 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.
Far-end delineated total cell count: 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. (R) (mandatory)
(4 bytes)
Far-end User total cell count: 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. (R) (mandatory) (4 bytes)
Far-end Idle Cell Bit Error Count: 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. (R) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 189

Actions
Notifications
Table 26/G.983.2 – Alarm list for TC adaptor performance monitoring history data ADSL
Threshold data
Number Event Description counter number
(Note)
0 Near-end HEC violation Near-end HEC violation count 1
threshold crossing
1 Near-end Idle Cell Bit Error Near-end Idle Cell Bit Error Count 2
Count threshold crossing
2 Far-end HEC violation count Far-end HEC violation count 3
threshold crossing
3 Far-end Idle Cell Bit Error Far-end Idle Cell Bit Error Count 4
Count threshold crossing
4-223 Reserved
7.3.82 Physical path termination point VDSL UNI

This managed entity represents the point at a VDSL connection in the ONU where physical paths
terminate and physical path level functions (e.g., path overhead functions) are performed.
Instances of this managed entity shall be automatically created/deleted by the ONU upon the
creation/deletion of a Subscriber Line Card of VDSL type.
If the Subscriber Line Card of VDSL type is a plug-in unit, the number of managed entities
automatically created is the maximum number supportable by the Subscriber Line Card slot. This
allows the creation of these managed entities before the unit is plugged-in.
Establishment of a "Physical Path Termination Point VDSL UNI"
The Physical Path Termination Point VDSL UNI is auto created when the Subscriber Line Card of
type VDSL is created. On auto creation the three profile pointers within the Managed Entity are set
to their default values of 0x00. However, the PPTP VDSL UNI must refer to three valid profiles
before it can be operational.
190 ITU-T Rec. G.983.2 (07/2005)

Relationships
Line Card managed entity classified as VDSL type.
Extensions for VDSL using Single Carrier Modulation (SCM) and Multiple Carrier Modulation
(MCM) are for further study.
Attributes
interface. Value 0x00: no loopback; value 0x01: loopback2 ("Loopback2" refers to a loopback at
the local VDSL modem). The OLT can execute a physical level loopback test after loopback is
set. Upon autonomous instantiation, the value 0x00 is used. (R, W) (mandatory) (1 byte)
Availability State: This attribute indicates whether the hardware to support this UNI is available
on the plugged in line card. Valid values are available(0), notAvailable(1), unknown(2).
VDSL Line Coding Type: This data type is used as the syntax for the VDSL Line Code.
Attributes with this syntax identify the line coding used. The three values are:
other(1) – none of the following;
mcm(2) – Multiple Carrier Modulation;
scm(3) – Single Carrier Modulation.
VDSL Line Type: Defines the type of VDSL physical line entity that exists, by defining
whether and how the line is channelized. If the line is channelized, the value will be other than
noChannel(1). This object defines which channel type(s) are supported. Defined values are:
noChannel(1) – no channels exist;
fastOnly(2) – only fast channel exists;
slowOnly(3) – only slow channel exists;
fastOrSlow(4) – either fast or slow channel exist, but only one at a time;
fastAndSlow(5) – both fast and slow channels exist.
ITU-T Rec. G.983.2 (07/2005) 191

VDSL Line Configuration Profile ID: This attribute provides a pointer to an instance of the
VDSL Line Configuration Profile managed entity that contains the data necessary for initializing
a VDSL MODEM. The value 0x00 is used to indicate that this ME does not point to a line
configuration profile. The default value 0x00 is used when this ME is auto created. (R, W)
VDSL Channel Configuration Profile ID: This attribute provides a pointer to an instance of
the VDSL Channel Configuration Profile managed entity that contains the data necessary for
channelizing a VDSL Connection. The value 0x00 is used to indicate that this ME does not point
to a channel configuration profile. The default value 0x00 is used when this ME is auto created.
VDSL Band Plan Configuration Profile ID: This attribute provides a pointer to an instance of
the VDSL Band Plan Configuration Profile managed entity that contains the data necessary to set
up a VDSL Connection. The value 0x00 is used to indicate that this ME does not point to band
plan configuration profile. The default value 0x00 is used when this ME is auto created. (R, W)
Actions
Notifications
this managed entity are given in Table 27.
Table 27/G.983.2 – AVC list for physical path termination point VDSL UNI
1-2 N/A
4-11 N/A
12-16 Reserved
detected or cleared. Both ONU and OLT should know the alarm list used by this entity. The
alarms for this entity are given in Table 28.
Table 28/G.983.2 – Alarm list for physical path termination point VDSL UNI
0 NE_LOF Near End (VTU-O) Loss of Framing
1 NE_LOS Near End (VTU-O) Loss of Signal
2 NE_LOP Near End (VTU-O) Loss of Power
3 NE_LOSQ Near End (VTU-O) Loss of Signal Quality
4 NE_LOL Near End (VTU-O) Loss of Link
5 FE_LOF Far End (VTU-R) Loss of Framing
192 ITU-T Rec. G.983.2 (07/2005)

Table 28/G.983.2 – Alarm list for physical path termination point VDSL UNI
6 FE_LOS Far End (VTU-R) Loss of Signal
7 FE_LOP Far End (VTU-R) Loss of Power
8 FE_LOSQ Far End (VTU-R) Loss of Signal Quality
9-223 Reserved
7.3.83 VDSL VTU-O physical data

This managed entity represents the physical status of the VDSL Termination Unit (ONU) (VTU-O)
in a VDSL connection in the ONU.
An instance of this managed entity shall be automatically created/deleted by the ONU upon the
Relationships
Attributes
byte is the slot ID. The second byte is the port ID with a value range from 0x01 to 0xFF (1 to
255). (R) (mandatory) (2 bytes)
Line Transmit Rate: Indicates the current VTU-O line transmit rate in kbit/s. This value will be
less than or equal to the current attainable rate.
NOTE – 1 kbit/s = 1000 bit/s.
Serial Number Part 1: The vendor-specific string that identifies the vendor equipment. It
consists of up to 32 ASCII characters. This attribute contains the first 16 characters.
Vendor ID: The vendor ID code is a copy of the binary vendor identification field expressed as
readable characters in hexadecimal notation. (R) (mandatory) (16 bytes)
Version Number: The vendor-specific version number sent by this VTU as part of the
initialization messages. It is a copy of the binary version number field expressed as readable
characters in hexadecimal notation. (R) (mandatory) (16 bytes)
Current Status: Indicates current state of the VTU-O. This is a bit-map of possible conditions.
The various bit positions are:
0 – noDefect – There are no defects on the line.
1 – lossOfFraming – VTU-O failure due to not receiving a valid frame.
2 – lossOfSignal – VTU-O failure due to not receiving signal.
ITU-T Rec. G.983.2 (07/2005) 193

3 – lossOfPower – VTU-O failure due to loss of power.
4 – lossOfSignalQuality – Loss of Signal Quality is declared when the Noise Margin falls
below the Minimum Noise Margin, or the bit-error-rate exceeds 10–7.
5 – lossOfLink – VTU-O failure due to inability to link with peer VTU. Set whenever the
transceiver is in the 'Warm Start' state.
6 – dataInitFailure – VTU-O failure during initialization due to bit errors corrupting startup
exchange data.
7 – configInitFailure – VTU-O failure during initialization due to peer VTU not able to
support requested configuration.
8 – protocolInitFailure – VTU-O failure during initialization due to incompatible protocol
used by the peer VTU.
9 – noPeerVtuPresent – VTU-O failure during initialization due to no activation sequence
detected from peer VTU.
Current Output Power: Measured total output power transmitted by this VTU in steps of
0.1 dBm. This is the measurement that was reported during the last activation sequence. The
effective range is 0 (0) to +16 (160) dBm. (R) (mandatory) (1 byte)
Current SNR Margin: Noise Margin as seen by this VTU with respect to its received signal
in steps of 0.25 dB. The effective range is –31.75 (–127) to +31.75 (127) dB. (R) (mandatory)
(1 byte)
Current Attenuation: Measured difference in the total power transmitted by the peer VTU and
the total power received by this VTU. The effective range is 0 (0) to +63.75 (255) dB.
Current Attainable Rate: Indicates the maximum currently attainable line transmit rate by the
VTU-O in kbit/s. This value will be equal to or greater than the current line rate.
Current Loop Length Estimate: Estimated loop length in feet assuming a 26 AWG (0.4 mm)
loop. (R) (mandatory) (2 bytes)
Actions
Notifications
None.
7.3.84 VDSL VTU-R physical data
This managed entity represents the physical status of the VDSL Termination Unit (Remote)
(VTU-R) in a VDSL connection in the ONU.
Relationships
194 ITU-T Rec. G.983.2 (07/2005)

Attributes
Line Transmit Rate: Indicates the current VTU-R line transmit rate in kbit/s. This value will be
less than or equal to the current attainable rate.
Serial Number Part 1: The vendor-specific string that identifies the vendor equipment. This
attribute contains the first 16 characters. (R) (mandatory) (16 bytes)
Vendor ID: The vendor ID code is a copy of the binary vendor identification field expressed as
readable characters in hexadecimal notation. (R) (mandatory) (16 bytes)
Version Number: The vendor-specific version number sent by this VTU as part of the
initialization messages. It is a copy of the binary version number field expressed as readable
characters in hexadecimal notation. (R) (mandatory) (16 bytes)
Current Status: Indicates current state of the VTU line. This is a bit-map of possible conditions.
The various bit positions are:
0 – noDefect – There are no defects on the line.
1 – lossOfFraming – VTU failure due to not receiving a valid frame.
2 – lossOfSignal – VTU failure due to not receiving signal.
3 – lossOfPower – VTU failure due to loss of power.
4 – lossOfSignalQuality – Loss of Signal Quality is declared when the Noise Margin falls
below the Minimum Noise Margin, or the bit-error-rate exceeds 10–7.
Current Output Power: Measured total output power transmitted by this VTU in steps of
0.1 dBm. This is the measurement that was reported during the last activation sequence. The
effective range is 0 (0) to +16 (160) dBm. (R) (mandatory) (1 byte)
Current SNR Margin: Noise Margin as seen by this VTU with respect to its received signal in
0.25 dB. The effective range is –31.75 (–127) to +31.75 (127) dB. (R) (mandatory) (1 byte)
Current Attenuation: Measured difference in the total power transmitted by the peer VTU and
the total power received by this VTU. The effective range is 0 (0) to +63.75 (255) dB.
Current Attainable Rate: Indicates the maximum currently attainable line transmit rate by the
VTU-R in kbit/s. This value will be equal to or greater than the current line rate.
Actions
ITU-T Rec. G.983.2 (07/2005) 195

Notifications
None.
7.3.85 VDSL channel data
This managed entity represents the physical status of the VDSL Fast and slow channels in a VDSL
connection in the ONU.
Relationships
Attributes
Current Interleave Delay Down: Downstream Interleave Delay for this channel in
milliseconds. Interleave delay defines the mapping (relative spacing) between subsequent input
bytes at the interleaver input and their placement in the bit stream at the interleaver output.
Larger numbers provide greater separation between consecutive input bytes in the output bit
stream allowing for improved impulse noise immunity at the expense of payload latency.
Current Fast Payload Rate Down: Actual fast channel downstream data rate, in kbit/s.
Current Slow Payload Rate Down: Actual slow downstream data rate, in kbit/s.
Current Fast CRC Block Length Down: Indicates the length of the downstream fast channel
data-block, in bytes, on which the CRC operates. (R) (mandatory) (2 bytes)
Current Slow CRC Block Length Down: Indicates the length of the downstream slow channel
Current Slow Burst Protect Down: Actual level of downstream impulse noise (burst)
protection, in microseconds, for the slow channel. (R) (mandatory) (2 bytes)
Current Fast FEC Down: Actual downstream Forward Error Correction (FEC) redundancy, in
percent, related overhead for the fast channel. (R) (mandatory) (1 byte)
Current Interleave Delay Up: Downstream Interleave Delay for this channel in milliseconds.
Interleave delay applies only to the interleave (slow) channel and defines the mapping (relative
spacing) between subsequent input bytes at the interleaver input and their placement in the bit
stream at the interleaver output. Larger numbers provide greater separation between consecutive
input bytes in the output bit stream allowing for improved impulse noise immunity at the
expense of payload latency.
In the case where the interface type is fast, return a value of zero. (R) (mandatory) (1 byte)
Current Fast Payload Rate Up: Actual fast channel upstream data rate, in kbit/s.
196 ITU-T Rec. G.983.2 (07/2005)

Current Slow Payload Rate Up: Actual slow upstream data rate, in kbit/s.
Current Fast CRC Block Length Up: Indicates the length of the upstream fast channel
Current Slow CRC Block Length Up: Indicates the length of the upstream slow channel
Current Slow Burst Protect Up: Actual level of upstream impulse noise (burst) protection, in
microseconds, for the slow channel. (R) (mandatory) (2 bytes)
Current Fast FEC Up: Actual upstream Forward Error Correction (FEC) redundancy, in
percent, related overhead for the fast channel. (R) (mandatory) (1 byte)
Actions
Notifications
None.
7.3.86 VDSL line configuration profile
An instance of this managed entity represents a VDSL Line Configuration Profile supported on the
ONU. Zero or more VDSL Physical Path Termination Points can reference an instance of a VDSL
Line Configuration Profile managed entity.
Instances of this managed entity are created and deleted by the ONU on request of the OLT.
Relationships
Zero or more instances of this managed entity shall be contained in an ONU. One or more
instances of this managed entity shall be contained in an ONU containing instances of Physical
Path Termination Point VDSL UNI.
Attributes
entity. The value 0x00 is reserved. (R, W, Set-be-create) (mandatory) (2 bytes)
Down Rate Mode: Specifies the rate selection behaviour for the line in the downstream
direction. manual(1) forces the rate to the configured rate, adaptAtInit(2) adapts the line based
upon line quality. (R, W, Set-by-Create) (mandatory) (1 byte)
Up Rate Mode: Specifies the rate selection behaviour for the line in the upstream direction.
manual(1) forces the rate to the configured rate, adaptAtInit(2) adapts the line based upon line
quality. (R, W, Set-by-Create) (mandatory) (1 byte)
Down Max Power: Specifies the maximum aggregate downstream power level in the range 0
(0) to 14.5 dBm (58) in 0.25 dBm intervals. (R, W, Set-by-Create) (mandatory) (1 byte)
Up Max Power: Specifies the maximum aggregate upstream power level in the range 0 (0) to
14.5 dBm (58) in 0.25 dBm intervals. (R, W, Set-by-Create) (mandatory) (1 byte)
ITU-T Rec. G.983.2 (07/2005) 197

Down Max SNR Margin: Specifies the maximum downstream Signal/Noise Ratio Margin in
units of 0.25 dB, for a range of 0 (0) to 31.75 dB (127). (R, W, Set-by-Create) (mandatory)
(1 byte)
Down Min SNR Margin: Specifies the minimum downstream Signal/Noise Ratio Margin in
units of 0.25 dB, for a range of 0 (0) to 31.75 dB (127). (R, W, Set-by-Create) (mandatory)
(1 byte)
Down Target SNR Margin: Specifies the target downstream Signal/Noise Ratio Margin in units
of 0.25 dB, for a range of 0 (0) to 31.75 dB (127). This is the Noise Margin the transceivers must
achieve with a BER of 10–7 or better to successfully complete initialization. (R, W,
Set-by-Create) (mandatory) (1 byte)
Up Max SNR Margin: Specifies the maximum upstream Signal/Noise Ratio Margin in units of
0.25 dB, for a range of 0 (0) to 31.75 dB (127). (R, W, Set-by-Create) (mandatory) (1 byte)
Up Min SNR Margin: Specifies the minimum upstream Signal/Noise Ratio Margin in units of
0.25 dB, for a range of 0 (0) to 31.75 dB (127). (R, W, Set-by-Create) (mandatory) (1 byte)
Up Target SNR Margin: Specifies the target upstream Signal/Noise Ratio Margin in units of
0.25 dB, for a range of 0 (0) to 31.75 dB (127). This is the Noise Margin the transceivers must
achieve with a BER of 10–7 or better to successfully complete initialization. (R, W,
Down PBO Control: Downstream power backoff (PBO) control for this line. For transceivers
which do not support downstream PBO control, this object MUST be fixed at disabled(1). If
auto(2) is selected, the transceiver will automatically adjust the power backoff. If manual(3) is
selected, then the transceiver will use the Down PBO Level. (R, W, Set-by-Create) (mandatory)
(1 byte)
Up PBO Control: Upstream power backoff (PBO) control for this line. For transceivers which
do not support upstream PBO control, this object MUST be fixed at disabled(1). If auto(2) is
selected, the transceiver will automatically adjust the power backoff. If manual(3) is selected,
then the transceiver will use the Up PBO Level. (R, W, Set-by-Create) (mandatory) (1 byte)
Down PBO Level: Specifies the downstream backoff level to be used when Down PBO
Control = manual(3). Valid range is 0 dB (0) to 40 dB (160) in 0.25 dB intervals. (R, W,
Up PBO Level: Specifies the upstream backoff level to be used when Up PBO
Control = manual(3). Valid range is 0 dB (0) to 40 dB (160) in 0.25 dB intervals. (R, W,
Line Type: This parameter provisions the VDSL physical entity at start-up by defining whether
and how the line will be channelized, i.e., which channel type(s) are supported. If the line is to be
channelized, the value will be other than noChannel(1).
Defined values are:
noChannel(1) – no channels exist;
fastOnly(2) – only the fast channel exists;
slowOnly(3) – only the slow channel exists
fastOrSlow(4) – either the fast or the slow channel exists, but only one at a time;
fastAndSlow(5) – both fast and slow channels exist.
(R, W, Set-by-Create) (mandatory) (1 byte)
198 ITU-T Rec. G.983.2 (07/2005)

Actions
Notifications
None.
7.3.87 VDSL channel configuration profile
An instance of this managed entity represents a VDSL Channel Configuration Profile supported on
the ONU. Zero or more VDSL Physical Path Termination Points can reference an instance of a
VDSL Channel Configuration Profile managed entity.
Relationships
Attributes
Down Rate Ratio: This attribute is the configured allocation ratio of excess downstream
transmit bandwidth between fast and slow channels. Only applies when two channel mode and
adaptAtInit are supported. Distribute bandwidth on each channel in excess of the corresponding
Minimum Transmit Bit Rate so that:
Rate Change Ratio = [Fast/(Fast + Slow)] × 100
In other words, this value is the fast channel percentage. Valid range is 0 to 100. (R, W,
Set-by-Create) (optional) (1 byte)
Up Rate Ratio: This attribute is the configured allocation ratio of excess upstream transmit
bandwidth between fast and slow channels. Only applies when two channel mode and
adaptAtInit are supported. Distribute bandwidth on each channel in excess of the corresponding
Minimum Transmit Bit Rate so that:
Rate Change Ratio = [Fast/(Fast + Slow)] × 100
In other words, this value is the fast channel percentage. Valid range is 0 to 100. (R, W,
Set-by-Create) (optional) (1 byte)
Down Slow Max Data Rate: Specifies the maximum downstream slow channel data rate in
steps of 64 kbit/s. The maximum aggregate downstream transmit speed of the line can be derived
from the sum of maximum downstream fast and slow channel data rates. (R, W, Set-by-Create)
Down Slow Min Data Rate: Specifies the minimum downstream slow channel data rate in steps
of 64 kbit/s. The minimum aggregate downstream transmit speed of the line can be derived from
the sum of minimum downstream fast and slow channel data rates. (R, W, Set-by-Create)
ITU-T Rec. G.983.2 (07/2005) 199

Up Slow Max Data Rate: Specifies the maximum upstream slow channel data rate in steps of
64 kbit/s. The maximum aggregate upstream transmit speed of the line can be derived from the
sum of maximum upstream fast and slow channel data rates. (R, W, Set-by-Create) (mandatory)
(2 bytes)
Up Slow Min Data Rate: Specifies the minimum upstream slow channel data rate in steps of
64 kbit/s. The minimum aggregate upstream transmit speed of the line can be derived from the
sum of minimum upstream fast and slow channel data rates. (R, W, Set-by-Create) (mandatory)
(2 bytes)
Down Max Interleave Delay: Specifies the maximum interleave delay, in milliseconds, for the
downstream slow channel. Valid range is 0 to 255 ms. (R, W, Set-by-Create) (mandatory)
(1 byte)
Up Max Interleave Delay: Specifies the maximum interleave delay, in milliseconds, for the
upstream slow channel. Valid range is 0 to 255 ms. (R, W, Set-by-Create) (mandatory) (1 byte)
Down Target Slow Burst: Specifies the target level of impulse noise (burst) protection, in
microseconds, for the downstream slow channel. Valid range is 0 to 1275 µs. (R, W,
Set-by-Create) (mandatory) (2 bytes)
Up Target Slow Burst: Specifies the target level of impulse noise (burst) protection, in
microseconds, for the upstream slow channel. Valid range is 0 to 1275 µs. (R, W, Set-by-Create)
Down Fast Max Data Rate: Specifies the maximum downstream fast channel data rate in steps
of 64 kbit/s. (R, W, Set-by-Create) (mandatory) (2 bytes)
Down Fast Min Data Rate: Specifies the minimum downstream fast channel data rate in steps
of 64 kbit/s. (R, W, Set-by-Create) (mandatory) (2 bytes)
Up Fast Max Data Rate: Specifies the maximum upstream fast channel data rate in steps of
64 kbit/s. (R, W, Set-by-Create) (mandatory) (2 bytes)
Up Fast Min Data Rate: Specifies the minimum upstream fast channel data rate in steps of
64 kbit/s. (R, W, Set-by-Create) (mandatory) (2 bytes)
Down Max Fast FEC: This parameter provisions the maximum level of Forward Error
Correction (FEC) redundancy related overhead to be maintained, as a percentage, for the
downstream fast channel. Valid range is 0 to 50 percent. (R, W, Set-by-Create) (optional)
(1 byte)
Up Max Fast FEC: This parameter provisions the maximum level of Forward Error Correction
(FEC) redundancy related overhead to be maintained, as a percentage, for the upstream fast
channel. Valid range is 0 to 50 percent. (R, W, Set-by-Create) (optional) (1 byte)
Actions
Notifications
None.
200 ITU-T Rec. G.983.2 (07/2005)

7.3.88 VDSL band plan configuration profile
An instance of this managed entity represents a VDSL Band Plan Configuration Profile supported
on the ONU. Zero or more VDSL Physical Path Termination Points can reference an instance of a
VDSL Band Plan Configuration Profile managed entity.
Relationships
Attributes
Band Plan: The VDSL band plan to be used for the line. bandPlan997(1) is to be used for
G.993.1 Bandplan-B, ETSI Bandplan, ANSI Plan 997. bandPlan998(2) is to be used for G.993.1
Bandplan-A, ANSI Plan 998. bandPlanFx(3) is to be used for G.993.1 Bandplan-C. other(4) is to
be used for non-standard band plans. If this object is set to bandPlanFx(3), then Band Plan FX
MUST also be set. (R, W, Set-by-Create) (mandatory) (1 byte)
Band Plan FX: The frequency limit, in kHz, between bands D2 and U2 when the Band Plan is
set to bandPlanFx(3). Valid range is 3 750 to 12 000 kHz. (R, W, Set-by-Create) (optional)
(2 bytes)
Band Opt Usage: Defines the VDSL link use of the optional frequency range [25 kHz-138 kHz]
(Opt). unused(1) indicates Opt is unused, upstream(2) indicates Opt usage is for upstream,
downstream(3) indicates Opt usage is for downstream. (R, W, Set-by-Create) (mandatory)
(1 byte)
Up PSD Template: The upstream PSD template to be used for the line. Here, templateMask1(1)
refers to a notched mask that limits the transmitted PSD within the internationally standardized
HAM (amateur Radio) radio bands, while templateMask2(2) refers to an unnotched mask. The
masks themselves depend upon the applicable standard being used (Applicable Standard). (R, W,
Down PSD Template: The downstream PSD template to be used for the line. Here,
templateMask1(1) refers to a notched mask that limits the transmitted PSD within the
internationally standardized HAM (Handheld Amateur Radio) radio bands, while
templateMask2(2) refers to an unnotched mask. The masks themselves depend upon the
applicable standard being used (Applicable Standard). (R, W, Set-by-Create) (mandatory)
(1 byte)
HAM Band Mask: The transmit power spectral density mask code, used to avoid interference
with HAM (Handheld Amateur Radio) radio bands by introducing power control (notching) in
one or more of these bands. Amateur radio band notching is defined in the VDSL spectrum as
follows:
Band Start frequency Stop frequency
------- ----------------- --------------------------------------
30 m 1 810 kHz 2 000 kHz
40 m 3 500 kHz 3 800 kHz (ETSI); 4000 kHz (ANSI)
80 m 7 000 kHz 7 100 kHz (ETSI); 7300 kHz (ANSI)
160 m 10 100 kHz 10 150 kHz
ITU-T Rec. G.983.2 (07/2005) 201

Notching for each standard band can be enabled or disabled via this bit mask. Two custom
notches may be specified. If customNotch1 is enabled, then both Custom Notch 1 Start and
Custom Notch 1 Stop MUST be specified. If customNotch2 is enabled, then both Custom
Notch 2 Start and Custom Notch 2 Stop MUST be specified. Valid bit values are defined as
follows, all combinations are allowed:
customNotch1(0) – custom (region-specific) notch
customNotch2(1) – custom (region-specific) notch
amateurBand30m(2) – amateur radio band notch
(R, W, Set-by-Create) (mandatory) (1 byte)
Custom Notch 1 Start: Specifies the start frequency, in kHz, of custom HAM (Handheld
Amateur Radio) notch 1. This field MUST be less than or equal to Custom Notch 1 Stop. Valid
range is 0 to 65 535 kHz. (R, W, Set-by-Create) (optional) (2 bytes)
Custom Notch 1 Stop: Specifies the stop frequency, in kHz, of custom HAM (Handheld
Amateur Radio) notch 1. This field MUST be greater than or equal to Custom Notch 1 Start.
(R, W, Set-by-Create). Valid range is 0 to 65 535 kHz. (optional) (2 bytes)
Custom Notch 2 Start: Specifies the start frequency, in kHz, of custom HAM (Handheld
Amateur Radio) notch 2. This field MUST be less than or equal to Custom Notch 2 Stop. Valid
range is 0 to 65 535 kHz. (R, W, Set-by-Create) (optional) (2 bytes)
Custom Notch 2 Stop: Specifies the stop frequency, in kHz, of custom HAM (Handheld
Amateur Radio) notch 2. This field MUST be greater than or equal to Custom Notch 2 Start.
Valid range is 0 to 65 535 kHz. (R, W, Set-by-Create) (optional) (2 bytes)
Deployment Scenario: The VDSL line deployment scenario. When using fttCab(1), the VTU-C
is located in a street cabinet. When using fttEx(2), the VTU-C is located at the central office.
Changes to this value will have no effect on the transceiver. (R, W, Set-by-Create) (mandatory)
(1 byte)
ADSL Presence: Indicates presence of ADSL service in the associated cable bundle/binder.
none(1) indicates no ADSL service in the bundle, adslOverPots(2) indicates ADSL service over
POTS is present in the bundle, adslOverISDN(3) indicates ADSL service over ISDN is present
in the bundle. (R, W, Set-by-Create) (mandatory) (1 byte)
Applicable Standard: The VDSL standard to be used for the line. ansi(1) indicates ANSI
standard, etsi(2) indicates ETSI standard, itu(3) indicates ITU standard, other(4) indicates a
standard other than the above. (R, W, Set-by-Create) (mandatory) (1 byte)
Actions
Notifications
None.
202 ITU-T Rec. G.983.2 (07/2005)

7.3.89 VDSL VTU-O physical interface monitoring history data
VDSL physical interface.
Path Termination Point VDSL UNI managed entity is created/deleted.
The performance management of the physical interfaces used by VDSL shall be supported.
Failure/notifications should include threshold alerts for unacceptable performance (error) rates.
Performance data should include transmission counts of Errored Seconds (ES), Severely Errored
Seconds (SES) and Unavailable Seconds (UAS).
Relationships
One instance of this managed entity can exist for each instance of the Physical Path Termination
Point VDSL UNI.
Attributes
Loss of Framing Seconds: Count of seconds during this interval that there was Loss of Framing.
Loss of Signal Seconds: Count of seconds during this interval that there was Loss of Signal.
Loss of Power Seconds: Count of seconds during this interval that there was Loss of Power.
Loss of Link Seconds: Count of seconds during this interval that there was Loss of Link.
Errored Seconds: Count of Errored Seconds during this interval. An Errored Second is a
one-second interval containing one or more CRC anomalies, or one or more LOS or LOF
defects. (R) (mandatory) (2 bytes)
Severely Errored Seconds: Count of Severely Errored Seconds during this interval.
Unavailable Seconds: Count of Unavailable Seconds during this interval. (R) (mandatory)
(2 bytes)
ITU-T Rec. G.983.2 (07/2005) 203

Line Initializations: Count of the line initialization attempts during this interval. This count
includes both successful and failed attempts. (R) (mandatory) (2 bytes)
Actions
Notifications
Both ONU and OLT should know the event list used by this entity. The list of TCAs for this
Table 29/G.983.2 – Alarm list for VDSL VTU-O physical interface monitoring history data
number (Note)
0 LOFS Exceeds threshold 1
1 LOSS Exceeds threshold 2
2 LOLS Exceeds threshold 3
3 LOPS Exceeds threshold 4
5 LI Exceeds threshold 6
8-223 Reserved
7.3.90 VDSL VTU-R physical interface monitoring history data

VDSL physical interface.
The performance management of the physical interfaces used by VDSL shall be supported.
Failure/notifications should include threshold alerts for unacceptable performance (error) rates.
Performance data should include transmission counts of Errored Seconds (ES), Severely Errored
Seconds (SES) and Unavailable Seconds (UAS).
204 ITU-T Rec. G.983.2 (07/2005)

Relationships
Point VDSL UNI.
Attributes
collected by this managed entity. The value 0x0000 is interpreted as a Null pointer. (R, W, Set
by-create) (mandatory) (2 bytes)
Loss of Framing Seconds: Count of seconds during this interval that there was Loss of Framing.
Loss of Signal Seconds: Count of seconds during this interval that there was Loss of Signal.
Loss of Power Seconds: Count of seconds during this interval that there was Loss of Power.
Loss of Link Seconds: Count of seconds during this interval that there was Loss of Link.
Errored Seconds: Count of Errored Seconds during this interval. An Errored Second is a
one-second interval containing one or more CRC anomalies, or one or more LOS or LOF
defects. (R) (mandatory) (2 bytes)
Severely Errored Seconds: Count of Severely Errored Seconds during this interval.
Unavailable Seconds: Count of Unavailable Seconds during this interval. (R) (mandatory)
(2 bytes)
Actions
ITU-T Rec. G.983.2 (07/2005) 205

Notifications
Table 30/G.983.2 – Alarm list for VDSL VTU-R physical interface monitoring history data
number (Note)
0 LOFS Exceeds threshold 1
1 LOSS Exceeds threshold 2
2 LOLS Exceeds threshold 3
3 LOPS Exceeds threshold 4
7-223 Reserved
7.3.91 VDSL VTU-O channel performance monitoring history data

This managed entity contains the last completed 15-minute interval collected statistic data for both
fast and slow VDSL channels, as seen from the VTU-O.
Relationships
Point VDSL UNI.
Attributes
206 ITU-T Rec. G.983.2 (07/2005)

Fast Channel Corrected Blocks: This attribute is the count of all blocks received by the
VTU-O with errors that were corrected on the fast channel within the previous 15-minute
Fast Channel Bad Blocks: This attribute is the count of all blocks received by the VTU-O with
uncorrectable errors on the fast channel within the previous 15-minute interval. (R) (mandatory)
(4 bytes)
Fast Channel Transmitted Blocks: This attribute is the count of all blocks transmitted by the
VTU-O on the fast channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Fast Channel Received Blocks: This attribute is the count of all blocks received by the VTU-O
on the fast channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Slow Channel Corrected Blocks: This attribute is the count of all blocks received by the
VTU-O with errors that were corrected on the slow channel within the previous 15-minute
Slow Channel Bad Blocks: This attribute is the count of all blocks received by the VTU-O with
uncorrectable errors on the slow channel within the previous 15-minute interval. (R) (mandatory)
(4 bytes)
Slow Channel Transmitted Blocks: This attribute is the count of all blocks transmitted by the
VTU-O on the slow channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Slow Channel Received Blocks: This attribute is the count of all blocks received by the VTU-O
on the slow channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Actions
Notifications
ITU-T Rec. G.983.2 (07/2005) 207

Table 31/G.983.2 – Alarm list for VDSL VTU-O channel performance monitoring history
data (reproduced from Table 14/G.983.10)
number (Note)
0 FCCB Exceeds threshold 1
1 FCBB Exceeds threshold 2
2 SCCB Exceeds threshold 3
3 SCBB Exceeds threshold 4
4-223 Reserved
7.3.92 VDSL VTU-R channel performance monitoring history data

This managed entity contains the last completed 15-minute interval collected statistic data for both
fast and slow VDSL channels, as seen from the VTU-R.
Relationships
Point VDSL UNI.
Attributes
Fast Channel Corrected Blocks: This attribute is the count of all blocks received by the VTU-R
with errors that were corrected on the fast channel within the previous 15-minute interval.
208 ITU-T Rec. G.983.2 (07/2005)

Fast Channel Bad Blocks: This attribute is the count of all blocks received by the VTU-R with
uncorrectable errors on the fast channel within the previous 15-minute interval. (R) (mandatory)
(4 bytes)
Fast Channel Transmitted Blocks: This attribute is the count of all blocks transmitted by the
VTU-R on the fast channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Fast Channel Received Blocks: This attribute is the count of all blocks received by the VTU-R
on the fast channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Slow Channel Corrected Blocks: This attribute is the count of all blocks received by the
VTU-R with errors that were corrected on the slow channel within the previous 15-minute
Slow Channel Bad Blocks: This attribute is the count of all blocks received by the VTU-R with
uncorrectable errors on the slow channel within the previous 15-minute interval. (R) (mandatory)
(4 bytes)
Slow Channel Transmitted Blocks: This attribute is the count of all blocks transmitted by the
VTU-R on the slow channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Slow Channel Received Blocks: This attribute is the count of all blocks received by the VTU-R
on the slow channel within the previous 15-minute interval. (R) (mandatory) (4 bytes)
Actions
Notifications
ITU-T Rec. G.983.2 (07/2005) 209

Table 32/G.983.2 – Alarm list for VDSL VTU-R channel performance monitoring
history data (reproduced from Table 15/G.983.10)
Threshold Data Counter
Number (Note)
0 FCCB Exceeds threshold 1
1 FCBB Exceeds threshold 2
2 SCCB Exceeds threshold 3
3 SCBB Exceeds threshold 4
4-223 Reserved
7.3.93 Video return path service profile

Relationships
One instance of this managed entity may exist for each ONU. It is created automatically by the
ONU on startup, if the ONU implements this service.
Please note that Annex A defines the transport methods required to support the video return path
function. This includes providing a brief description of the relevant aspects of the two return path
specifications supported (SCTE 55-1 [25] and 55-2 [26]). It also includes the formatting for
carriage of the data over the B-PON data path.
Appendix VI presents three transparent ways to support the video return channel over a B-PON
or other access system. The transparent aspect of the video return path is given only for
information since it does not impact B-PON standardization.
Attributes
entity. This 2-byte number always has the value 0x00. (R) (mandatory) (2 bytes)
VRP Mode: This attribute specifies which format is being used for the VRP. These are defined
by code-points:
0: Mode 1, SCTE 55-1 shall be used (256 kbit/s data rate, 62 byte PDUs, preceded by the
unique word 0xCC CC CC 0). (mandatory)
210 ITU-T Rec. G.983.2 (07/2005)

1: Mode 2, SCTE 55-2 shall be used (256 kbit/s data rate, 59 byte PDUs, preceded by the
unique word 0xCC CC CC 0D). (optional)
2: Mode 2, SCTE 55-2 shall be used (1.544 Mbit/s data rate, 59 byte PDUs, preceded by
the unique word 0xCC CC CC 0D). (mandatory)
3: Mode 2, SCTE 55-2 should be used (3.088 Mbit/s data rate, 59 byte PDUs, preceded by
the unique word 0xCC CC CC 0D). (optional)
4-255: Reserved.
VRP Frequency lower bound: This attribute reports the ONU VRP tuning range lower bound,
in units of Hertz. (R) (mandatory) (4 bytes)
VRP Frequency upper bound: This attribute reports the ONU VRP tuning range upper bound,
in units of Hertz. (R) (mandatory) (4 bytes)
VRP Frequency used: This attribute reports the ONU VRP tuner frequency currently in use, in
units of Hertz. (R, W) (mandatory) (4 bytes)
Mode 1 Physical Layer Configuration Mode: This attribute controls the physical layer
configuration to be used in mode 1. The attribute is bit mapped, as follows:
Bit 15: DQPSK mode. 0 = "Default Mode", 1 = "Alternate Mode"
Bit 14-8: Reserved
Bit 7: Randomizer Stage 6 preload
Actions
Notifications
Table 33.
alarm list for this entity is given in Table 34.
ITU-T Rec. G.983.2 (07/2005) 211

Table 33/G.983.2 – AVC list for video return path service
1 N/A
2 OpState Operational state of VRP Service
3-16 Reserved
Table 34/G.983.2 – Alarm list for video return path service

0 Frequency Mismatch Frequency set by OLT is outside the capabilities of this
ONU, or a frequency that is not on the standardized
frequency plan
1-223 Reserved
7.3.94 Video return path statistics

Relationships
One instance of this managed entity may exist for each ONU. It is created by the OLT.
Attributes
entity. This 2-byte number always has the value 0x00. (R, Set-by-create) (mandatory) (2 bytes)
Interval End time: This attribute identifies the most recently finished 15-minute interval. It is a
Rx Total bursts: This attribute reports the total number of bursts detected. (R) (optional)
(4 bytes)
Rx Good bursts: This attribute reports the number of bursts that were detected and received
correctly. (R) (optional) (4 bytes)
Rx FEC corrected bursts: This attribute reports the number of bursts that were detected with
errors, but which were successfully corrected using FEC. (R) (optional) (4 bytes)
Rx Missed bursts: This attribute reports the number of bursts that were detected, but that were
not received correctly (e.g., errors that are FEC uncorrectable). (R) (optional) (4 bytes)
Rx Min Power: This attribute reports the lowest power level of all bursts received in the current
interval, in units of dBmV. (R) (optional) (1 byte)
212 ITU-T Rec. G.983.2 (07/2005)

Rx Max Power: This attribute reports the highest power level of all bursts received in the
current interval, in units of dBmV. (R) (optional) (1 byte)
Rx Current Power: This attribute reports the power level of the latest burst received, in units of
dBmV. (R) (mandatory) (optional) (1 byte)
Rx FEC corrected Symbols: This attribute reports the number of symbols that were corrected
through the use of FEC. It provides an indicator of the bit error rate of the link. (R) (optional)
(4 bytes)
Actions
Set: Set one Threshold ID.
Get current data: This action returns the current value of one or more actual counters associated
with performance monitoring attributes and the value of the Interval End Time attribute
representing the interval in which the request is made. The values in the specific counters are
reset at the end of the interval. Support of this action is optional.
Notifications
Table 35/G.983.2 – Alarm list for video return path statistics

number (Note)
0 Rx Total bursts Rx Total bursts threshold crossing 1
1 Rx Good bursts Rx Good bursts threshold crossing 2
2 Rx FEC corrected bursts Rx FEC corrected bursts threshold 3
crossing
3 Rx Missed bursts Rx Missed bursts threshold crossing 4
4 Rx Min Power Rx Min Power threshold crossing 5
5 Rx Max Power Rx Max Power threshold crossing 6
6 Rx Current Power Rx Current Power threshold crossing 7
7 Rx FEC corrected Symbols Rx FEC corrected Symbols 8
threshold crossing
8-223 Reserved
ITU-T Rec. G.983.2 (07/2005) 213

7.3.95 802.1p mapper service profile
This managed entity is used to associate the priorities of 802.1P priority tagged frames with a
specific connection. Instances of this managed entity are created and deleted at the request of the
OLT.
Relationships
One instance of this ME may be associated with zero or one instance of the PPTP UNI ME or the
MAC bridge port configuration data ME.
Attributes
PPTP UNI Pointer: An instance identifier of the PPTP UNI that is associated with this 802.1p
Priority Queue Mapper, in the case of direct 802.1p mapping. In the case of combined
Bridging-mapping, this pointer is not used, and its value is set to 0xFFFF. (R, Set-by-create)
Interwork TP Pointer (for P-Bit priority 0): This attribute represents a pointer to the
Interworking Termination Point that is associated with P-Bit = 000 tagged frames. The value
0xFFFF is a null pointer. (R, W, Set-by-create) (mandatory) (2 bytes)
Unmarked Frame Option: This attribute indicates how the ONT should handle Untagged
Ethernet frames received across the associated Ethernet interface. Valid values include the
following:
0: Convert from DSCP to 802.1p;
1: Tag frame to a certain value.
214 ITU-T Rec. G.983.2 (07/2005)

DSCP to P-Bit Mapping: This attribute is used in conjunction with the Unmarked Frame
Option attribute. If unmarked frame option is 0, this attribute structure can be considered a
bitmap that represents a sequence of 64 "3-bit" groupings. Each of the 64 groupings represents
the possible value of the 6-bit DSCP field. Each of the "3-bit" groupings represents the "P-bit
value" to which the associated DSCP value should be mapped. Once marked, the P-Bit marked
frame will then be routed to the GEM Interwork Pointer as indicated by the P-Bit to Interwork
Pointer mappings above.
Default P-Bit Marking: This attribute is used in conjunction with the Unmarked Frame Option
attribute. If unmarked frame option is 1, this attribute contains the default P-Bit priority setting
that will be applied to the frame. The P-Bit marked frame will then be routed to the
GEM Interwork Pointer as indicated by the P-Bit to Interwork Pointer mappings above.
Actions
Notifications
None.
7.3.96 OLTB-PON
This optional managed entity identifies the OLT to which an ONT is connected.
The setting of this ME prompts the ONT to configure itself for operability with the OLT that has
identified itself. If the OLT is operable with the ONT's default configuration then the setting of this
ME is not required.
An instance of this managed entity is automatically created by the ONT after initialization and setup
to the ONT's current configuration. Immediately following the startup phase, the OLT sets the ONT
to the desired configuration.
Relationships
One instance of this managed entity is contained in the instance of the ONT managed entity.
Attributes
OLT Vendor id: This attribute identifies the OLT vendor that the ONT is interfacing with, and
is the same format as the 4 most significant bytes of an ONT serial number as specified in ITU-T
Rec. G.983.1. Upon autonomous instantiation, this attribute consists of all spaces. (R,W)
Equipment ID: This attribute may be used to identify the specific type of OLT. In North
America, this may be used for the equipment CLEI code. The default value of all spaces shall be
used when Equipment ID information is not available or applicable to the OLT being
represented. Upon autonomous instantiation, this attribute consists of all spaces. (R,W)
ITU-T Rec. G.983.2 (07/2005) 215

Version: This attribute identifies the version of the OLT as defined by the vendor. The default
value of a printable value of "0" shall be used when version information is not available or
applicable to the OLT being represented. Upon autonomous instantiation, this attribute consists
of all spaces. (R,W) (mandatory) (14 bytes)
Actions
Notifications
None.
7.3.97 Multicast interworking VCC termination point
An instance of this managed entity represents a point in the ONT where the interworking of a
service (e.g., IP) or underlying physical infrastructure (e.g., Ethernet) takes place. At this point, a bit
stream is reconstructed from ATM cells.
Instances of this managed entity are created and deleted by the ONT on request of the OLT.
Establishment of connection
The multicast VCC TP is a special case of the ordinary VCC TP managed entity, whose purpose is
specifically to manage the correspondence of IP multicast group addresses with the PON layer
addresses. This is done via a new table attribute. The relationships that the ordinary VCC TP entity
has would be maintained; however, the VP/VC network CTP would not reflect a normal connection
per se, as the multicast VCC TP can represent many connections at once. So, the VP/VC network
CTP object used in this case would not represent a circuit termination point, and would only be used
to provide information on the traffic descriptors, priority queues, or performance management
features.
The related VP/VC network CTP, Service Profile, and AAL profile entities must be created first.
The multicast interworking VCC TP is then created with references to these entities.
Modes of operation
The default multicast operation of the PON is where all the multicast content streams are placed in
one PON layer connection. This connection is then specified in the first entry of the
MulticastAddressTable as set by the OLT. The single entry also specifies an all-inclusive IP
multicast address range (e.g., 224.0.0.0 to 239.255.255.255). The ONT then filters the traffic based
on either Ethernet MAC addresses or IP addresses. The VP/VC Network CTP ME has the VPI/VCI
that supports all the multicast connections.
The optional multicast operation of the PON is where groups of one or more multicast content
streams are carried over individual PON layer connections. In this case, the OLT sets as many table
entries as desired for the multicasting control system. The ONT then filters the groups based on
PON layer address. The ONT can also filter based on higher-layer addresses in a subsequent step. In
this case, only one instance of VP/VC Network CTP ME is created by the request from OLT.
Though this VP/VC Network CTP ME has only one VPI/VCI, ONT should regard this ME as the
representative of those multicast VP/VC connections. Therefore, the traffic descriptors, priority
queues, and performance management features for all the multicast connections are integrated into
the VP/VC Network CTP ME.
Discovery of Multicast support
The OLT uses the multicast IW VCC TP entity as the means to discover the ONT's multicasting
capability. This entity is mandatory if multicasting is supported by the ONT. Therefore, if the OLT
216 ITU-T Rec. G.983.2 (07/2005)

attempts to create this entity on an ONT that does not support multicasting, the create command
will fail. Furthermore, if the ONT does not support multiple multicasting groups, then the OLT's
attempt to set multiple table entries will fail. The OLT will then have to make the necessary
adjustments.
Relationships
One instance of this managed entity shall exist for each occurrence of transformation of ATM
cells into a data stream where multicast interworking is desired. Note that the attributes "AAL
Profile pointer" and "Service Profile pointer" imply relationships to these managed entities.
Attributes
entity. The value 0xFFFF is reserved. (R, Set-by-create) (mandatory) (2 bytes)
VCI Value: This attribute is not used. (R, Set-by-create) (mandatory) (2 bytes)
VP/VCNetworkCTP Connectivity Pointer: This attribute provides an instance identifier of the
VP Network CTPB-PON or VC Network CTPB-PON that is associated with this Interworking
Interworking Option: This attribute identifies the type of non-ATM function that is being
interworked; the option can be MAC Bridge LAN (0x01), IP Router (0x03), or 802.1p mapper
(0x05). (R, Set-by-create) (mandatory) (1 byte)
Service Profile Pointer: This attribute provides the service profile type and a pointer to the
instance of a service profile, such as the MAC Bridge Service Profile (if the interworking option
= 0x01), IP Router Service Profile (if the interworking option = 0x03), or 802.1p mapper service
profile (if interworking option = 0x05). (R, Set-by-create) (mandatory) (2 bytes)
AAL Profile Pointer: This attribute provides the AAL profile type and a pointer to an instance
of AAL Profile such as AAL 5 ProfileB-PON if the interworking option = 0x01, 0x03, 0x05.
Interworking Termination Point pointer: This attribute is set to 0x0000, and not used.
AAL Loopback configuration: This attribute is set to 0x0000 and not used. (R, W) (mandatory)
(1 byte)
PPTP Counter: This attribute represents the number of instances of PPTP managed entities
associated with this instance of the Interworking VCC Termination Point managed entity. If only
one instance of a PPTP managed entity is associated with this instance of the Interworking VCC
Termination Point managed entity, this attribute is set to 0x01. If multiple instances of PPTP
managed entities are associated with this instance of the Interworking VCC Termination Point
managed entity, this attribute is set to 0xZZ, where ZZ represents the number of associated PPTP
instances. (R) (optional) (1 byte)
MulticastAddressTable: This attribute contains the mapping of IP multicast addresses to PON
layer addresses. One entry provides the VPI/Port-ID value (2 bytes, right justified), VCI/spare
value (2 bytes), IP multicast address start (4 bytes), and IP multicast address stop (4 bytes). An
OMCI set message can carry a maximum of 2 entries at the same time. The first four bytes of
each entry is treated as the index of the list, and a Set to a particular (VPI/Port-ID – VCI/spare)
value will overwrite any existing entry with the same first four bytes. If the last eight bytes of a
Set command are all zero, then that entry will be deleted from the list, as all-zero IP addresses
ITU-T Rec. G.983.2 (07/2005) 217

are not valid multicast addresses. (R, W) (mandatory for one entry, optional for multiple entries)
(N * 12 bytes, N is the number of entries in the list.)
Actions
Get: Get one or more attributes. Latch a snapshot (i.e., copy) of the current
MulticastAddressTable and respond with the size of data (4 bytes) that should be obtained using
the Get next command.
Get Next: Get the latched attribute values of the managed entity within the current snapshot.
Notifications
Alarm: None.
Table 36a/G.983.2 − AVC list for interworking VCC termination point

1-9 N/A
10 OpState Operational state of Interworking VCC Termination Point
11-16 Reserved
Table 36b/G.983.2 − Alarm list for interworking VCC termination point

0 End-to-end VC-AIS-LMIR End-to-end VC-AIS receiving indication (optional)
1 End-to-end VC-RDI-LMIR End-to-end VC-RDI receiving indication (optional)
2 End-to-end VC-AIS-LMIG End-to-end VC-AIS generation indication (optional)
3 End-to-end VC-RDI-LMIG End-to-end VC-RDI generation indication (optional)
4 Segment Loss of Continuity Loss of continuity is detected when the Interworking VCC
Termination Point is a segment end point (optional)
5 End-to-End Loss of Loss of continuity is detected at the Interworking VCC
Continuity Termination Point (optional)
6 CSA Cell starvation alarm
7-223 Reserved
7.4 VP and VC MUX management

7.4.1 VP Network CTPB-PON
This managed entity is used to represent the termination of VP links on an ONT. An instance of the
ATM VP Cross-Connection (i.e., VP MUX in ONT) managed entity may be used to relate two
218 ITU-T Rec. G.983.2 (07/2005)

instances of the VP Network CTPB-PON managed entity for point-to-point cross-connection
(multipoint cross-connection is for further study).
Instances of the VP Network CTPB-PON managed entity will be created on demand of the OLT:
• as a consequence of action "create" on the VP Network CTPB-PON managed entity, or
• as a consequence of action "create complete connection" on the ATM VP
Cross-Connection managed entity.
Instances of the VP Network CTPB-PON managed entity will be deleted on demand of the OLT:
• as a consequence of action "delete" on the VP Network CTPB-PON managed entity, or
• as a consequence of action "delete complete connection" on the ATM VP
Notice that a VP Network CTPB-PON can be deleted only when no ATM VP Cross-Connection or
Interworking VCC Termination Point is associated with it. It is the responsibility of the OLT to
make sure that the VP Network CTPB-PON meets this condition at the time when the OLT requests to
delete it.
Note that this managed entity aggregates connectivity functionality from the network view and
alarms from the network element view as well as artefacts from trails.
Relationships
Zero or more instances of the VP Network CTPB-PON managed entity shall exist for each instance
of the TC AdapterB-PON, PON TC Adapter or Interworking VCC Termination Point managed
entity.
Relationship to Priority QueueB-PON/Traffic Descriptor Profile Pointer: see attribute definition.
Relationship to UPC Disagreement Monitoring History DataB-PON: one or zero implied in the
managed entity id of UPC Disagreement Monitoring History DataB-PON.
This managed entity is related to the ATM VP Cross-Connection managed entity through the
Termination Point ANI/UNI side attributes of the ATM VP Cross-Connection managed entity.
Attributes
Managed Entity id: This attribute provides a number for each instance of this managed entity
that is unique over all Network CTPB-PON MEs, of both VP and VC type. (R, Set-by-create)
VPI Value: This attribute identifies the VPI value associated with the VP link being terminated.
This value must be unique over any ANI or UNI. (R, Set-by-create) (mandatory) (2 bytes)
UNI/ANI Pointer: This attribute associates the VP Network CTPB-PON with the ANI (i.e.,
PON interface) or a UNI. It points to the connected ANI/UNI instance id.
NOTE – For the case using the multiplexing function of AAL 2 (i.e., multiple instances of UNI are
associated with a VP Network CTPB-PON instance), this attribute is assigned a special value:
0x00XX will be used for pseudo slotIDs;
0xXX00 will be used for pseudo portIDs.
Therefore, 0x0000 will be used only for integrated interfaces (integrated type of ONT) that
support multiple AAL 2 functions. (R, Set-by-create) (mandatory) (2 bytes)
Direction: This attribute specifies whether the VP link is used for UNI-to-ANI (value 0x01),
ANI-to-UNI (value 0x02), or bidirectional (value 0x03) connection. (R, W, Set-by-create)
ITU-T Rec. G.983.2 (07/2005) 219

Priority Queue Pointer for downstream: This attribute points to the instance of the Priority
QueueB-PON used for this VP Network CTPB-PON in the downstream direction. Note that the value
of this pointer is null when the VP Network CTPB-PON is at the ANI side. (R, Set-by-create)
Traffic Management Pointer for upstream: This attribute points to the instance of the Priority
QueueB-PON or T-CONT used for this VP Network CTPB-PON in the upstream direction. It is used
when the UNI/ANI pointer indicates an ANI instance id. If the Traffic Management Option
attribute in ONTB-PON is 0x00, then this pointer indicates the Priority Queue serving this
VP CTP. If the Traffic Management Option attribute in ONTB-PON is 0x01, then this pointer
indicates the T-CONT serving this VP CTP. (R, Set-by-create) (mandatory) (2 bytes)
Traffic Descriptor Profile Pointer: This attribute serves as a pointer to the instance of the
Traffic Descriptor Profile managed entity that contains the traffic parameters used for this
VP Network CTPB-PON. This attribute is used when the Traffic Management Option attribute in
ONTB-PON is 0x01. It applies to the UNI side VP Network CTPB-PON if UPC is used. In this case,
this pointer points to a Traffic Descriptor managed entity.
When traffic shaping is used, it applies to the ANI side VP Network CTPB-PON. In this case, this
pointer points to a Traffic Descriptor Profile managed entity and the Priority Queue Pointer for
the upstream attribute is null. (R, Set-by-create) (optional) (2 bytes)
See also Appendix IV.
UNI Counter: This attribute represents the number of instances of UNIB-PON managed entities
associated with an instance of the VP Network CTPB-PON managed entity. If only one instance of
a UNIB-PON managed entity is associated with an instance of the VP Network CTPB-PON managed
entity, this attribute is set to 0x01. If multiple instances of UNIB-PON managed entities are
associated with an instance of the VP Network CTPB-PON managed entity (i.e., in case of AAL 2
multiplexing), this attribute is set to 0xZZ, where ZZ represents the number of associated
UNIB-PON instances. (R) (optional) (1 byte)
Actions
Get: Get one or more attributes of this managed entity.
Set: Set one or more attributes of this managed entity.
Notifications
Alarm: This notification is used to notify the management system for the ATM Layer
Management Indication (LMI) when an alarm has been detected or cleared. The OLT should
know the alarm list used by this entity. The alarm list for this entity is given in Table 37. See also
Appendix III.
220 ITU-T Rec. G.983.2 (07/2005)

Table 37/G.983.2 − Alarm list for VP network CTPB-PON
0 VP-AIS-LMIR VP-AIS receiving indication (optional)
1 VP-RDI-LMIR VP-RDI receiving indication (optional)
2 VP-AIS-LMIG VP-AIS generation indication (optional)
3 VP-RDI-LMIG VP-RDI generation indication (optional)
4 Segment Loss of Continuity Loss of continuity is detected when the VP Network
CTPB-PON is a segment end point (optional)
5 End-to-End Loss of Continuity Loss of continuity is detected when the VP Network
CTPB-PON supports an Interworking VCC Termination
Point (optional)
6-223 Reserved
7.4.2 ATM VP cross-connection

For point-to-point ATM VP Cross-Connections, this managed entity is used to represent the
Cross-Connect relationship between two VP Network CTPsB-PON. For multipoint ATM VP
Cross-Connections, which are optional, the use of this managed entity is for further study.
Instances of this managed entity shall be created and deleted by the OLT based on ATM connection
set up.
Relationships
Zero or more instances of the ATM VP Cross-Connection managed entity shall exist for each
instance of the ONTB-PON managed entity.
Attributes
entity. This 2-byte number is directly associated with the instance identifier of the VP Network
CTPB-PON at the ANI side of this ATM VP cross-connect. (R, Set-by-create) (mandatory)
(2 bytes)
Termination Point ANI side: This attribute identifies the instance of the VP Network CTPB-PON
managed entity that represents the cross-connected VP Network CTPB-PONs on the ANI side.
Termination Point UNI side: This attribute identifies the instance of the VP Network CTPB-PON
managed entity that represents the cross-connected VP Network CTPB-PONs on the UNI side.
the functions performed by instances of this managed entity. (R, W, Set-by-create) (mandatory)
(1 byte)
Actions
ITU-T Rec. G.983.2 (07/2005) 221

Create complete connection: Create two instances of the VP Network CTPB-PON managed
entity (ANI-side and UNI-side) and one instance of the ATM VP Cross-Connection managed
entity.
Delete complete connection: Delete two instances of the VP Network CTPB-PON managed entity
(ANI-side and UNI-side) and one instance of the ATM VP Cross-Connection managed entity.
Get: Get attributes of this managed entity.
Get complete connection: Get all attributes of a connection; this holds the attributes of two
instances of the VP Network CTPB-PON managed entity (ANI-side and UNI-side) and the
attributes of the corresponding ATM VP Cross-Connection managed entity.
Notifications
managed entity is given in Table 38.
Table 38/G.983.2 − AVC list for ATM VP cross-connection

1 N/A
2 N/A
4 N/A
5-16 Reserved
7.4.3 VP PM history data

This managed entity is used to collect and report performance monitoring data associated with a
VPC for the last completed 15-minute interval. The instances of this managed entity are created and
deleted on request of the OLT. Note that these processes supersede the in-band PM OAM functions.
Relationships
Zero or more instances of this managed entity may exist for each instance of the VP Network
CTPB-PON managed entity. If the instance is associated with the ANI-side VP CTP, then the
performance of the downstream ATM flows is reported. If the instance is associated with the
UNI-side VP CTP, then the performance of the upstream ATM flows is reported.
Attributes
VP Network CTPB-PON. (R, Set-by-create) (mandatory) (2 bytes)
the actual counters are updated. The value of this attribute is 0x00 during the first 15-minute
222 ITU-T Rec. G.983.2 (07/2005)

Lost C=0+1 Cells: This attribute measures background cell loss. It cannot distinguish between
cells lost because of header bit errors, ATM-level header errors, cell policing, or buffer
overflows. It records only loss of information independent of the priority of the cell. If the actual
counter saturates, it remains on its maximum value. (R) (mandatory) (2 bytes)
Lost C = 0 Cells: This attribute measures background cell loss. It cannot distinguish between
overflows. It records only loss of high priority cells. If the actual counter saturates, it remains on
its maximum value. (R) (mandatory) (2 bytes)
Misinserted Cells: This attribute is used to measure occurrences of when a cell is misrouted to
an active VP that is being monitored. If the actual counter saturates, it remains on its maximum
value. (R) (mandatory) (2 bytes)
Transmitted C = 0 + 1 Cells: This attribute provides a count of all cells that are originated at a
monitored connection by the transmitting end point (i.e., backward reporting is assumed). (R)
Transmitted C = 0 Cells: This attribute provides a count of all high priority cells that are
originated at a monitored connection by the transmitting end point (i.e., backward reporting is
assumed). (R) (mandatory) (5 bytes)
Impaired Block: This severely errored cell block counter will be incremented whenever one of
the following events takes place: the number of misinserted cells exceeds Mmisinserted, the number
of bipolar violations exceeds Merrored, or the number of lost cells exceeds Mlost. The values for
Mmisinserted, Merrored, and Mlost are set based on vendor-operator negotiation. (R) (mandatory)
(2 bytes)
Actions
real-time value of the actual counters associated with those attributes. Support of this action is optional.
Notifications
sent at the crossing of the threshold; the TCA change notification "off" will be sent at the end of
the 15-min period since that is when the counters are reset to 0x00. Both ONT and OLT should
know the event list used by this entity, given in Table 39.
ITU-T Rec. G.983.2 (07/2005) 223

Table 39/G.983.2 − Alarm list for VP PM history data
Threshold data
counter # (Note)
0 Lost CLP=0+ 1 Cells Exceeds threshold 1
1 Lost CLP=0 Cells Exceeds threshold 2
2 Misinserted Cells Exceeds threshold 3
3 Impaired Blocks Exceeds threshold 4
4-223 Reserved
7.4.4 VC network CTPB-PON

This managed entity is used to represent the termination of VC links on an ONT. An instance of the
ATM VC Cross-Connection (i.e., VC MUX in ONT) managed entity may be used to relate two
instances of the VC Network CTPB-PON managed entity for point-to-point cross-connection
(multipoint cross-connection is for further study).
Instances of the VC Network CTPB-PON managed entity will be created on demand of the OLT:
• as a consequence of action "create" on the VC Network CTPB-PON managed entity, or
• as a consequence of action "create complete connection" on the ATM VC
Instances of the VC Network CTPB-PON managed entity will be deleted on demand of the OLT:
• as a consequence of action "delete" on the VC Network CTPB-PON managed entity, or
• as a consequence of action "delete complete connection" on the ATM VC
Notice that a VC Network CTPB-PON can be deleted only when no ATM VC Cross-Connection or
Interworking VCC Termination Point is associated with it. It is the responsibility of the OLT to
make sure that the VC Network CTPB-PON meets this condition at the time when the OLT requests
to delete it.
Note that this managed entity aggregates connectivity functionality from the network view and
alarms from the network element view as well as artefacts from trails.
Relationships
Zero or more instances of the VC Network CTPB-PON managed entity shall exist for each
instance of the TC AdapterB-PON, PON TC Adapter or Interworking VCC Termination Point
managed entity.
Relationship to Priority QueueB-PON /Traffic Descriptor Profile Pointer: see attribute definition.
Relationship to UPC Disagreement Monitoring History DataB-PON: one or zero implied in the
managed entity id of UPC Disagreement Monitoring History DataB-PON.
This managed entity is related to the ATM VC Cross-Connection managed entity through the
Termination Point ANI/UNI side attributes of the ATM VC Cross-Connection managed entity.
224 ITU-T Rec. G.983.2 (07/2005)

Attributes
that is unique over all Network CTPB-PON MEs, of both VP and VC type. (R, Set-by-create)
VPI Value: This attribute identifies the VPI value associated with the VC link being terminated.
VCI Value: This attribute identifies the VCI value associated with the VC link being terminated.
The combination of VPI and VCI values must be unique over any ANI or UNI.
UNI/ANI Pointer: This attribute associates the VC Network CTPB-PON with the ANI (i.e., PON
interface) or a UNI. It points to the connected ANI/UNI instance id.
NOTE – For the case using the multiplexing function of AAL 2 (i.e., multiple instances of UNI are
associated with a VC Network CTPB-PON instance), this attribute is assigned a special value:
– 0x00XX will be used for pseudo slotIDs;
– 0xXX00 will be used for pseudo portIDs.
Therefore, 0x0000 will be used only for integrated interfaces (integrated type of ONT) that
support multiple AAL 2 functions. (R, Set-by-create) (mandatory) (2 bytes)
Direction: This attribute specifies whether the VC link is used for UNI-to-ANI (value 0x01),
ANI to-UNI (value 0x02), or bidirectional (value 0x03) connection. (R, W, Set-by-create)
Priority Queue Pointer for downstream: This attribute points to the instance of the Priority
QueueB-PON used for this VC Network CTPB-PON in the downstream direction. Note that the value
of this pointer is null when the VC Network CTPB-PON is at the ANI side. (R, Set-by-create)
Traffic management Pointer for upstream: This attribute points to the instance of the Priority
QueueB-PON or T-CONT used for this VC Network CTPB-PON in the upstream direction. It is used
when the UNI/ANI pointer indicates an ANI instance id. If the Traffic Management Option
attribute in ONTB-PON is 0x00, then this pointer indicates the Priority Queue serving this
VC CTP. If the Traffic Management Option attribute in ONTB-PON is 0x01, then this pointer
indicates the T-CONT serving this VC CTP. (R, Set-by-create) (mandatory) (2 bytes)
Traffic Descriptor Profile Pointer: This attribute serves as a pointer to the instance of the
Traffic Descriptor Profile managed entity that contains the traffic parameters used for this
VC Network CTPB-PON. This attribute is used when the Traffic Management Option attribute in
ONTB-PON is 0x01. It applies to the UNI side VC Network CTPB-PON if UPC is used. In this case,
this pointer points to a Traffic Descriptor managed entity.
When traffic shaping is used, it applies to the ANI side VC Network CTPB-PON. In this case, this
pointer points to a Traffic Descriptor Profile managed entity and the Priority Queue Pointer for
the upstream attribute is null. (R, Set-by-create) (optional) (2 bytes)
Actions
ITU-T Rec. G.983.2 (07/2005) 225

Notifications
Alarm: This notification is used to notify the management system for the ATM Layer
Management Indication (LMI) when an alarm has been detected or cleared. The OLT should
know the alarm list used by this entity. The alarm list for this entity is given in Table 40. See also
Appendix III. Note that in the case where an Interworking VCC Termination Point ME is
directly associated with this CTP, these alarms are suppressed on the CTP.
Table 40/G.983.2 − Alarm list for VC network CTPB-PON

0 VC-AIS-LMIR VC-AIS receiving indication (optional)
1 VC-RDI-LMIR VC-RDI receiving indication (optional)
2 VC-AIS-LMIG VC-AIS generation indication (optional)
3 VC-RDI-LMIG VC-RDI generation indication (optional)
4 Segment Loss of Continuity Loss of continuity is detected when the VC Network
CTPB-PON is a segment end point (optional)
5 End-to-End Loss of Loss of continuity is detected when the VC Network
Continuity CTPB-PON supports an Interworking VCC Termination
Point (optional)
6-223 Reserved
7.4.5 ATM VC cross-connection

For point-to-point ATM VC Cross-Connections, this managed entity is used to represent the
cross-connect relationship between two VC Network CTPB-PONs. For multipoint ATM VC
Cross-Connections, which are optional, the use of this managed entity is for further study.
Instances of this managed entity shall be created and deleted by the OLT based on ATM connection
set up.
Relationships
Zero or more instances of the ATM VC Cross-Connection managed entity shall exist for each
instance of the ONTB-PON managed entity.
Attributes
entity. This 2-byte number is directly associated with the instance identifier of the VC Network
CTPB-PON at the ANI side of this ATM VC cross-connect. (R, Set-by-create) (mandatory)
(2 bytes)
Termination Point ANI side: This attribute identifies the instance of the VC Network CTPB-PON
managed entity that represents the cross-connected VC Network CTPB-PONs on the ANI side.
Termination Point UNI side: This attribute identifies the instance of the VC Network CTPB-PON
managed entity that represents the cross-connected VC Network CTPB-PONs on the UNI side.
226 ITU-T Rec. G.983.2 (07/2005)

the functions performed by instances of this managed entity. (R, W, Set-by-create) (mandatory)
(1 byte)
Actions
Create complete connection: Create two instances of the VC Network CTPB-PON managed
entity (ANI-side and UNI-side) and one instance of the ATM VC Cross-Connection managed
entity.
Delete complete connection: Delete two instances of the VC Network CTPB-PON managed entity
(ANI-side and UNI-side) and one instance of the ATM VC Cross-Connection managed entity.
Get: Get attributes of this managed entity.
Get complete connection: Get all attributes of a connection; this holds the attributes of two
instances of the VC Network CTPB-PON managed entity (ANI-side and UNI-side) and the
attributes of the corresponding ATM VC Cross-Connection managed entity.
Notifications
managed entity is given in Table 41.
Table 41/G.983.2 − AVC list for ATM VC cross-connection

1 N/A
2 N/A
4 N/A
5-16 Reserved
7.4.6 VC PM history data

This managed entity is used to collect and report performance monitoring data associated with a
VCC for the last completed 15-minute interval. The instances of this managed entity are created and
deleted on request of the OLT. Note that these processes supercede the in-band PM OAM functions.
Relationships
Zero or more instances of this managed entity may exist for each instance of the VC Network
CTPB-PON managed entity. If the instance is associated with the ANI-side VP CTP, then the
performance of the downstream ATM flows is reported. If the instance is associated with the
UNI-side VP CTP, then the performance of the upstream ATM flows is reported.
Attributes
entity. The assigned number is the same as the Managed Entity id of the corresponding VC
Network CTPB-PON. (R, Set-by-create) (mandatory) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 227

Lost C = 0 + 1 Cells: This attribute measures background cell loss. It cannot distinguish between
overflows. It records only loss of information independent of the priority of the cell. If the actual
counter saturates, it remains on its maximum value. (R) (mandatory) (2 bytes)
Lost C = 0 Cells: This attribute measures background cell loss. It cannot distinguish between
overflows. It records only loss of high priority cells. If the actual counter saturates, it remains on
its maximum value. (R) (mandatory) (2 bytes)
Misinserted Cells: This attribute is used to measure occurrences of when a cell is misrouted to
an active VC that is being monitored. If the actual counter saturates, it remains on its maximum
value. (R) (mandatory) (2 bytes)
Transmitted C = 0 + 1 Cells: This attribute provides a count of all cells that are originated at a
monitored connection by the transmitting end point (i.e., backward reporting is assumed).
Transmitted C = 0 Cells: This attribute provides a count of all high priority cells that are
originated at a monitored connection by the transmitting end point (i.e., backward reporting is
assumed). (R) (mandatory) (5 bytes)
Impaired Block: This severely errored cell block counter will be incremented whenever one of
the following events takes place: the number of misinserted cells exceeds Mmisinserted, the number
of bipolar violations exceeds Merrored, or the number of lost cells exceeds Mlost. The values for
Mmisinserted, Merrored, and Mlost are set based on vendor-operator negotiation. (R) (mandatory)
(2 bytes)
Actions
228 ITU-T Rec. G.983.2 (07/2005)

Notifications
know the event list used by this entity, given in Table 42.
Table 42/G.983.2 − Alarm list for VC PM history data

Threshold data
counter # (Note)
0 Lost CLP=0+ 1 Cells Exceeds threshold 1
1 Lost CLP=0 Cells Exceeds threshold 2
2 Misinserted Cells Exceeds threshold 3
3 Impaired Blocks Exceeds threshold 4
4-223 Reserved
7.5 Traffic management

7.5.1 Priority QueueB-PON
This managed entity specifies the priority queue in the ONT that is used for the VP Network
CTPB-PON. All the Priority Queues used for the upstream traffic are created by the ONT after
initialization. All the Priority Queues used for the downstream traffic are created/deleted by the
ONT after the creation/deletion of the Subscriber Line Card.
The following assumption is made in order to simplify the queue management: the maximum
number of priority queues supported by an ONT, Subscriber Line Card or PON IF Line Card is 32
(the maximum number is 256 in the case of DBA support). If N priority queues reside in the ONT,
the Subscriber Line Card or PON IF Line Card, N Priority QueueB-PON managed entities will be
automatically created by the ONT following the creation of the related equipment. Note that the
OLT will find all the queues by reading the Priority QueueB-PON managed entity instances. If the
OLT tries to retrieve a non-existing Priority QueueB-PON, this will be indicated in the response from
the ONT to the OLT.
One or more Priority Queue should be created in the PON IF Linecard in order to guarantee the
backward compatibility with the G.983.2 ONT.
Priority queues can exist in the ONT core and subscriber line cards as well as PON IF Line Cards.
Therefore the managed entity id definition is extended for DBA applications.
In order to have a flexible connection and configuration between the priority queues and Traffic
Schedulers and T-CONT buffers new attributes are added for DBA applications.
Relationships
One or more instances of this managed entity shall be contained in the ONTB-PON managed entity
to model the upstream direction if the Traffic Management Option attribute in ONT is 0x00.
ITU-T Rec. G.983.2 (07/2005) 229

One or more instances of this managed entity shall be associated with the Subscriber Line Card
managed entity as downstream Priority QueueB-PON.
Attributes
Managed Entity id: Non-DBA definition: This attribute provides a unique number for each
instance of this managed entity. The first byte is the slot id of the Subscriber Line Card or PON
IF card with which this queue is associated. The second byte is the priority of this queue
(0x00 indicates the highest priority, and 0x1F (31) the lowest).
DBA definition: This attribute provides a unique number for each instance of this managed
entity. The first byte is the slot id of the Subscriber Line Card or PON IF card with which this
queue is associated. For integrated Subscriber Line/PON IF interfaces, this byte can be
associated with "pseudo" slot ids 0x00, 0x80 (128), respectively. If the ONT has upstream
priority queues that are not associated with the PON IF card at the creation of this instance, the
first byte of this priority queue is 0xFF. The second byte is the priority of this queue
(0x00 indicates the highest priority, and 0xFF (255) the lowest). The second byte is numbered by
the ONT itself.
In either definition, the priority rank of the queues applies on a per-port or per-T-CONT basis.
Congestion on one port or T-CONT will not block traffic being delivered to other ports or
T-CONTs. (R) (mandatory) (2 bytes)
Queue Configuration Option: This attribute identifies the buffer-partitioning policy. The value
of 0x01 means that all the queues share one buffer size of Maximum Queue Size and the value
0x00 means that each queue uses its individual buffer size of Maximum Queue Size. (R)
Maximum Queue Size: This attribute specifies the maximum size of the queue. (R) (mandatory)
(2 bytes)
Allocated Queue Size: This attribute identifies the allocated size of this queue. (R, W)
Discard-cell-counter reset interval: This attribute represents the interval in milliseconds at
which the counter resets itself. (R, W) (optional) (2 bytes)
Threshold value for discarded cells due to buffer overflow: The threshold for the number of
cells discarded on this queue due to buffer overflow. (R, W) (optional) (2 bytes)
Back Pressure Operation: This attribute is used to activate (enable: value 0x00) or deactivate
(disable: value 0x01) the functions of Back Pressure operation. Default value is 0x00. (R, W)
(mandatory if Back Pressure supported) (2 bytes)
Back Pressure Time: This attribute indicates the time duration in which the customer terminal
temporarily suspends sending data. This attribute presents the duration in microseconds. This
attribute can be used as a pause time for Ether UNI. Values: 0x00000000 to 0xFFFFFFFF. Upon
autonomous instantiation, the value 0x00000000 is used. (R, W) (mandatory if Back Pressure
supported) (4 bytes)
Back Pressure occur Queue Threshold: This attribute identifies the threshold size of this queue
to start sending Back Pressure signal. (R, W) (mandatory if Back Pressure supported) (2 bytes)
Back Pressure clear Queue Threshold: This attribute identifies the threshold size of this queue
to stop sending Back Pressure signal. (R, W) (mandatory if Back Pressure supported) (2 bytes)
T-CONT buffer pointer: This attribute represents the T-CONT buffer instance that is directly
associated with this priority queue. Upon autonomous instantiation this attribute consists of the
0x8000, 0x8100 or 0xYY00. 0xYY is the first byte of this Managed Entity id. (The default value
should be decided in consideration of the backward compatibility.) It is used when this priority
230 ITU-T Rec. G.983.2 (07/2005)

queue is contained by a T-CONT buffer directly, this pointer is null (0x0000) otherwise. (R, W)
(mandatory if DBA supported) (2 bytes)
Traffic Scheduler pointer: This attribute represents the Traffic Scheduler instance that is
directly associated with this priority queue. Upon autonomous instantiation this attribute is null
(0x0000). This pointer is used when this priority queue is connected with a Traffic Scheduler.
(R, W) (mandatory if DBA supported) (2 bytes)
Weight: This attribute represents weight for WRR. This weight is used by the Traffic Scheduler
or T-CONT buffer (whose Policy is WRR) indicated by the Traffic Scheduler pointer or
T-CONT buffer pointer, if present. Upon autonomous instantiation this attribute consists of the
0x01. (R, W) (mandatory if DBA supported) (1 byte)
Actions
Notifications
attributes of this managed entity. The notification shall identify the attribute that changed and its
new value.
threshold crossing alert (TCA) has been detected or cleared. Both ONT and OLT should know
the event coding used by this entity. The event list for this entity is given in Table 43.
Table 43/G.983.2 − Alarm list for Priority QueueB-PON

0 Cell loss Exceeds threshold
1-223 Reserved
7.5.2 Traffic descriptors

ATM transfer capabilities (ATCs) are defined in ITU-T Rec. I.371 [7]. These are Deterministic Bit
Rate (DBR), Statistical Bit Rate (SBR), ATM Block Transfer with Delayed Transmission
(ABT/DT), ATM Block Transfer with Immediate Transmission (ABT/IT), Available Bit Rate
(ABR), and Guaranteed Frame Rate (GFR).
[B-9] has defined analogous Service Categories. These are Constant Bit Rate (CBR), Real-time
Variable Bit Rate (rt-VBR), Non-Real-Time VBR (nrt-VBR), Unspecified Bit Rate (UBR),
Available Bit Rate (ABR), and Guaranteed Frame Rate (GFR).
Both the ITU-T SBR ATC and the ATM Forum VBR service categories may be further subdivided
into 3 categories. These are taken to be separate ATCs or Service Categories and are designated by
adding the numeral 1, 2, or 3 to the VBR or SBR acronym. For VBR1 and SBR1, the cell loss ratio
(CLR) performance objective is applied to the aggregate traffic in the connection. For VBR2 and
SBR2, the CLR objectives are applied only to cells with the cell loss priority (CLP) bit set to 0x00,
and there is no tagging of cells. For VBR3 and SBR3, the CLR objective is applied only to cells
with the cell loss priority (CLP) bit set to 0x00, and there is tagging of cells.
The plausible approximate correspondence among ITU-T ATC and the service categories in [B-9]
is shown in Table 44.
ITU-T Rec. G.983.2 (07/2005) 231

Table 44/G.983.2 − Traffic descriptors
ITU [B-9] Traffic descriptor in G.983.2
DBR [1] CBR CBR/DBR Traffic Descriptor
DBR [U] UBR UBR Traffic Descriptor
SBR1 [2] VBR1 SBR1/VBR1 Traffic Descriptor
SBR2 [1]/[3] VBR2 SBR2/VBR2 Traffic Descriptor
SBR3 [3] VBR3 SBR3/VBR3 Traffic Descriptor
ABR ABR ABR Traffic Descriptor
GFR GFR GFR Traffic Descriptor
ABT/DT ABT/DT/IT Traffic Descriptor
ABT/IT
The attribute value units used in the Traffic Descriptors in the following clauses are identical to the
ones defined in ITU-T Rec. I.751 [9]. See also References [12] and [7] for a full discussion of
traffic attributes.
Note carefully that all the traffic descriptor managed entities in an ONT must have a unique
number, regardless of type.
7.5.2.1 DBR/CBR traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream DBR/CBR virtual path
connections.
Instances of this managed entity are created and deleted by the OLT.
Relationships
Zero or more instances of this managed entity may be contained in an instance of an ONTB-PON
managed entity.
Each instance of this entity may be related to zero or more instances of VP Network CTPB-PON
entities through their pointer attribute: Traffic Descriptor Profile Pointer.
Attributes
that is unique over all the traffic descriptors regardless of type. (R, Set-by-create) (mandatory)
(2 bytes)
Service Category/ATC: Value 0x00 is used for DBR/CBR. (R, Set-by-create) (mandatory)
(1 byte)
Peak Cell Rate: Peak Cell Rate for the CLP = 0 + 1 traffic flow. Unit is an integer number of
cells/second. (R, Set-by-create) (mandatory) (4 bytes)
Cell Delay Variation Tolerance in relation to the PCR: Cell Delay Variation Tolerance in
relation to the PCR for the CLP = 0 + 1 traffic flow. Unit is in microseconds. (R, Set-by-Create)
CLR: Maximum permissible Cell Loss Ratio for the CLP = 0 + 1 traffic flow. (R, Set-by-create)
Actions
232 ITU-T Rec. G.983.2 (07/2005)

Notifications
None.
7.5.2.2 UBR traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream UBR virtual path
connections.
Relationships
managed entity.
Attributes
(2 bytes)
Service Category/ATC: Value 0x01 is used for UBR/DBR[U]. (R, Set-by-create) (mandatory)
(1 byte)
relation to the PCR for the CLP = 0 + 1 traffic flow. Unit is in microseconds. (R, Set-by-create)
FrameDiscard: This boolean attribute allows the indication of frame-aware handling. If set to
'false', no special handling is requested. If set to 'true', then the ONU is requested to treat data for
this connection as frames (e.g., AAL 5 CPCS_PDUs) rather than as individual cells. The
treatment must be on a per-VC basis. While the precise implementation is equipment-specific,
this treatment may for example involve discarding entire frames during congestion, rather than a
few cells from many frames. (R, W, Set-by-create) (optional) (1 byte)
Actions
Notifications
None.
7.5.2.3 SBR1/VBR1 traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream SBR1/VBR1 virtual path
connections.
ITU-T Rec. G.983.2 (07/2005) 233

Relationships
managed entity.
Attributes
(2 bytes)
Service Category/ATC: Value 0x02 is used for SBR1, value 0x03 is used for Real-time VBR1,
and value 0x04 is used for Non Real-time VBR1. (R, Set-by-create) (mandatory) (1 byte)
Sustainable Cell Rate: Sustainable Cell Rate for the CLP = 0 + 1 traffic flow. Unit is an integer
number of cells/second. (R, Set-by-create) (mandatory) (4 bytes)
Maximum Burst Size: Maximum Burst Size for the CLP = 0 + 1 traffic flow. Unit is an integer
number of cells. (R, Set-by-create) (mandatory) (2 bytes)
Cell Delay Variation Tolerance in relation to the SCR: Cell Delay Variation Tolerance in
relation to the SCR for the CLP = 0 + 1 traffic flow. Unit is in microseconds. (R, Set-by-create)
CLR: Maximum permissible Cell Loss Ratio for the CLP = 0 + 1 traffic flow. (R, Set-by-create)
Actions
Notifications
None.
connections.
234 ITU-T Rec. G.983.2 (07/2005)

Relationships
managed entity.
Attributes
(2 bytes)
Service Category/ATC: Value 0x05 is used for SBR2, value 0x06 is used for real-time VBR2,
and value 0x07 is used for non-real-time VBR2. (R, Set-by-create) (mandatory) (1 byte)
Sustainable Cell Rate: Sustainable Cell Rate for the CLP = 0 traffic flow. Unit is an integer
Maximum Burst Size: Maximum Burst Size for the CLP = 0 traffic flow. Unit is an integer
relation to the SCR for the CLP = 0 traffic flow. Unit is in microseconds. (R, Set-by-create)
CLR: Maximum permissible Cell Loss Ratio for the CLP = 0 traffic flow. (R, Set-by-create)
Actions
Notifications
None.
connections.
ITU-T Rec. G.983.2 (07/2005) 235

Relationships
managed entity.
Attributes
(2 bytes)
Service Category/ATC: Value 0x08 is used for SBR3, value 0x09 is used for real-time VBR3,
and value 0x0A is used for non-real-time VBR3. (R, Set-by-create) (mandatory) (1 byte)
Sustainable Cell Rate: Sustainable Cell Rate for the CLP = 0 traffic flow. Unit is an integer
Maximum Burst Size: Maximum Burst Size for the CLP = 0 traffic flow. Unit is an integer
CLR: Maximum permissible Cell Loss Ratio for the CLP = 0 traffic flow. (R, Set-by-create)
Actions
Notifications
None.
7.5.2.6 ABR traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream ABR virtual path
connections.
236 ITU-T Rec. G.983.2 (07/2005)

Relationships
managed entity.
managed entities through their pointer attribute: Traffic Descriptor Profile Pointer.
Attributes
(2 bytes)
Service Category/ATC: Value 0x0B is used for ABR. (R, Set-by-create) (mandatory) (1 byte)
Peak Cell Rate: Peak Cell Rate for the CLP = 0 traffic flow. Unit is an integer number of
relation to the PCR for the CLP = 0 traffic flow. Unit is in microseconds. (R, Set-by-create)
Minimum Cell Rate: Minimum Cell Rate for the CLP = 0 traffic flow. Unit is an integer
Initial Cell Rate: Rate at which a source should send initially and after an idle period. The unit
is an integer number of cells/second. The value must not exceed PCR and is usually lower.
(R, Set-by-create) (optional) (4 bytes)
Transient Buffer Exposure: These parameters are required for ABR traffic. (R, Set-by-create)
Rate Decrease Factor: Controls the rate decrease that occurs when backward RM cells with
CI = 1 are received. Allowed values are 1/2k, with k between 0 and 15. The coding of the
attribute is according to the value of k. (R, Set-by-create) (optional) (1 byte)
Rate Increase Factor: Controls the rate increase that occurs when a backward RM cell is
received with CI = 0 and NI = 0. Allowed values are 1/2k, with k between 0 and 15. The coding
of the attribute is according to the value of k. (R, Set-by-create) (optional) (1 byte)
Fixed Round Trip Time: The sum of the fixed and propagation delays (in ms) from the source
to the destination and back. (R, Set-by-create) (optional) (2 bytes)
Number RM: The maximum number of data cells a source may send for each forward RM cell.
Allowed values are 2k, where k is used as the code and is between 1 and 8. (R, Set-by-create)
(optional) (1 byte)
Time RM: Upper bound on the time (in ms) between forward RM cells for an active source.
Allowed values are computed as 100/2k, where k is used as the code and is between 0 and 7. The
default is k = 0. (R, Set-by-create) (optional) (1 byte)
Cut-off Decrease Factor: Controls the rate decreases associated with lost or delayed backward
RM cells. Allowed values are: 1/26 (value 0x07), 1/25 (value 0x06), 1/24 (value 0x05), 1/23
(value 0x04), 1/22 (value 0x03), 1/2 (value 0x02), 0x01 (value 0x01) and 0x00 (value 0).
ACR Decrease Time Factor: Time permitted between sending RM cells before the rate
decreases to ICR. The range is from 10 ms to 10.23 s in increments of milliseconds.
(R, Set-by-create) (optional) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 237

Actions
Notifications
None.
7.5.2.7 ABT/DT/IT traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream ABT/DT/IT virtual path
connections.
Relationships
managed entity.
managed entities through its pointer attribute: Traffic Descriptor Profile Pointer.
Attributes
(2 bytes)
Service Category/ATC: Value 0x0C is used for ABT/DT; value 0x0D is used for ABT/IT.
number of cells/second. (R, Set-by-create) (optional) (4 bytes)
number of cells. (R, Set-by-create) (optional) (2 bytes)
relation to the SCR for the CLP = 0 + 1 traffic flow. Unit is in microseconds. (R, Set-by-create)
Number RM: The maximum number of data cells a source may send for each forward RM cell.
Allowed values are 2k, where k is used as the code and is between 0x01 and 0x08.
238 ITU-T Rec. G.983.2 (07/2005)

Time RM: Upper bound on the time between forward RM cells for an active source. Allowed
values are computed as 100/2k, where k is used as the code and is between 0x00 and 0x07. The
default is k = 0. (R, Set-by-create) (optional) (1 byte)
Actions
Notifications
None.
7.5.2.8 GFR traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream GFR virtual path
connections.
Relationships
managed entity.
managed entities through their pointer attribute: Traffic Descriptor Profile Pointer.
Attributes
(2 bytes)
Service Category/ATC: Value 0x0E is used for GFR. (R, Set-by-create) (mandatory) (1 byte)
number of cells/second. (R, Set-by-create) (optional) (4 bytes)
number of cells. (R, Set-by-create) (optional) (2 bytes)
ITU-T Rec. G.983.2 (07/2005) 239

Maximum Frame size: Maximum Frame size for GFR traffic. Unit is an integer number of
cells. (R, Set-by-create) (optional) (2 bytes)
Minimum Cell Rate: Minimum Cell Rate for the CLP = 0 traffic flow. Unit is an integer
Actions
Notifications
None.
7.5.2.9 UBR+ traffic descriptor
This managed entity specifies traffic and QoS parameters for upstream UBR+ virtual path
connections. Instances of this managed entity are created and deleted by the OLT.
Relationships
managed entity. Each instance of this entity may be related to zero or more instances of VP
Network CTPB-PON managed entities through their pointer attribute: Traffic Descriptor Profile
Pointer.
Attributes
(2 bytes)
Service Category/ATC: Value 0x0F is used for UBR+ [U]. (R, Set-by-create) (mandatory)
(1 byte)
Minimum Cell Rate: Minimum guaranteed cell rate. Unit is an integer number of cells/second.
this treatment may for example, involve discarding entire frames during congestion, rather than a
240 ITU-T Rec. G.983.2 (07/2005)

Actions
Notifications
None.
7.5.3 This clause intentionally left blank
7.5.4 UPC Disagreement Monitoring History DataB-PON
An instance of this managed entity is used to collect and report the last completed 15-minute
interval data associated with UPC Disagreement Monitoring functions performed by the ONT on
individual VP Network CTPB-PON or VC Network CTPB-PON managed entities in ONTB-PON. The
instances of this managed entity are created and deleted by the OLT.
Relationships
One instance of this managed entity may exist for each instance of a VP Network CTPB-PON or
VC Network CTPB-PON managed entity instantiated at the UNI side.
Attributes
entity. The assigned number is the same as the Managed Entity id of the corresponding VP
Network CTPB-PON or VC Network CTPB-PON. (R, Set-by-create) (mandatory) (2 bytes)
Interval End Time: This attribute identifies the most recent finished 15-minute interval. It is a
Discarded Cells due to UPC: This attribute provides a raw, thresholded count of the number of
discarded cells due to combined CLP = 0 and CLP = 1 UPC policing. If the actual counter
Discarded CLP = 0 Cells due to UPC: This attribute provides a raw, thresholded count of the
number of discarded CLP = 0 cells due to CLP = 0 only UPC policing. This counter is only
present if CLP = 0 traffic is separately policed. If the actual counter saturates, it remains on its
Tagged CLP = 0 Cells: This attribute provides a raw, unthresholded count of the number of
cells that have been tagged. If the actual counter saturates, it remains on its maximum value.
Successfully Passed Cells: This attribute provides a raw, unthresholded count of the number of
cells that have been passed by the combined CLP=0+1 UPC policing. (R) (mandatory) (5 bytes)
ITU-T Rec. G.983.2 (07/2005) 241

Successfully Passed CLP = 0 Cells: This attribute provides a raw, unthresholded count of the
number of high priority cells that have been passed by the CLP=0 UPC policing.
Actions
Notifications
know the alarm list used by this entity, given in Table 45.
Table 45/G.983.2 − Alarm list for UPC disagreement monitoring history data B-PON
Threshold data
counter # (Note)
0 Discarded Cells due to UPC Exceeds threshold 1
1 Discarded CLP = 0 Cells due to UPC Exceeds threshold 2
2-223 Reserved
7.5.5 Traffic scheduler

An instance of this managed entity represents a logical object of some Traffic Scheduler to control
upstream ATM cells. A Traffic Scheduler can accommodate ATM cells after priority queue or other
Traffic Scheduler and transfer ATM cells toward the next Traffic Scheduler or T-CONT buffer.
Relationships
Zero or more instances of this managed entity are contained in an instance of the ONT managed
entity.
Attributes
entity. This 2-byte number is associated with the physical capability that realizes the Traffic
242 ITU-T Rec. G.983.2 (07/2005)

Scheduler. The first byte is the slot id of the PON IF card with which this Traffic Scheduler is
associated. For integrated PON IF interfaces, this byte can be associated with "pseudo" slot id
0x80 (128). If the ONT has Traffic Schedulers that are not associated with the PON IF card at
the creation of this instance, the first byte of this Traffic Scheduler is 0xFF. The second byte is
the Traffic Scheduler id that is numbered by the ONT itself. The Traffic Scheduler id is
numbered in ascending order with the range of 0x00 to 0xFF in each PON-IF Line Card or ONT
core. (R) (mandatory) (2 bytes)
T-CONT Buffer pointer: This attribute represents the T-CONT Buffer instance that is directly
associated with this Traffic Scheduler. Upon autonomous instantiation this attribute consists of
the 0x8000, 0x8100 or 0xYY00. 0xYY is the first byte of this Managed Entity ID. (The default
value should be decided in consideration of the backward compatibility.) This pointer is used
when this Traffic Scheduler is contained by the T-CONT buffer directly, it is null (0x0000)
otherwise. (R) (mandatory) (2 bytes)
Traffic Scheduler pointer: This attribute represents the Traffic Scheduler instance that serves
this Traffic Scheduler. Upon autonomous instantiation this attribute is null (0x0000). This
pointer is used when this Traffic Scheduler is connected to the another Traffic Scheduler, it is
null otherwise. (The default value should be decided in consideration of the backward
compatibility.) (R) (mandatory) (2 bytes)
Policy: This attribute represents scheduling policy. Valid values include but are not limited to
"Null"(value 0x00), "HOL"(value 0x01) or "WRR"(value 0x02). Upon autonomous instantiation
this attribute consists of the 0x00. (R) (mandatory) (1 byte)
Priority/Weight: This attribute represents priority for HOL scheduling or the weight for
WRR scheduling. This value is used by the T-CONT buffer or Traffic Scheduler indicated by the
T-CONT buffer pointer or Traffic Scheduler pointer. If the indicated pointer has Policy = HOL,
then this value is interpreted as a priority (0x00 indicates the highest priority, and 0xFF (255) the
lowest). If the indicated pointer has Policy = WRR, then this value is interpreted as a weight.
Upon autonomous instantiation this attribute consists of the 0x00. (R, W) (mandatory) (1 byte)
Actions
Notifications
Attribute Value Change: This notification is used to report autonomous changes of attributes of
this managed entity. The notification shall identify its new value.
8 ONT Management and Control Channel (OMCC)

An ATM connection shall be provisioned for the OMCC. ITU-T Rec. G.983.1 [3] specifies a
PLOAM message that activates a VPI/VCI pair between the OLT and ONT processors. The
VPI/VCI value for the management channel of each is programmed by the OLT using this message.
The OMCCs of different ONTs should be assigned different VPIs. A grant flow must be allocated
by the MAC layer of the OLT for upstream OMCC traffic of each ONT.
The following performance requirements related to the OMCC should be studied further with input
from operators:
a) The cells carrying ONT management messages should be sent with cell loss priority
CLP = 0.
b) The upstream traffic on each OMCC should not exceed x bandwidth, where x is based on
the operator's requirement.
ITU-T Rec. G.983.2 (07/2005) 243

c) An upstream OMCC cell should always be put in the high priority queue or be modelled
with the CBR service category; the constraints on the downstream OMCC cells are out of
the scope of the Recommendation as this is completely under control of the OLT.
d) Message Response Time: The system should support response times that do not exceed 1 s
for the high priority protocol handling messages and 3 s for the low priority protocol
handling messages.
9 ONT management and control protocol
9.1 ONT management and control protocol cell format

9.1.1 Introduction
Each ONT Management and Control Protocol packet is encapsulated directly in a single 53-byte
ATM cell. The cell format is shown in Figure 41. The following clauses discuss the details.
ATM Transaction Message Device Message Message AAL 5

Header Correlation Type Identifier Identifier Contents Trailer
(5 bytes) Identifier (1 byte) (1 byte) (3 bytes) (33 bytes) (8 bytes)
(2 bytes)
Figure 41/G.983.2 − ONT management and control protocol cell format
9.1.2 ATM header

The header contains the VPI/VCI value of the OMCC for the addressed ONT (see clause 8).
The header PTI should equal 001. The CLP bit should equal 0.
The HEC should be calculated using the normal ATM CRC-8 polynomial.
9.1.3 Transaction correlation identifier
The Transaction Correlation Identifier is used to associate a request message with its response
message. For request messages, the OLT selects any transaction identifier. A response message
carries the transaction identifier of the message to which it is responding. The transaction identifier
of event messages is 0x0000.
As explained in 9.2 Message Flow Control and Error Recovery, the most significant bit of the
Transaction Correlation Identifier is used to indicate the priority of the message. The following
coding will be used: 0 = low priority, 1 = high priority. The OLT decides whether a command
should be executed with low or high priority.
The mechanism that the OLT uses to assign the rest of the bits of the Transaction Correlation
Identifier in an acknowledged command is not standardized and is left to the implementers.
However, since the Transaction Correlation Identifier is used to match a command from the OLT to
the ONT with a response from the ONT to the OLT, some care is required in the choice of the
Transaction Correlation Identifier. The OLT must assign the Transaction Correlation Identifier in
such a way that, whenever it sends a command with a Transaction Correlation Identifier that has
been used before in another command to the same ONT, it is guaranteed with sufficiently high
probability that no response for the first command will be received.
244 ITU-T Rec. G.983.2 (07/2005)

9.1.4 Message type
The Message Type field is subdivided into four parts. These are given in Figure 42.
8 7 6 5 1
DB AR AK MT
Figure 42/G.983.2 − Message type field subdivision
The most significant bit, bit 8, is reserved for the destination bit (DB). In the OMCI this bit is
always 0.
Bit 7, Acknowledge Request (AR), is used to indicate whether or not the message requires an
acknowledgement. If an acknowledgement is expected, this bit is set to "1". If no acknowledgement
is expected, the coding of this bit is "0". Note that "acknowledge" means a response to an action
request, not an acknowledgement at the link layer.
Bit 6, Acknowledgement (AK), is used to indicate whether or not this message is an
acknowledgement to an action request. If a message is an acknowledgement, this bit is set to "1". If
the message is not a response, this bit is set to "0".
Bit 5 to bit 1, Message Type (MT), are used to indicate the message type. Codes 0 to 3 are reserved
for future use. Codes 4 to 31 are used by this Recommendation. Table 46 lists the message types
that are defined.
Table 46/G.983.2 − OMCI message types

Inc MIB
MT Type Purpose AK
data sync.
4 Create Create a managed entity instance with its attributes yes yes
5 Create complete Create an ATM VP Cross-Connection and two yes yes
connection associated VP Network CTPB-PONs or create an ATM
VC Cross-Connection and two associated VC
Network CTPB-PONs
6 Delete Delete a managed entity instance yes yes
7 Delete complete Delete an ATM VP Cross-Connection and two yes yes
connection associated VP Network CTPB-PONs or delete an
ATM VC Cross-Connection and two associated VC
Network CTPB-PONs
8 Set Set one or more attributes of a managed entity yes yes
9 Get Get one or more attributes of a managed entity yes no
10 Get complete Get all attributes of an ATM VP Cross-Connection yes no
connection and the attributes of the associated VP Network
CTPB-PONs
11 Get all alarms Latch the alarm statuses of all managed entities and yes no
reset the alarm message counter
12 Get all alarms next Get the alarm status of the next managed entity yes no
13 MIB upload Latch the MIB yes no
14 MIB upload next Get latched attributes of a managed entity instance yes no
15 MIB reset Clear the MIB and reinitialize it to its default and yes no
reset the MIB data sync counter to 0
ITU-T Rec. G.983.2 (07/2005) 245

Table 46/G.983.2 − OMCI message types
Inc MIB
MT Type Purpose AK
data sync.
16 Alarm Notification of an alarm no no
17 Attribute value Notification of an autonomous attribute value change no no
change
18 Test Request a test on a specific managed entity yes no
19 Start software Start a software download action yes yes
download
20 Download section Download a section of a software image yes/no no
21 End software End of a software download action yes yes
download
22 Activate software Activate the downloaded software image yes yes
23 Commit software Commit the downloaded software image yes yes
24 Synchronize Time Synchronize the time between OLT and ONT yes no
25 Reboot Reboot ONT, Subscriber Line Card or PON IF Line yes no
Card
26 Get next Get the latched attribute values of the managed entity yes no
within the current snapshot
27 Test result Notification of test result that is initiated by "Test" no no
28 Get current data Get current counter value associated with one or yes no
more attributes of a managed entity
NOTE – The "Download section" action is only acknowledged for the last section within a window.
See Appendix I.2.15.
9.1.5 Device identifier

For systems based on ITU-T Rec. G.983.1 [3], this field is defined as 0x0A.
9.1.6 Message identifier
The message identifier consists of three bytes. The first, most significant, byte of the message
identifier field is used to indicate which managed entity is the target of the action specified in the
message type. The maximum number of possible managed entities is thus 256. The least significant
two bytes of this message identifier field are used to identify the managed entity instance. The
maximum number of instances per managed entity is thus 65 536.
Table 47 gives the managed entities and their class values in the OMCI. Depending on the managed
entity, there will be only one (e.g., ONTB-PON) or several (e.g., VP Network CTPB-PON) instances.
246 ITU-T Rec. G.983.2 (07/2005)

Table 47/G.983.2 − Managed entity identifiers
Managed entity class value Managed entity
1 ONTB-PON
2 ONT Data
3 PON IF Line Cardholder
4 PON IF Line Card
5 Subscriber Line Cardholder
6 Subscriber Line Card
7 Software Image
8 UNIB-PON
9 TC AdapterB-PON
10 Physical Path Termination Point ATM UNI
11 Physical Path Termination Point Ethernet UNI
12 Physical Path Termination Point CES UNI
13 Logical N × 64 kbit/s Sub-port Connection Termination Point
14 Interworking VCC Termination Point
15 AAL 1 ProfileB-PON
17 AAL 1 Protocol Monitoring History DataB-PON
18 AAL 5 Protocol Monitoring History DataB-PON
20 (intentionally left blank)
21 CES Service ProfileB-PON
23 CES Physical Interface Monitoring History Data
24 Ethernet Performance Monitoring History Data
25 VP Network CTPB-PON
26 ATM VP Cross-Connection
27 Priority QueueB-PON
28 DBR/CBR Traffic Descriptor
29 UBR Traffic Descriptor
30 SBR1/VBR1 Traffic Descriptor
33 ABR Traffic Descriptor
34 GFR Traffic Descriptor
35 ABT/DT/IT Traffic Descriptor
36 UPC Disagreement Monitoring History DataB-PON
38 ANI
ITU-T Rec. G.983.2 (07/2005) 247

39 PON TC Adapter
40 PON Physical Path Termination Point
41 TC Adapter Protocol Monitoring History Data
42 Threshold DataB-PON
43 Operator Specific
44 Vendor Specific
45 MAC Bridge Service Profile
46 MAC Bridge Configuration Data
47 MAC Bridge Port Configuration Data
48 MAC Bridge Port Designation Data
49 MAC Bridge Port Filter Table Data
50 MAC Bridge Port Bridge Table Data
51 MAC Bridge PM History Data
52 MAC Bridge Port PM History Data
53 Physical Path Termination Point POTS UNI
54 Voice CTP
55 Voice PM History Data
56 AAL 2 PVC ProfileB-PON
57 AAL 2 CPS Protocol Monitoring History DataB-PON
58 Voice Service Profile AAL
59 LES Service Profile
60 AAL 2 SSCS Parameter Profile 1
61 AAL 2 SSCS Parameter Profile 2
62 VP PM History Data
63 Traffic Scheduler
64 T-CONT Buffer
65 UBR+ Traffic Descriptor
66 AAL 2 SSCS Protocol Monitoring History DataB-PON
67 IP Port Configuration Data
68 IP Router Service Profile
69 IP Router Configuration Data
70 IP Router PM History Data 1
71 IP Router PM History Data 2
72 ICMP PM History Data1
73 ICMP PM History Data 2
74 IP Route Table
75 IP Static Routes
76 ARP Service Profile
248 ITU-T Rec. G.983.2 (07/2005)

77 ARP Configuration Data
78 VLAN Tagging Operation Configuration Data
79 MAC Bridge Port Filter Preassign Table
80 Physical Path Termination Point ISDN UNI
81 (Reserved for Physical Path Termination Point HPNA UNI)
82 Physical Path Termination Point Video UNI
83 Physical Path Termination Point LCT UNI
84 VLAN Tagging Filter Data
85 ONUB-PON
86 ATM VC Cross-Connection
87 VC Network CTPB-PON
88 VC PM History Data
89 Ethernet Performance Monitoring History Data 2
90 Physical Path Termination Point Video ANI
91 Physical Path Termination Point 802.11 UNI
92 802.11 Station Management data 1
93 802.11 Station Management data 2
94 802.11 General Purpose Object
95 802.11 MAC&PHY Operation and Antenna Data
96 802.11 Counters
97 802.11 PHY FHSS DSSS IR Tables
98 Physical Path Termination Point ADSL UNI Part 1
99 Physical Path Termination Point ADSL UNI Part 2
100 ADSL Line Inventory and Status Data Part 1
101 ADSL Line Inventory and Status Data Part 2
102 ADSL Channel Downstream Status Data
103 ADSL Channel Upstream Status Data
104 ADSL Line Configuration Profile Part 1
107 ADSL Channel Configuration Profile
108 ADSL Subcarrier Masking Downstream Profile
109 ADSL Subcarrier Masking Upstream Profile
110 ADSL Downstream PSD Mask Profile
111 ADSL Downstream RFI Bands Profile
112 ADSL ATU-C Performance Monitoring History Data
113 ADSL ATU-R Performance Monitoring History Data
114 ADSL ATU-C Channel Performance Monitoring History Data
ITU-T Rec. G.983.2 (07/2005) 249

115 ADSL ATU-R Channel Performance Monitoring History Data
116 TC Adaptor Performance Monitoring History Data ADSL
117 Physical Path Termination Point VDSL UNI
118 VDSL VTU-O Physical Data
119 VDSL VTU-R Physical Data
120 VDSL Channel Data
121 VDSL Line Configuration Profile
122 VDSL Channel Configuration Profile
123 VDSL Band Plan Configuration Profile
124 VDSL VTU-O Physical Interface Monitoring History Data
125 VDSL VTU-R Physical Interface Monitoring History Data
126 VDSL VTU-O Channel Performance Monitoring History Data
127 VDSL VTU-R Channel Performance Monitoring History Data
128 Video Return Path Service Profile
129 Video Return Path Statistics
130 802.1p mapper service profile
131 OLTB-PON
132 Multicast Interworking VCC Termination Point
133-239 Reserved for future standardization
240-255 Vendor-Specific Entities, not to be standardized
9.1.7 Message contents

The layout of the message contents field is message specific. The detailed layout of all messages is
given in Appendix II.
9.1.8 AAL 5-trailer
The eight bytes of this field are used as follows:
a) The CPCS-User-to-User-Indication (CPCS-UU) field is set to 0x00 at the transmitter and
ignored at the receiver.
b) The CPCS Common Part Indication (CPCS-CPI) field is set to 0x00 at the transmitter and
ignored at the receiver.
c) The length of the CPCS-SDU field is set to 0x0028.
d) The 32-bit CRC is as specified in ITU-T Rec. I.363.5 [6].
9.1.9 OMCI protocol limitations
Due to the arrangement of the messages, the OMCI imposes limits on the size of the message
payloads. Table 48 lists the important limits for both B-PON and G-PON usages of the OMCI. To
enable re-use of managed entities over both B-PON and G-PON, it is important that all MEs are
defined such that they fit into the G-PON limits.
250 ITU-T Rec. G.983.2 (07/2005)

Table 48/G.983.2 – OMCI protocol limitations
Item Limited by B-PON limit G-PON limit
Total size of Set-by-Create Attributes (including Create 35 34
ME ID)
Size of (R) or (R,W) Simple Attribute Get-Response 26 25
Size of (R) or (R,W) Table Entry Set 31 30
Total size of a Get Get-Response 26 25
Total size of a Get-current data Get-Current Data 26 25
Response
It is important that the OLT and ONT implementations take these limits into account. For example,
it is very easy to form a 'get' command that asks the ONT to return more attributes than there is
space in the Response message. Specifically, there is a known issue where the OLT and ONT may
disagree on the maximum size limitation of the 'Get' response.
For the sake of maintaining backwards-compatibility, the behaviour when either the ONT or OLT
utilizes a 30-byte message contents field is described:
Case 1. The OLT implements a maximum attribute space of 26 bytes, while the ONT implements a
maximum attribute space of 30 bytes.
The OLT should not ask for attributes that exceed 26 bytes, so the ONT will just leave the
extra space blank. Even in the case where the OLT asks for too many attributes, it will get
an attribute mask that clarifies what is being sent and will ignore the attributes that extend
beyond the 26 bytes.
Case 2. The OLT uses a maximum attribute space of 30 bytes, while the ONT uses a maximum
attribute space of 26 bytes.
The OLT may ask for too many attributes, and the ONT can respond with however many
attributes fit in its 26-byte attribute space. The OLT will get the appropriate attribute-
present mask and will parse the attributes that were sent correctly. It will ask again later for
those attributes that did not fit.
While this is the preferred behaviour, an alternate interpretation may be that the ONT would return
a "parameter error" code when it receives a Get that does not fit in the Get Response. For the sake
of interoperability, the expected behaviour between and OLT and ONT with different
interpretations is provided below:
Case 1. The ONT reports a parameter error, and the OLT expects a partial list. If this happens, the
OLT should react by simplifying its Get request. The ONT will then respond without an
error.
Case 2. The ONT provides a partial list, while the OLT expects to get an error. The OLT will
receive a normal message and will process it normally. The OLT should ask again for any
attributes it did not get.
9.2 Message flow control and error recovery

The flow control/error recovery procedures for message exchange over the OMCC are based upon a
simplex acknowledged transaction stop-and-wait mechanism that can easily be extended to support
concurrent execution of multiple transaction requests of different priority levels. These flow-control
procedures ensure that a low level acknowledged transaction request transmitted from the OLT has
been properly received and processed to completion by the ONT before the next message of the
same priority level is sent by the OLT. The stop-and-wait protocol uses the transaction correlation
identifier field, retry counter(s), and applicable transaction request timer(s) to control the message
flow rate while relying upon a CRC calculation to verify the data integrity of all received messages.
ITU-T Rec. G.983.2 (07/2005) 251

A Transaction Request Timer Ti with expiration time Tmaxi is started when a transaction request
message of priority level "i" is sent to an ONT and is stopped upon receipt of an error-free
acknowledgement message containing the same transaction correlation id value. If a valid
acknowledgement message is not received by the OLT after timer Ti expires, the OLT resends the
original transaction request message.
A retransmitted acknowledged transaction request message carries the same correlation ID as the
original message. Each time an acknowledged transaction request message is retransmitted by the
OLT, the transmitter increments the Retry Counter Ri (the counter associated with priority level "i"
acknowledged transaction requests). When a retry counter Ri (initialized to 0x00 upon start-up)
reaches the maximum retry value, Rmaxi, the transmitter stops retransmitting the message and
declares an OMCC link state error.
Note that these timers (Ti) and retry counters (Ri) are only maintained within the OLT controller
and do not exist within the ONT. Furthermore, the default threshold values for timer expiration
(Tmaxi) and number of retries (Rmaxi) are not subject to standardization. It is suggested that the
default threshold values of both Tmax and Rmax be independently configurable for each priority
level. The default value for Tmax1 (i.e., high priority threshold) should account for the typical
message transmission delay plus the command message response time.
These flow control/error recovery procedures are illustrated in Figure 43 for a case where the
OMCC link is not permanently broken. First the OLT sends an acknowledged transaction request
(Message 1) with priority level 0. Subsequently (i.e., while Message 1 is still outstanding), the OLT
issues an additional acknowledged transaction request (Message 2) with priority level 1. Both of
these commands are received and executed with the associated response (acknowledgement
messages) returned to the OLT by the ONT. The acknowledgement for Message 1 is received by
the OLT in time, however the response to Message 2 is lost and never received. The OLT detects
that something went wrong because timer T1 expires, and the OLT therefore retransmits the original
command (Message 2). Note that the ONT detects that this retransmitted command is identical to
the last received command (for priority level 1) and therefore does not re-execute it. The ONT
simply retransmits the original response from the previous execution of Message 2, which reaches
the OLT in time. Finally, the OLT sends an acknowledged transaction request (Message 3) with
priority level 0, but the message itself gets lost and is never properly received by the ONT. After the
associated timer (T0) expires, the OLT retransmits the command and now all goes well.
252 ITU-T Rec. G.983.2 (07/2005)

Figure 43/G.983.2 – Concurrent message exchange with error recovery
ITU-T Rec. G.983.2 (07/2005) 253

A case where the OMCC link is effectively broken (down) is shown in Figure 44.
Figure 44/G.983.2 – OMCC link error detection
9.3 OMCI handling within the ONT

9.3.1 Prioritized protocol entities
This clause specifies the behaviour of the ONT more precisely than in the preceding clause with
respect to the prioritized request mechanism of the OMCC.
Conceptually, the way the ONT handles the OMCC requests can be illustrated by referring to the
dual priority level implementation example shown in Figure 45.
When the ONT receives an ATM cell via the VCC associated with the management channel, it shall
calculate the CRC and compare it with the value found in the AAL 5 trailer. If the values do not
match, the ONT shall discard the message. It is recommended that this event be logged by the ONT
and possibly communicated to the OLT by some out-of-band mechanism but, as far as the protocol
is concerned, the message is discarded silently.
Messages with a correct CRC are then placed into either of two distinct incoming FIFO-based
message queues, according to the priority level (i.e., high or low) of the associated command. Note
that the priority level of a given command is encoded using the most significant bit of the
transaction correlation Identifier field. If the associated incoming message queue is already full, the
ONT must simply discard the message. It is recommended that this event be logged by the ONT and
possibly communicated to the OLT by some out-of-band mechanism but, as far as the protocol is
concerned, the message is discarded silently.
254 ITU-T Rec. G.983.2 (07/2005)

There are two distinct incoming command processing protocol entities (one associated with each
priority level) that are used to service messages sequentially from an independently associated
incoming FIFO queue. Each of these protocol entities can execute concurrently. If a message is a
one-way command (i.e., an unacknowledged command), the protocol entity will simply have the
command executed. If a message is an acknowledged command, the protocol entity must first look
at the Transaction Correlation Identifier. If it is not equal to the Transaction Correlation Identifier of
the last executed command with the same priority level, the protocol entity will have the command
executed and place the response/acknowledgement (with identical Transaction Correlation
Identifier) in the outgoing FIFO queue of the same priority level. If the Transaction Correlation
Identifier is equal to that of the last executed command with the same priority level (i.e., the case
where the controller retransmits a command due to lack of proper acknowledgement), the protocol
entity will not actually have the command executed but simply will place the response from the last
execution of that command in the outgoing FIFO queue (i.e., resend the previous acknowledgement
response). It is assumed that in both cases, the command processing protocol entity for a given
priority level will block until there is room in the associated outgoing FIFO queue for the response
message.
In the other direction, requests by the applications to send autonomous event notifications will
simply result in the corresponding messages being directed to an event notification protocol entity
for transmission to the OLT. The event notification protocol entity will forward these event
notification messages to the low priority outgoing FIFO queue. In this case as well, the event
notification protocol entity will block until there is room in the low priority outgoing FIFO queue to
hold the notification message. The CRC generator will remove messages from the outgoing FIFO
queues using a strict priority discipline (i.e., the low-priority queue will only be serviced when the
high-priority queue is empty), generate a CRC, append a properly-formatted AAL 5 trailer to the
cell payload, and transmit the message to the OLT.
Figure 45/G.983.2 – Protocol entities within the ONT
9.3.2 Restrictions on the actions in relation to the protocol entities

To reduce the complexity and the amount of memory necessary in the ONT, the OLT is not allowed
to issue a MIB Upload or a Software Download of a certain priority level while a similar action in
the other priority level is in progress.
ITU-T Rec. G.983.2 (07/2005) 255

Annex A
Transport of video return path service

A.1 Network overview
This Recommendation considers networks that use B-PON systems that include a video overlay.
This system provides a bidirectional ATM transport service and a unidirectional video or data
downstream broadcast or unicast service. If only broadcast video services are desired, then the only
video transport required is the third wavelength, as shown in Figure A.1. The ONT converts the
signals on the third wavelength to electrical signals on a coaxial output, suitable for video
appliances such as televisions.
Figure A.1/G.983.2 – A B-PON with broadcast video only
In many cases, however, interactive video services are needed. In this case, the customer's video
termination equipment (commonly referred to as a Set Top Box, or STB) needs connectivity back to
the video control equipment in the central office. In the case of the B-PON system, this connectivity
must be provided by the ONU and OLT. This scenario is depicted in Figure A.2. The connection
begins in the STB, which transmits its information up the coaxial cables that connect it to the ONT.
The ONT must receive this information, and adapt it to be carried on the B-PON in the form of an
ATM connection. The OLT transports this connection through the network. At some point, the
connection then terminates on the video control equipment.
Figure A.2/G.983.2 – A B-PON with interactive video services
256 ITU-T Rec. G.983.2 (07/2005)

Figure A.2 defines two interfaces that are important to interoperability. The STB-ONU interface is
the first. This interface is defined by two standards: SCTE 55-1 and SCTE 55-2. These are peer
standards that are mutually exclusive; that is, a system will run either one or the other, but not both
at one time. Furthermore, each of these standards defines several grades of capability, one being
chosen as the default (or basic practice). Clauses A.2 and A.4 clarify this interface for the purposes
of providing the Video Return Path over B-PON.
The second important interface is the ONU-Network interface. This logical interface is an ATM
connection that conducts the return path information back to the video equipment in the central
office. The information must be formatted in a standardized way so that common control equipment
can be used. The formatting depends on the particular return path interface being used. Clauses A.3
and A.5 define these formats.
Given the situation that there are two modes on both interfaces, it makes sense that the ONU has
two modes of operation, denoted Mode 1 and Mode 2. Mode 1 corresponds to support of the
SCTE 55-1 system, and Mode 2 corresponds to support of the SCTE 55-2 systems. The mode is set
by the network operator during the initialization management of the video service.
A.2 Mode 1 STB-ONU Interface

The STB-ONU interface, in this case, is based on that from the commonly deployed SCTE 55-1
standard. The 55-1 standard defines all the aspects of the interactive video control system, while the
STB-ONU interface herein described is only concerned with the upstream transmission of data.
Therefore, we specify below which sections and sub-sections are relevant to the definition of the
STB-ONU interface.
Relevant sections of SCTE 55-1 that apply to the STB-ONU interface:
5.2 PHYSICAL LAYER FOR RETURN-PATH TRANSMISSION
5.2.1 Return-Path Modem Description – A general explanation, Required.
5.2.2 RF Return Path Packet Format – Specifies the format of the upstream packet,
Required.
Please note that the unique word specified in this section is given in standard QPSK
notation, and not differential QPSK notation.
5.2.3 RF Return-Path Forward Error Correction – Specifies the code used for the FEC
bytes, Optional.
Please note that while the FEC will be calculated by compliant STBs, the ONT's processing
of the FEC is optional.
5.2.4 RF Return-Path Randomizer – Specifies the randomizer used in the upstream
packets, Required.
Please note that the randomizer output is applied to the entire packet EXCEPT the unique
word. Also, the programmable value of the randomizer seed to be used is given in the
Video Return Path Service Profile Managed Entity.
5.2.5 RF Return Path Modulator – Specifies the physical layer to be used, Required.
Note that while the center frequency is specified to a wider range, in actual practice this
frequency is limited from 8 to 12 MHz. Also, the DQPSK mode to be used is given in the
Video Return Path Service Profile Managed Entity.
5.2.6 RF Return-Path Demodulator Specification – Specifies the physical layer to be
used, Required.
ITU-T Rec. G.983.2 (07/2005) 257

All other sections of SCTE 55-1 are not relevant to the STB-ONT interface. In particular, the
extended practice (section 5.3) is explicitly not supported.
A.3 Mode 1 ONU-network interface

In mode 1, the ONU must forward the derandomized packet sequence field (1 byte) and the ATM
data (53 bytes) intact to the video control system. The procedure to do this is:
1) Receive the DQPSK burst, and capture all 62 bytes of data and measure the power level of
the burst relative to the nominal input power level for the receiver.
2) Exclusive OR the randomizer sequence with the received data.
3) (Optional) Calculate the FEC parity, compare with that received, and detect/correct errors.
Discard cells that have uncorrectable errors.
4) Assemble the datagram to be forwarded, which is 56 bytes in length.
5) Encapsulate the datagram using AAL 5.
6) Forward the AAL 5 segments over an ATM Virtual Circuit allocated on the PON.
The structure of the incoming RF burst data and the outgoing ATM circuit data is shown in
Figure A.3. The outgoing datagram is always 56 bytes in length, and is composed of a two byte
Level Indication field, a one byte packet sequence field, and a 53 byte ATM data field. The unique
word and FEC bytes are terminated in the ONU.
Figure A.3/G.983.2 – The transformation of a 55-1 formatted burst into ATM datagrams
The level indication field is formatted as: a1bb bbbb 0000 0000, where:
The bit 'a' is a detection indicator to be used if FEC is implemented in the ONT (if not, bit 'a' should
be set to zero always), where:
a = 0 means burst was detected without errors;
a = 1 means a burst was detected with errors, but was corrected.
The '1' is a reserved bit.
The bits 'bbbbbb' are a power indication, containing the 2's complement representation of the
measured power of this burst, in units of decibels relative to the nominal receive power of the
equipment. For example, if the nominal receive power of the ONU is 10 dBmV, and a burst arrives
with 17 dBmV, then bbbbbb=000111. If the same ONU receives a 7 dBmV burst, then
bbbbbb=111101.
The "0000 0000" are all reserved bits.
258 ITU-T Rec. G.983.2 (07/2005)

The ATM VC that carries the video return path data can be configured to provide a UBR service.
The cell rate of the service can be calculated from the latency requirements of the 55-1 protocol and
equipment implementation. Practical implementations of this protocol have round trip delay
tolerances on the order of 100 ms. After this time, the STB will begin to re-transmit its upstream
cells. One of the contributors of the delay will be the cell transmission time, which in our case is
double the inverse cell rate.
For example, if 20 ms is allocated for cell transmission time, then the cell rate for the video return
path connection should be made 2/20ms = 100 cps.
To summarize, the ONU-Network interface is 56 byte payloads (as defined above) encapsulated in
AAL 5, carried in an ATM VC.
A.4 Mode 2 STB-ONU interface

The STB-ONU interface in this case is based on that from the commonly deployed SCTE 55-2
standard. The 55-2 standard defines all the aspects of the interactive video control system, while the
STB-ONU interface herein described is only concerned with the upstream transmission of data.
Therefore, we specify below which sections and subsections are relevant to the definition of the
STB-ONU interface.
Relevant sections of SCTE 55-2 that apply to the STB-ONU interface:
2.2 Upstream Physical Interface Specification – A general explanation of the system,
Required.
2.2.1 Quaternary Phase Shift Keying (QPSK) – A description of the physical layer used,
Required.
Grade A 256 kbit/s is optional
Grade B 1.544 Mbit/s is required
Grade C 3.088 Mbit/s is optional
2.2.2 Coaxial Cable Impedance – A physical layer parameter, Required.
2.2.3 Time Division Multiple Access (TDMA), Optional.
2.2.4 Contention Based Access, Required.
All other sections of SCTE 55-2 are not relevant to the STB-ONT interface.
A.5 Mode 2 ONU-network interface

In mode 2, the ONU forwards the de-randomized and re-addressed ATM cells (53 bytes) to the
video control system. The procedure to do this is:
1) Receive the QPSK burst, and capture all 59 bytes of data.
2) Exclusive OR the randomizer sequence with the received data.
3) (Required) Calculate the FEC parity, compare with that received, and detect/correct errors.
Discard cells that have uncorrectable errors.
4) Perform a virtual circuit merge on all connections coming from the subtending STBs. Note
that this merging function requires the ONU to queue all cells in a subtending VC until the
end-of-packet indication is received. This maintains AAL 5 user payload frame delineation.
5) Forward the merged AAL 5 segments over an ATM Virtual Circuit allocated on the PON.
The structure of the incoming RF burst data and the outgoing ATM circuit data is shown in
Figure A.4. The outgoing datagram is a 53-byte ATM cell. The cells have undergone a VC merge.
The unique word and FEC bytes are terminated in the ONU.
ITU-T Rec. G.983.2 (07/2005) 259

Figure A.4/G.983.2 – The transformation of a 55-2 formatted burst into ATM datagrams
The ATM VC that carries the video return path data can be configured to support the operator
chosen QoS.
This method provides efficient bandwidth usage upstream since it maps the ATM payload from the
STB onto the PON directly on a PON allocated VC.
To summarize, the ONU-Network interface is 53 byte cells, carrying AAL 5 encapsulated data,
using a PON allocated ATM VC.
260 ITU-T Rec. G.983.2 (07/2005)

Appendix I
OMCI common mechanisms and services
This appendix describes the common mechanisms of the OMCI, e.g., the MIB resynchronization,
and the OMCI services, e.g., the equipment management or connection management.
I.1 Common mechanisms

The common mechanisms consist of:
a) MIB data sync increase.
b) MIB audit and resynchronization.
c) Alarm sequence number increase.
d) Alarm audit and resynchronization.
e) Get an attribute that is larger than the OMCI message contents field.
f) Create an instance of a managed entity with an attribute that is larger than the OMCI
message contents field.
g) Reporting of test result.
h) Alarm Reporting Control.
These common mechanisms will be explained by the use of scenario diagrams.
I.1.1 MIB data sync increase
The MIB at the OLT and the instances of the managed entities in the ONT have to be synchronized
at all times. This clause describes the means for achieving this. The "tool" used for this is the MIB
data sync attribute of the ONT Data managed entity.
The MIB data sync attribute is a global 8-bit sequence number. When auditing the MIB in the ONT,
the OLT requests this sequence number. If this number coincides with the corresponding sequence
number in the OLT, no further action is needed, as the two MIBs, in ONT and OLT, are thought to
be identical. If there is a discrepancy, the OLT either:
1) downloads its copy (including the MIB data sync) of the MIB to the ONT, or
2) uploads the MIB of the ONT, compares it with its own MIB, sends the necessary
commands to the ONT to correct the differences and downloads its sequence number.
The ONT will be audited with respect to its MIB in three cases:
a) On loss and re-establishment of the OMCC.
b) Periodically, based on the operator's requirements.
c) On demand of the OpS.
On detecting a newly installed ONT, regardless of the sequence number of its MIB, the OLT will
perform either a MIB audit followed by whatever modifications are required, or a MIB reset and
ONT startup procedure (see I.2.1).
The MIB data sync counter will be incremented for the creation and deletion of managed entity
instances that are the consequence of a command by the OLT. The MIB data sync counter will also
be incremented for attribute value changes which are the consequence of a command by the OLT.
The MIB data sync counter will be incremented once per executed command (see Figure I.1).
In contrast, the MIB data sync counter will not be incremented for autonomous creation and
deletion of managed entity instances by the ONT itself. Neither will the MIB data sync counter be
ITU-T Rec. G.983.2 (07/2005) 261

incremented for autonomous changes to attributes of managed entities within the ONT (see
Figure I.2).
The order in which the OLT and the ONT will update their MIBs and increment the MIB data sync
is not imposed. However, both the OLT and the ONT must locally update the MIB and increment
the MIB data sync as one atomic action.
When incremented, the sequence number that follows 255 is 1. 0x00 is reserved for the following
cases:
a) Default MIB with which the ONT left the factory.
b) An ONT which after (re-) initialization cannot restore its MIB.
In other words, a sequence number of 0 indicates that the ONT's MIB is not well defined, and
therefore requires audit/reconfiguration.
Note that no mechanisms exist to detect that an autonomous attribute value change notification has
been lost. Therefore, the OLT must regularly read the values of the attributes that can change their
values autonomously.
Figure I.1/G.983.2 − Increment of MIB data sync at ONT and OLT under OLT command
262 ITU-T Rec. G.983.2 (07/2005)

Figure I.2/G.983.2 − No increment of MIB data sync at ONT and OLT in case
of autonomous attribute value changes
ITU-T Rec. G.983.2 (07/2005) 263

I.1.2 MIB audit and resynchronization
Figure I.3 shows the scenario diagram of the MIB audit and MIB resynchronization process.
Figure I.3/G.983.2 − Audit and MIB resynchronization
264 ITU-T Rec. G.983.2 (07/2005)

The OLT must issue as many MIBUploadNext requests as the number of instances given in the
MIBUpload response. The maximum time between two MIBUploadNext requests is 1 minute. If
the OLT does not send a MIBUploadNext request within this time after the previous
MIBUploadNext request or after the MIBUpload start request, the ONT assumes the MIB upload to
be terminated. The ONT can drop the copy of the MIB, and consider any MIBUploadNext requests
to be out of range, as described in II.2.22.
I.1.3 Alarm sequence number increase
The ONT informs the OLT of alarm status changes by sending alarm status change notifications.
Note that these notifications are sent in unacknowledged messages that carry an eight-bit alarm
sequence number for the benefit of the OLT to detect loss of alarm notifications (see Figure I.4
and I.1.4). After a restart of the ONT, the alarm sequence number is reset so that the first alarm
notification sent by the ONT will have an alarm sequence number equal to 1. The alarm message
sequence number is incremented for each alarm notification and wraps around from 255 to 1.
Consequently, an alarm notification with sequence number 0x00 will never be sent.
Figure I.4/G.983.2 − Increment of alarm sequence number at ONT and OLT
ITU-T Rec. G.983.2 (07/2005) 265

I.1.4 Alarm audit and resynchronization
When the OLT detects a gap in the received sequence, as shown in Figure I.5, it asks the ONT for
an alarm status report by sending a "Get All Active Alarms" command. Obviously, this command is
acknowledged by a response that contains the number of managed entity instances that have
outstanding alarms. The OLT will request the alarm status of all these managed entities instances
via the "Get All Alarms Next" command. The OLT will compare these alarm statuses of all these
instances with its own and will notify the network manager of the changes. The alarm sequence
number is reset by the ONT when it receives the "Get All Active Alarms" request.
Figure I.5/G.983.2 − Audit and alarm resynchronization
The OLT must issue as many GetAllAlarmsNext requests as the number of instances given in the
GetAllAlarms start response. The maximum time between two GetAllAlarmsNext requests is
266 ITU-T Rec. G.983.2 (07/2005)

1 minute. If the OLT does not send a GetAllAlarmsNext request within this time after the previous
GetAllAlarmsNext request or after the GetAllAlarms start request, the ONT assumes the alarm
upload to be terminated. The ONT can drop the copy of the alarm table, and consider any
GetAllAlarmsNext requests to be out of range, as described in II.2.18.
I.1.5 Get an attribute that is larger than the OMCI message contents field
Figure I.5-a shows the scenario diagram when the OLT gets an attribute that is larger than the
OMCI message contents field (see 9.1.9 for limitations). The OLT asks the ONT for the size of the
attribute by sending a "Get" command. In the Get response, the ONT uses 4 bytes to indicate the
size of the data. This implies that the Get response message is formatted as if the oversized attribute
had a size of 4 bytes. Then, the OLT will request the attribute data from the ONT via the
appropriate number of "Get next" commands. This scenario is used for the MAC Filter Table
attribute of MAC Bridge Port Filter Table Data managed entity and the Bridge Table attribute of the
MAC Bridge Port Bridge Table Data managed entity.
Figure I.5-a/G.983.2 − Get an attribute that is larger than the OMCI message field
ITU-T Rec. G.983.2 (07/2005) 267

The OLT must issue as many "Get next" requests as needed to accommodate the size of the data
indicated in the Get response. The maximum time between two "Get next" requests is 1 minute. If
the OLT does not send a "Get next" request within this time after the previous "Get next" request or
after the Get start request, the ONT assumes the Get attribute command has been terminated and
can drop the copy of the attribute, and consider any GetNext requests to be out of range, as
described in II.2.44. In addition, the OLT should not initiate simultaneous multiple get-next
processes to any one ONT.
I.1.6 Create an instance of a managed entity with an attribute that is larger than the OMCI
message contents field
Figure I.5-b shows the scenario diagram when the OLT creates an instance of a managed entity with
an attribute that is larger than the OMCI message contents field (exactly 33 bytes). The OLT first
creates an instance of the managed entity without attribute data by sending a "Create" command and
then sets the attribute data by sending the appropriate number of "Set" commands. This scenario is
useful for Threshold Data B-PON ME.
Figure I.5-b/G.983.2 − Create an instance of a managed entity with an attribute

that is larger than the OMCI message field
268 ITU-T Rec. G.983.2 (07/2005)

I.1.7 Report test result
Figure I.5-c shows the scenario diagram for when the OLT requests that the ONT perform a test.
The OLT requests that the ONT starts testing by sending a "Test" command. This command is
acknowledged by a "Test" response. Then, the ONT carries out the test. After the test is complete,
the ONT reports the test result via a "Test result" notification message. This scenario is used for the
"SelfTest" attribute of ONTB-PON managed entity or Subscriber Line Card managed entity.
Moreover, this scenario may be useful for MLT tests or for additional tests that may be added in the
future.
Figure I.5-c/G.983.2 − Reporting of test result
I.1.8 Alarm reporting control

Alarm Reporting Control allows for the suppression of alarms from physical path termination
points, under the control of the management system. A complete description of ARC from a generic
viewpoint is given in Amendment 3 (2001)/M.3100. The OMCI provides for ARC functions using
two attributes of the PPTP, 'ARC' and 'ARC Interval'. These two attributes are described below
ARC:
This attribute allows the activation of Alarm Reporting Control (ARC) for this PPTP. The attribute
works in concert with the ARC_interval attribute. A value of zero indicates disable, while a value
of 1 indicates enable. The default value is disabled. When the ARC attribute is set to disabled, the
PPTP is in the "ALM" state, as defined in Amendment 3 (2001)/M.3100. Alarms are reported
normally in the ALM state. When the ARC attribute is set to enabled, then the PPTP is in the
"NALM-QI" state, as defined in Amendment 3 (2001)/M.3100. Alarms are suppressed in this state.
The PPTP moves from the ALM state to the NALM-QI state when the OLT changes the ARC
attribute to enabled. The PPTP moves from the NALM-QI state to the ALM state when either:
1) the PPTP is trouble free and the ARC_interval timer expires; or
2) the ARC attribute is set to disable by the OLT.
If the ARC_interval timer expires, the ONT will set the ARC attribute to disabled autonomously,
and send an AVC to notify the OLT. Please refer to Amendment 3 (2001)/M.3100 for more
extensive discussion of the behaviours of the state diagram.
ITU-T Rec. G.983.2 (07/2005) 269

Note that the ARC_interval can assume normal timing values of 0 to 254 minutes. The value of 0
implies that a PPTP in the NALM-QI state will immediately transition to the ALM state upon
detection of a problem-free state. An ARC_interval value of 255 has the special meaning of
'infinity'. This value means that the timer shall never expire, and the PPTP will stay in the
NALM-QI state until the OLT sets the ARC attribute to disabled. This behaviour is equivalent to
the "NALM" state, which is another generic behaviour of the ARC function in Amendment 3
(2001)/M.3100.
Note that there is no support for the "NALM-TI" subfunction in the OMCI system. (R,W) (optional)
(1 byte)
ARC_interval:
This attribute defines the interval to be used with the ARC function for this PPTP. The values 0
through 254 give the duration in minutes for the NALM-QI timer. The special value 255 means that
the timer never expires. The default value is zero. (R, W) (optional) (1 byte)
I.2 Common services

The common services consist of:
a) start-up phase of ONT;
b) on demand subscriber line card provisioning;
c) on demand subscriber line card de-provisioning;
d) plug-and-play subscriber line card provisioning;
e) plug-and-play subscriber line card de-provisioning;
f) ATM VP Cross-Connection or ATM VC Cross-Connection set-up;
g) ATM VP Cross-Connection or ATM VC Cross-Connection breakdown;
h) software image download;
i) software image changes;
j) MAC bridge service connection set-up;
k) MAC bridge service connection tear-down;
l) Addition of entities to MAC Filter Table;
m) Removal of entities from MAC Filter Table;
n) Voice service connection set-up; and
o) Voice service connection tear-down;
p) IP Router service connection set-up;
q) IP Router service connection tear-down;
r) Addition of entities to IP Static Routes;
s) Removal of entities from IP Static Routes;
t) Structured/Unstructured CES service connection set-up (ATM mode);
u) Structured/Unstructured CES service connection tear-down (ATM mode).
All the listed services will be explained by the use of scenario diagrams.
I.2.1 Start-up phase of ONT
The start-up phase of an ONT, from the OMCI point of view, belongs to one of two cases:
a) the ONT is "new" to the OLT; or
b) the OLT already "saw" this ONT at this PON.
270 ITU-T Rec. G.983.2 (07/2005)

The details of start-up scenarios also vary for ONTs with different configuration options, e.g.,
a) ONT with cardholders at both PON IF and UNI;
b) ONT with integrated interfaces at both PON IF and UNI;
c) ONT with cardholders at PON IF and integrated interfaces at UNI; and
d) ONT with integrated interfaces at PON IF and cardholders at UNI.
Here the following scenarios will only show cases a) and b), from which the scenarios for cases c)
and d) can be deduced.
NOTE – The preferred solution is that Subscriber Line Card and Subscriber Line Cardholder managed
entities should always be modelled, regardless of whether or not the ONT has integrated interfaces.
Figure I.6 shows the start-up phase of a "new" ONT with Cardholders on both sides. Figure I.7
shows the start-up phase of a "new" ONT with integrated interfaces on both sides. Figure I.8 shows
the start-up phase of an "old" ONT.
The behaviour of the ONT with respect to inserted Subscriber Line Cards during the start-up phase
is not shown in the following figures. This behaviour is the subject of I.2.2.
Note that if attribute value changes do not arrive at the OLT, the OLT will not know the number of
cardholders or integrated ports that reside in the ONT. The OLT can request the information of the
newly created managed entity instances by a sequence of "Get" requests. If a "Get" request is issued
on a non-existing instance, the response message to the OLT will indicate the error – Unknown
managed entity instance.
In general, the AVCs shown in Figures I.6 and I.7 should be viewed as a partial method of ONT
discovery. The OLT cannot rely on the receipt of AVCs to learn all ONT information, because not
all managed entities or attributes issue AVCs, and because AVCs can be lost in transmission
without an error being detected. Therefore, the OLT should audit any ONT immediately after a
Reset is completed.
ITU-T Rec. G.983.2 (07/2005) 271

Figure I.6/G.983.2 – Start-up of a "new" ONT with Cardholders on both sides
272 ITU-T Rec. G.983.2 (07/2005)

Figure I.6/G.983.2 − Start-up of a "new" ONT with Cardholders on both sides (continued)
Figure I.6/G.983.2 − Start-up of a "new" ONT with Cardholders on both sides (continued)
ITU-T Rec. G.983.2 (07/2005) 273

Figure I.6/G.983.2 − Start-up of a "new" ONT with Cardholders on both sides (concluded)
274 ITU-T Rec. G.983.2 (07/2005)

Figure I.7/G.983.2 − Start-up phase of a "new" ONT with integrated interfaces on both sides
ITU-T Rec. G.983.2 (07/2005) 275

Figure I.7/G.983.2 − Start-up phase of a "new" ONT with integrated interfaces
on both sides (concluded)
276 ITU-T Rec. G.983.2 (07/2005)

Figure I.8/G.983.2 − Start-up phase of an "old" ONT
I.2.2 Subscriber line card provisioning/deprovisioning

The provisioning and deprovisioning of Subscriber Line Card can be triggered in two ways:
a) On demand by the OpS;
b) Plug-and-play, triggered by the detection of the card insertion/removal.
However, this trigger of provisioning and deprovisioning is transparent to the ONT, i.e., the ONT is
always responding to OLT provisioning and deprovisioning commands. The difference between
plug-and-play mode and on-demand mode would reside in the OLT. For the on-demand mode, the
OLT will provision (deprovision) the presence of the subscriber line card in the ONT when it has
been provisioned (deprovisioned) by the operator; for the plug-and-play mode, the OLT will
provision the slot to "plug-and-play" and further provision (deprovision) the presence of the
subscriber line card in the ONT as soon as it has received a notification from the ONT that a line
card has been plugged in (out).
I.2.3 On-demand subscriber line card provisioning
NOTE – It is possible to provision a subscriber line card while a subscriber line card of the same or of a
different type is provisioned for the subscriber line cardholder. In case a subscriber line card of the same type
is already provisioned, the provisioned command will have no effect. In case a subscriber line card of a
different type is already provisioned, this subscriber line card will be automatically deprovisioned and only
then will the system be configured according to the newly given plug-in unit type. Figure I.9 shows the
scenario of provisioning an ATM LIM. Figure I.10 shows the scenario of provisioning a non-ATM LIM.
The cases below show the use of the attributes "Expected type" and "Sensed type" of the
corresponding Physical Path Termination Point ATM/Ethernet/CES UNI.
Case 1
The subscriber linecard Holder or the ONT itself (the latter in case of integrated interfaces) only
supports a specific type of interface. Notice that in the former case, the attribute "type" of the
Subscriber Line Card managed entity will be equal to this type.
In this case, on creation of the Physical Path Termination Point managed entity instance, the
attributes "Expected Plug-in Unit type" and "Actual Plug-in type" of the Subscriber Linecard
Holder managed entity are both set equal to the specific interface type and the ONT sends attribute
value change notifications to the OLT with the values of these attributes. It will not be possible for
ITU-T Rec. G.983.2 (07/2005) 277

the OLT to change the value of the attribute "Expected Plug-in Unit type" later on (i.e., any attempt
by the OLT to change the value of the attribute will be refused by the ONT).
Case 2
The subscriber linecard holder or the ONT itself (the latter in case of integrated interfaces) supports
interfaces of different types.
In this case, on creation of the Physical Path Termination Point managed entity instance, the
attribute "Expected Plug-in Unit type" is set to autosensing (0x00) and attribute "Actual Plug-in
Unit type" is set to:
• inapplicable or unknown if the interface does not support autosensing or if the autosensing
fails (actually, the coding is 0x00 in both cases);
• the sensed type if the interface supports autosensing and the autosensing was successful.
The ONT will send an attribute value change notification with the values of these attributes.
Later on, it will be possible for the OLT to change the value of attribute "Expected Plug-in Unit
type" with the "Set" action. The value of attribute "Sensed type" will be set equal to the value of
attribute "Expected type". Notice however that the ONT will only execute the "Set" action if the
ONT supports the configured interface type.
Figure I.9/G.983.2 − ATM subscriber line card provisioning
278 ITU-T Rec. G.983.2 (07/2005)

Figure I.9/G.983.2 − ATM subscriber line card provisioning (concluded)
ITU-T Rec. G.983.2 (07/2005) 279

Figure I.10/G.983.2 – Non-ATM card subscriber line card provisioning
280 ITU-T Rec. G.983.2 (07/2005)

Figure I.10/G.983.2 − Non-ATM card subscriber line card provisioning (concluded)
I.2.4 On-demand subscriber line card deprovisioning

The ONT will delete from the MIB all managed entities that it automatically created during the
provisioning of this subscriber line card. On the other hand, the OLT will be responsible for
deleting all those managed entities that are associated with this card and were created by the OLT.
Figure I.11 shows the process of deprovisioning a Subscriber Line Card.
ITU-T Rec. G.983.2 (07/2005) 281

Figure I.11/G.983.2 − Subscriber line card deprovisioning
I.2.5 Plug-and-play subscriber line card provisioning

A subscriber line cardholder can be provisioned for a plug-and-play mode of operation (see also
Figure 32). Figure I.12 shows the scenario for provisioning a slot for plug-and-play.
282 ITU-T Rec. G.983.2 (07/2005)

Figure I.12/G.983.2 − Plug-and-play subscriber line card provisioning
Not shown in the scenario diagram given above are the notifications of the ONT due to incorrectly
inserted subscriber line cards. Figure 32 is given for this purpose.
I.2.6 Plug-and-play subscriber line card deprovisioning
When a subscriber line card is removed from a subscriber line cardholder, a notification will be
send to the OLT. The OLT will deprovision the subscriber line cardholder upon receiving the
notification (see Figure I.13).
Figure I.13/G.983.2 − Plug-and-play subscriber line card deprovisioning
ITU-T Rec. G.983.2 (07/2005) 283

I.2.7 ATM service set-up
The ATM connections within the ONT can be created in two ways: one consists of consecutively
requesting the creation of two VP Network CTPB-PONs and one ATM VP Cross-Connection
(Figure I.14), whereas the other uses one request which will cause the simultaneous creation of two
VP Network CTPB-PONs and one ATM VP Cross-Connection (Figure I.15).
In the given figures for ATM service set-up, the assumption is made that Priority Queues are used.
If Traffic Descriptors are used, the Traffic Descriptor managed entity instance for the requested
service must be created first. Also, the OLT might want to create corresponding History Data
managed entities for the connection.
These descriptions can be extended for use with VC cross-connections as well. For ATM service
set-up and tear-down using VC cross-connections, replace "VP Network CTPB-PONs" with
"VC Network CTPB-PONs" and "ATM VP Cross-Connection" with "ATM VC Cross-Connection".
Figure I.14/G.983.2 − VP cross-connection set-up (alternative 1)
284 ITU-T Rec. G.983.2 (07/2005)

Figure I.15/G.983.2 − VP cross-connection set-up (alternative 2)
I.2.8 ATM service tear-down

The connections within the ONT can be deleted in two ways: one consists of consecutive deletion
of the ATM VP Cross-Connection and the two VP Network CTPB-PONs (Figure I.16), whereas the
other uses one request to delete the ATM VP Cross-Connection and the two associated VP Network
CTPB-PONs (Figure I.17). The correct order of the deletion of the instances in the first alternative is
under the control of the OLT. If applicable, the OLT must delete the corresponding History Data
managed entities as well.
These descriptions can be extended for use with VC cross-connections as well. For ATM service
set-up and tear-down using VC cross-connections, replace "VP Network CTPB-PONs" with "VC
Network CTPB-PONs" and "ATM VP Cross-Connection" with "ATM VC Cross-Connection".
ITU-T Rec. G.983.2 (07/2005) 285

Figure I.16/G.983.2 − VP cross-connection deletion (alternative 1)
Figure I.17/G.983.2 − VP cross-connection deletion (alternative 2)
I.2.9 Structured CES service connection set-up

The following scenario of structured CES service connection set-up is given for an ONT with
cross-connect functionality. For an ONT that does not model cross-connect functionality, the
Interworking VCC Termination Point is directly associated with the VP/VC Network CTPB-PON on
the ANI side.
286 ITU-T Rec. G.983.2 (07/2005)

Figure I.18 shows the set-up of the first structured CES service on a Subscriber Line Card.
Additional services on the same UNI interface, with their Interworking VCC Termination Points,
AAL 1 ProfileB-PONs and CES ProfileB-PONs, can also share the same VP/VC Network CTPB-PON.
Note that the AAL 1 and CES profiles can be shared among multiple Interworking VCC
Termination Points. No creation of profiles is needed if the Interworking VCC Termination Point is
pointing to an existing profile.
Also, the OLT might want to create corresponding History Data managed entities for the
connection.
Figure I.18/G.983.2 − Connection set-up of a structured CES
I.2.10 Structured CES service connection tear-down

The following scenario, shown in Figure I.19, of structured CES service connection tear-down is
given for an ONT with cross-connect functionality. For an ONT that does not model cross-connect
functionality, the Interworking VCC Termination Point is directly associated with the VP/VC
Network CTPB-PON on the ANI side.
Termination Points. If there are more Interworking VCC Termination Points associated with these
profile managed entities, the OLT may not request to delete them. This holds also for the ATM
connection used: if more Interworking VCC Termination Points are associated with this connection
(i.e., VP/VC Network CTPB-PON), the ATM connection cannot be deleted.
If applicable, the OLT must delete the corresponding History Data managed entities as well.
ITU-T Rec. G.983.2 (07/2005) 287

Figure I.19/G.983.2 − Connection tear-down of a structured CES
I.2.11 Unstructured CES service connection set-up

The following scenario, shown in Figure I.20, for unstructured CES service connection set-up, is
given for an ONT with cross-connect functionality. For an ONT that does not model cross-connect
functionality, the Interworking VCC Termination Point is directly associated with the VP/VC
Network CTPB-PON on the ANI side.
Termination Points. No creation of profiles is needed if the Interworking VCC Termination Point is
pointing to an existing profile.
Also, the OLT might want to create corresponding History Data managed entities for the
connection.
288 ITU-T Rec. G.983.2 (07/2005)

Figure I.20/G.983.2 − Connection set-up of an unstructured CES
I.2.12 Unstructured CES service connection tear-down

The following scenario, shown in Figure I.21, for an unstructured CES service connection
tear-down is given for an ONT with cross-connect functionality. For an ONT that does not model
cross-connect functionality, the Interworking VCC Termination Point is directly associated with the
VP/VC Network CTPB-PON on the ANI side.
Termination Points. If there are more Interworking VCC Termination Points associated with these
profile managed entities, the OLT may not request to delete them. This holds also for the ATM
connection used: if more Interworking VCC Termination Points are associated with this connection
(i.e., VP/VC Network CTPB-PON), the ATM connection cannot be deleted.
If applicable, the OLT must delete the corresponding History Data managed entities as well.
Figure I.21/G.983.2 − Connection tear-down of an unstructured CES
ITU-T Rec. G.983.2 (07/2005) 289

I.2.13 This clause intentionally left blank
I.2.14 This clause intentionally left blank
I.2.15 Software image download
The download of a Software Image is based on a "segmented stop and wait" protocol; thus, the next
segment can only be transmitted to the ONT if the previous segment is positively acknowledged. A
Software Image segment (also named window) consists of one of more Software Image sections.
Each section is transmitted in one OMCC message.
The number of sections in a segment is negotiated before the actual download. First the OLT
proposes a segment size (not greater than 256). The ONT can propose a smaller segment size in the
response. If the response indicates a smaller segment size, this is the size to be used in the
download. Thus, an image segment consists of N image sections, with N being equal to the segment
size. Only the last image section is acknowledged. If the ONT processed all sections of a segment
properly, the acknowledgement will be positive, after which the OLT will download the next
segment.
Note that the section numbering starts from 0 so that segments of precisely 8 kilobytes can be
downloaded.
If an error occurred with a section of a segment (e.g., CRC error or missed section), the last section
will be negatively acknowledged, which will result in an entire retransmission of the last segment.
When the last segment transferred is positively acknowledged, the OLT sends a CRC-32 to the
ONT in the Software Image end download command. The ONT calculates the CRC-32 and
compares it to the CRC received from the OLT. If they are equal, the image is considered valid.
Figure I.22 gives the scenario for the software download.
290 ITU-T Rec. G.983.2 (07/2005)

Figure I.22/G.983.2 − Software download
ITU-T Rec. G.983.2 (07/2005) 291

I.2.16 Software image activate and commit
See Figure I.23.
Figure I.23/G.983.2 − Software activate (above) and software commit (below)
I.2.17 MAC bridge service connection set-up

Figure I.24 shows the scenario for MAC bridge service connection set-up for an ONT with
cross-connect functionality. For an ONT that does not model cross-connect functionality, the
Interworking VCC Termination Point is directly associated with the VP Network CTPB-PON on
the ANI side. Note that the AAL 5 ProfileB-PON can be shared among multiple Interworking VCC
Termination Points. No creation of profiles is needed if the Interworking VCC Termination Point
points to an existing profile. Also, the OLT may want to create corresponding History Data
managed entities for the connection.
292 ITU-T Rec. G.983.2 (07/2005)

Figure I.24/G.983.2 − Connection set-up for MAC bridge service connection
ITU-T Rec. G.983.2 (07/2005) 293

I.2.18 MAC bridge service connection tear-down
The following scenario, Figure I.25, depicts MAC bridge service connection tear-down for an ONT
with cross-connect functionality. For an ONT that does not model cross-connect functionality, the
Interworking VCC Termination Point is directly associated with the VP Network CTPB-PON on
the ANI side. Note that the AAL 5 ProfileB-PON can be shared among multiple Interworking VCC
Termination Points. If there are more Interworking VCC Termination Points associated with this
profile managed entity, the OLT may not request to delete it. This holds also for the ATM
connection used: if more Interworking VCC Termination Points are associated to this connection
(i.e., VP Network CTPB-PON), the ATM connection cannot be deleted. If applicable, the OLT must
delete the corresponding History Data managed entities as well.
294 ITU-T Rec. G.983.2 (07/2005)

Figure I.25/G.983.2 − Connection tear-down for MAC bridge service connection
ITU-T Rec. G.983.2 (07/2005) 295

I.2.19 Addition of entries on MAC filter table
The following scenario, Figure I.26, depicts addition of entries to the MAC Filter Table for
an ONT.
Figure I.26/G.983.2 − Addition of entries to the MAC filter table
I.2.20 Removal of entries from MAC filter table

The following scenario, Figure I.27, depicts the removal of entries from the MAC Filter Table for
an ONT.
Figure I.27/G.983.2 − Removal of entries from MAC filter table
296 ITU-T Rec. G.983.2 (07/2005)

I.2.21 Voice over AAL 2 service connection set-up
The following scenario, Figure I.28, depicts Voice over AAL 2 service connection set-up for an
ONT with cross-connect functionality. For an ONT that does not model cross-connect functionality,
the Interworking VCC Termination Point is directly associated with the VP Network CTPB-PON on
the ANI side. Note that the Voice Service, LES Service, AAL 2 and AAL 2 PVC profiles can be
shared among multiple Interworking VCC Termination Points. No creation of profiles is needed if
the Interworking VCCTP points to an existing profile. Moreover, the SSCS Parameter1 and SSCS
Parameter2 profiles can be shared among multiple AAL 2 ProfileB-PONs, so no creation of profiles is
needed if the AAL 2 ProfileB-PON points to an existing profile. Also, the OLT may want to create
corresponding History Data managed entities for the connection.
ITU-T Rec. G.983.2 (07/2005) 297

Figure I.28/G.983.2 − Connection set-up for voice over AAL 2 service connection
298 ITU-T Rec. G.983.2 (07/2005)

I.2.22 Voice over AAL 2 service connection tear-down
The following scenario, Figure I.29, depicts the Voice over AAL 2 service connection tear-down
for an ONT with cross-connect functionality. For an ONT that does not model cross-connect
functionality, the Interworking VCC Termination Point is directly associated with the VP Network
CTPB-PON on the ANI side. Note that the Voice Service, LES Service, AAL 2 and AAL 2 PVC
profiles can be shared among multiple Interworking VCC Termination Points. If there are more
Interworking VCC Termination Points associated with these profile managed entities, the OLT may
not request to delete them. This holds also for the ATM connection used: if more Interworking
VCC Termination Points are associated with this connection (i.e., VP Network CTPB-PON), the
ATM connection cannot be deleted. Moreover, the SSCS Parameter1 and SSCS Parameter2 profiles
can be shared among multiple AAL 2 ProfilesB-PON. If there are more AAL 2 ProfilesB-PON
associated with these profile managed entities, the OLT may not request to delete them. If
applicable, the OLT must delete the corresponding History Data managed entities as well.
ITU-T Rec. G.983.2 (07/2005) 299

Figure I.29/G.983.2 − Voice over AAL 2 service connection tear-down
300 ITU-T Rec. G.983.2 (07/2005)

I.2.23 Voice over AAL 1 service connection set-up
The following scenario, Figure I.30, for Voice over AAL 1 service connection set-up is given for an
ONT with cross-connect functionality. For an ONT that does not model cross-connect functionality,
the Interworking VCC Termination Point is directly associated with the VP Network CTPB-PON on
the ANI side.
Note that the Voice Service and AAL 1 profiles can be shared among multiple Interworking
VCC Termination Points. No creation of profiles is needed if the Interworking VCC Termination
Point is pointing to an existing profile. Also, the OLT might want to create corresponding History
Data managed entities for the connection.
Figure I.30/G.983.2 − Connection set-up voice over AAL 1 service connection
ITU-T Rec. G.983.2 (07/2005) 301

I.2.24 Voice over AAL 1 service connection tear-down
The following scenario, Figure I.31, for voice over AAL 1 service connection tear-down is given
for an ONT with cross-connect functionality. For an ONT that does not model cross-connect
functionality, the Interworking VCC Termination Point is directly associated with the VP Network
CTPB-PON on the ANI side.
Note that the Voice Service and AAL 1 profiles can be shared among multiple Interworking
VCC Termination Points. If there are more Interworking VCC Termination Points associated with
these profile managed entities, the OLT may not request to delete them. This holds also for the
ATM connection used: if more Interworking VCC Termination Points are associated with this
connection (i.e., VP Network CTPB-PON), the ATM connection cannot be deleted. If applicable, the
OLT must delete the corresponding History Data managed entities as well.
Figure I.31/G.983.2 − Connection tear-down for Voice over AAL 1 service connection
302 ITU-T Rec. G.983.2 (07/2005)

I.2.25 IP Router service connection set-up
Figure I.32 shows the scenario for IP Router service connection set-up for an ONT with
cross-connect functionality. For the case that an ONT does not model cross-connect function, the
Interworking VCC Termination Point is directly associated to the VP Network CTPB-PON on the
ANI side.
Note that the AAL 5 profile can be shared among multiple Interworking VCC Termination Points.
No creation of profiles is needed if the Interworking VCCTP points to an existing profile.
Moreover, the IP Router Service Profile and ARP Service Profile can be shared among multiple
IP Port Configuration Data managed entities, so no creation of profiles is needed if the IP Port
Configuration Data points to an existing profile.
The OLT also may want to create corresponding History Data managed entities for the connection.
ITU-T Rec. G.983.2 (07/2005) 303

Figure I.32/G.983.2 − Connection set-up for IP router service connection
304 ITU-T Rec. G.983.2 (07/2005)

I.2.26 IP router service connection tear-down
The following scenario, Figure I.33, depicts IP router service connection tear-down for an ONT
with cross-connect functionality. For the case that an ONT does not model cross-connect function,
the Interworking VCC Termination Point is directly associated to the VP Network CTPB-PON on the
ANI side.
Note that the AAL 5 profile can be shared among multiple Interworking VCC Termination Points.
If there are more Interworking VCC Termination Points associated with this profile managed entity,
the OLT may not request to delete it. This holds also for the ATM connection used: if more
Interworking VCC Termination Points are associated to this connection (i.e., VP Network
CTPB-PON), the ATM connection cannot be deleted. Moreover, the IP Router Service Profile and
ARP Service Profile can be shared among multiple IP Port Configuration Data managed entities. If
there are more IP Port Configuration Data managed entities associated with these profile managed
entities, the OLT may not request to delete them.
If applicable, the OLT can delete the corresponding History Data managed entities as well.
ITU-T Rec. G.983.2 (07/2005) 305

Figure I.33/G.983.2 − Connection tear-down for IP router service connection
306 ITU-T Rec. G.983.2 (07/2005)

I.2.27 Addition of entries to IP static routes
The following scenario, Figure I.34, depicts addition of entities to the IP static routes managed
entity for an ONT.
Figure I.34/G.983.2 − Addition of entities to the IP static routes
I.2.28 Removal of entries from IP static routes

The following scenario, Figure I.35, depicts the removal of entries from the IP static routes
managed entity for an ONT.
Figure I.35/G.983.2 − Removal of entries from IP static routes
I.3 Common services with PON protection

In cases where PON protection is implemented, some of the common service scenarios given in
clause I.2 must be modified or augmented to accommodate the protection function. The following
subclauses describe these cases.
ITU-T Rec. G.983.2 (07/2005) 307

I.3.1 OMCC establishment – protection side ranged after start-up of working side
Figure I.36 shows the OMCI start-up sequence when only the working-side PON-LT is ranged
during the initial phase. In the given figure, the assumption is made that the OLT and the ONT are
both available for PON protection.
NOTE – When the OLT and the ONT do not support a common protection scenario (i.e., 1+1, 1:1 and extra
traffic), the protection side is not used.
Figure I.36/G.983.2 – Start-up scenario for sequential ranging of working

and protection sides
308 ITU-T Rec. G.983.2 (07/2005)

I.3.2 OMCC establishment for simultaneous ranging of working and protection PON-LTs
Figure I.37 shows the OMCI start-up sequence when both working-side PON-LT and protection-
side PON-LT are ranged simultaneously during the initial phase. In the given figure, the assumption
is made that the OLT and the ONT are both available for PON protection.
NOTE – When the OLT and the ONT do not support a common protection scenario (i.e., 1+1, 1:1 and extra
traffic), the protection side is not used.
Figure I.37/G.983.2 – Start-up scenario for simultaneous ranging of working

and protection sides
ITU-T Rec. G.983.2 (07/2005) 309

I.3.3 VP configuration for the ONT defined as 1+1 model
Figure I.38 shows the VP configuration sequence for the 1+1 protection architecture.
NOTE – The same VPI/VCI for the OMCC should be used for both working and protection sides.
Figure I.38/G.983.2 – VP configuration for 1+1 ONT
310 ITU-T Rec. G.983.2 (07/2005)

I.3.4 VP configuration for the ONT defined as 1:1 model
Figure I.39 shows the VP configuration sequence for the 1:1 protection architecture.
NOTE – The same VPI/VCI for the OMCC should be used for both working and protection sides.
Figure I.39/G.983.2 – VP configuration for 1:1 ONT
ITU-T Rec. G.983.2 (07/2005) 311

I.3.5 VP removal for 1+1 model ONT
Figure I.40 shows the VP removal sequence for the 1+1 protection architecture.
Figure I.40/G.983.2 – VP removal for 1+1 ONT
312 ITU-T Rec. G.983.2 (07/2005)

I.3.6 VP removal for a 1:1 model ONT
Figure I.41 shows the VP removal sequence for the 1:1 protection architecture.
Figure I.41/G.983.2 – VP removal for 1:1 ONT
ITU-T Rec. G.983.2 (07/2005) 313

I.3.7 Switch-over sequence for a 1+1 model ONT
Figure I.42 shows the switch-over sequence for the 1+1 protection architecture. In the given figure,
the assumption is made that the working side's PON-LT detects Signal Fail (SF) or Signal Degrade
(SD).
Figure I.42/G.983.2 – Switch-over sequence for 1+1 ONT
314 ITU-T Rec. G.983.2 (07/2005)

I.3.8 Switch-over sequence for a 1:1 model ONT
Figure I.43 shows the switch-over sequence for the 1:1 protection architecture. In the given figure,
the assumption is made that the working side's PON-LT detects Signal Fail (SF) or Signal
Degrade (SD).
Figure I.43/G.983.2 – Switch-over sequence for 1:1 ONT
ITU-T Rec. G.983.2 (07/2005) 315

I.4 Common services with DBA support
The following scenarios describe the initial discovery of the DBA function, and the creation and
deletion of a T-CONT in the ONT.
I.4.1 Initial handshake
The scope of initial handshake is from ranging to acquisition of the information to be able to start
the status reporting. Allocation of the divided_slot grant and data grants and T-CONT configuration
is described in clause I.4.2.
Figure I.44 shows the initial handshake procedure.
Figure I.44/G.983.2 – Initial handshake procedure
316 ITU-T Rec. G.983.2 (07/2005)

I.4.2 Addition of T-CONT in an ONT
Figure I.45 shows the addition of T-CONT.
Figure I.45/G.983.2 – T-CONT addition procedure
ITU-T Rec. G.983.2 (07/2005) 317

I.4.3 Deletion of T-CONT in an ONT
Figure I.46 shows the deletion of T-CONT.
Figure I.46/G.983.2 – Deletion of T-CONT
318 ITU-T Rec. G.983.2 (07/2005)

Appendix II
OMCI message set

II.1 General remarks
II.1.1 Message type identifier
In 9.1.4, the message types are given. This identifier is omitted in the message set below.
II.1.2 Entity class identifier
In 9.1.6, the entity class identifiers are given. This identifier is omitted in the message set below.
II.1.3 Result and reason
Responses to commands can indicate the result of the command. A value of "null" will indicate that
the command was processed successfully. Non-null values will indicate the reason of the failure. If
the result was "failure", the rest of the message contents will be filled with all 0x00s. The definition
of each result and reason is as follows:
0) command processed successfully
There are two functions for command processing: command interpretation and command
execution. This result means that the received command, such as Get/Set/Test/Reboot, was
properly interpreted by the ONT's command interpretation function without errors and that
the interpreted command was successfully transferred to the ONT's command execution
function.
1) command processing error
This result means the command processing failed at the ONT due to some reason not
described by items 3, 4, etc.
2) command not supported
This result means that the message type indicated in Byte 8 is not supported by the ONT.
3) parameter error
This result means that the command message received by the ONT was errored.
4) unknown managed entity
This result means that the managed entity class indicated in Byte 10 is not supported by the
ONT.
5) unknown managed entity instance
This result means that the managed entity instance indicated in Bytes 11 and 12 does not
exist in the ONT.
6) device busy
This result means that the command could not be processed due to process-related
congestion at the ONT.
7) instance exists
This result means that the ONT already has a managed entity instance that corresponds to
the one the OLT is attempting to create.
8) Reserved
9) attribute(s) failed or unknown
This result means that an optional attribute is not supported by the ONT or that a
mandatory/optional attribute could not be executed by the ONT, even if it is supported. In
ITU-T Rec. G.983.2 (07/2005) 319

conjunction with this result, attribute masks are used to indicate which attributes failed or
were unknown.
The following two kinds of attribute masks are used when this result/reason is raised:
– optional attribute mask coding, which indicates whether or not the optional attribute is
supported. Bytes 14 and 15 are assigned to this mask.
– attribute execution mask coding, which indicates whether or not the mandatory/optional
attribute was executed. Bytes 16 and 17 are assigned to this mask.
If one or more optional attributes are not supported by the ONT, the "optional attribute
mask coding" for each unsupported optional attribute becomes 1 while the
corresponding "attribute execution mask coding" remains 0.
If one or more mandatory or optional attributes were not executed by the ONT, the
"optional attribute mask coding" remains 0, while the "attribute execution mask
coding" becomes 1 for each failed attribute."
II.1.4 Get, get response and set messages
For an attribute mask, a bitmap is used in the "Get", "Get Current Data", "Get response", "Get
Current Data Response", and "Set" messages. This bitmap indicates which attributes are requested
(Get, Get Current Data) or provided (Get response, Get Current Data Response, and Set). The
bitmap is composed as follows (see Table II.1):
Table II.1/G.983.2 − Attribute mask coding

Byte Bit
8 7 6 5 4 3 2 1
1 Attribute 1 Attribute 2 Attribute 3 Attribute 4 Attribute 5 Attribute 6 Attribute 7 Attribute 8
2 Attribute 9 Attribute 10 Attribute 11 Attribute 12 Attribute 13 Attribute 14 Attribute 15 Attribute 16
The attribute numbers correspond to the ordering of the attributes in clause 7. Note that the
Managed Entity identifier, which is an attribute of each managed entity, has no corresponding bit in
the attribute mask. Thus, the attributes are counted starting from the first attribute after the Managed
Entity identifier.
II.1.5 Alarm notifications
The ONT will send this notification each time an alarm has changed status for the entity indicated
in the message identifier. The message shows the status of all alarms of this entity. It is up to the
OLT to determine which alarms changed status.
The maximum number of alarms that is supported by the OMCI is 240; thus, the alarm bitmap uses
30 bytes. The bitmap is composed as follows (see Table II.2):
Table II.2/G.983.2 − Alarm mask coding

Byte Bit
8 7 6 5 4 3 2 1
1 Alarm 0 Alarm 1 Alarm 2 Alarm 3 Alarm 4 Alarm 5 Alarm 6 Alarm 7
…
320 ITU-T Rec. G.983.2 (07/2005)

The alarm numbers correspond to the alarm coding in clause 7. Bits in the alarm bitmap that
correspond to non-existing alarms shall always be set equal to "0". Bits that correspond to an
existing alarm are set to a value of "0" to indicate that the corresponding alarm is cleared or a value
of "1" to indicate that the alarm has been raised.
Alarm message sequence numbers can obtain values in the interval 1 to 255. Zero is excluded in
order to make this counter similar to the MIB data sync counter.
II.1.6 Test, test response, and test result
The descriptions below indicate how Test, Test response, and Test result are related.
Test: This message is used to initiate either a self test or an MLT test (or additional tests
defined in future).
Test response: This message is an immediate reaction to a Test message. The "Test response"
message reports the ability of the ONT to run the required test, but it does not
contain any specific results.
Test result: This message is used to report the result of either a self test (requested by the OLT)
or a MLT test (or additional test defined in future). In the case of an
AUTONOMOUS self test, the Test result notification is not used. Instead,
notification is sent to the OLT via an alarm ONLY if the managed entity fails its
autonomous self test.
A test on a particular managed entity instance is invoked by sending a Test message to this instance.
Each managed entity that supports tests needs to have an action "Test" defined for it. The type of
test that is invoked by a Test message depends on the managed entity.
The "Test response" message is an indication to the OLT that the test request is received and is
being processed. The results of a requested test will be sent to the OLT via a specific "Test result"
message.
The "Test response" message will be sent immediately after the Test message is received
(i.e., within the normal response time). The transaction identifier of the "Test response" message is
identical to the transaction identifier of the Test message that requested the test.
II.2 Message layout

II.2.1 Create
It should be noted that the message contents for the "Create" message apply only to attributes that
are "Set-by-create". Thus, byte 13 begins with the attribute value for the first Set-by-create attribute
and so forth. If the message contains attributes that are not supported by the ONT, the ONT will
ignore the attributes, but it must allocate the space in the message to maintain delineation of the
attribute fields.
Field Byte 8 7 6 5 4 3 2 1 Comments

Transaction identifier 6-7
Message type 8 0 1 0 DB = 0, AR = 1, AK = 0
bits 5-1: action = create
Device identifier type 9 0 0 0 0 1 0 1 0 OMCI = 0x0A
Message identifier 10 entity class
11 MSB entity instance
12 LSB entity instance
ITU-T Rec. G.983.2 (07/2005) 321

Message contents 13 attribute value of first Set-by-create
attribute (size depending on the type of
attribute)
…
attribute value of last Set-by-create attribute
(size depending on the type of attribute)
xx-45 0 0 0 0 0 0 0 0 padding
II.2.2 Create response

bits 5-1: action = create
Message contents 13 0 0 0 0 x x x x result, reason
0000 = command processed successfully
0001 = command processing error
0010 = command not supported
0011 = parameter error
0100 = unknown managed entity
0101 = unknown managed entity instance
0110 = device busy
0111 = instance exists
14-45 0 0 0 0 0 0 0 0 padding
II.2.3 Create complete connection

bits 5-1: action = create complete
connection
Message contents 13 MSB ani VP Network CTPB-PON or
VC Network CTPB-PON instance
14 LSB ani VP Network CTPB-PON or
322 ITU-T Rec. G.983.2 (07/2005)

Message contents 15 MSB uni VP Network CTPB-PON or
16 LSB uni VP Network CTPB-PON or
17 MSB uni/ani pointer (= MSB corresponding
uni instance)
18 LSB uni/ani pointer (= LSB corresponding
uni instance)
19 MSB vpi ani side
20 LSB VPI ani side
21 MSB VPI uni side (= 0x00)
22 LSB VPI uni side
23 0 0 0 0 0 y x x direction/VP-VC choice
xx :
01 = uni-to-ani
10 = ani-to-uni
11 = bidirectional
y:
0 = create VP CTPs
1 = create VC CTPs
24 MSB priority queue pointer ani
VP Network CTPB-PON
25 LSB priority queue pointer ani VP Network
CTPB-PON
26 MSB priority queue pointer uni
VP Network CTPB-PON
27 LSB priority queue pointer uni VP Network
CTP
28 padding
29 padding
30 MSB traffic descriptor profile pointer
uni VP Network CTPB-PON
31 LSB traffic descriptor profile pointer uni
VP Network CTPB-PON
32 MSB VCI ani side (if VC CTP)
33 LSB VCI ani side (if VC CTP)
34 MSB VCI uni side (if VC CTP)
35 LSB VCI uni side (if VC CTP)
36-45 0 0 0 0 0 0 0 0 padding
ITU-T Rec. G.983.2 (07/2005) 323

II.2.4 Create complete connection response

bits 5-1: action = create complete
connection
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.5 Delete

bits 5-1: action = delete
Message contents 13-45 0 0 0 0 0 0 0 0 padding
II.2.6 Delete response

Message type 8 0 0 1 DB = 0, AR = 0, AK =1
bits 5-1: action = delete
324 ITU-T Rec. G.983.2 (07/2005)

Message contents 13 result, reason
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.7 Delete complete connection

bits 5-1: action = delete complete
connection
II.2.8 Delete complete connection response

bits 5-1: action = delete complete
connection
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
ITU-T Rec. G.983.2 (07/2005) 325

II.2.9 Set

bits 5-1: action = set
Message contents 13 MSB attribute mask
14 LSB attribute mask
15 attribute value of first attribute to set (size
depending on the type of attribute)
…
attribute value of last attribute to set (size
depending on the type of attribute)
xx-45 0 0 0 0 0 0 0 0 padding
II.2.10 Set response

bits 5-1: action = set
0110 = device busy
1001 = attribute(s) failed or unknown
14 "optional attribute" mask (attributes 1-8),
used with "1001" encoding:
0 = default
1 = unsupported attribute
0 = default
326 ITU-T Rec. G.983.2 (07/2005)

Message contents 16 "attribute execution" mask (attributes 1-8),
0 = default
1 = failed attribute
17 "attribute execution" mask (attributes 9-16),
0 = default
18-45 0 0 0 0 0 0 0 0 padding
II.2.11 Get

bits 5-1: action = get
15-45 0 0 0 0 0 0 0 0 padding
II.2.12 Get response

Note that the optional Attribute and Attribute Execution masks should always be assumed to be
present, even if result code 0x1001 is not returned. There is a consideration of interoperability on
this point. Some implementations do not assume the mask is always present (which is deprecated
behaviour). Even in this case, it can be shown that no failure occurs.

bits 5-1: action = get
ITU-T Rec. G.983.2 (07/2005) 327

0110 = device busy
14 MSB attribute mask
16 attribute value of first attribute included
…
attribute value of last attribute included
xx-41 0 0 0 0 0 0 0 0 padding
0 = default
0 = default
0 = default
0 = default
II.2.13 Get complete connection

bits 5-1: action = get complete connection
Message identifier 10 Entity class
328 ITU-T Rec. G.983.2 (07/2005)

II.2.14 Get complete connection response

bits 5-1: action = get complete connection
0110 = device busy
14 MSB ani VP Network CTPB-PON or
15 LSB ani VP Network CTPB-PON or
16 MSB uni VP Network CTPB-PON or
17 LSB uni VP Network CTPB-PON or VC
Network CTPB-PON instance
18 MSB uni/ani pointer (= msb corresponding
uni instance)
19 LSB uni/ani pointer (= lsb corresponding
uni instance)
20 MSB VPI ani side
21 LSB VPI ani side
22 MSB VPI uni side (= 0x00)
23 LSB VPI uni side
24 0 0 0 0 0 y x x direction/VP-VC choice
xx :
01 = uni-to-ani
10 = ani-to-uni
11 = bidirectional
y:
0 = create VP CTPs
1 = create VC CTPs
25 MSB priority queue pointer ani VP
Network CTPB-PON
26 LSB priority queue pointer ani VP Network
CTPB-PON
ITU-T Rec. G.983.2 (07/2005) 329

Message contents 27 MSB priority queue pointer uni
VP Network CTPB-PON
28 LSB priority queue pointer uni VP Network
CTPB-PON
29 padding
30 padding
31 MSB traffic descriptor profile pointer uni
VP Network CTPB-PON or padding
32 LSB traffic descriptor profile pointer uni
VP Network CTPB-PON or padding
33 MSB VCI ani side (if VC CTP)
34 LSB VCI ani side (if VC CTP)
35 MSB VCI uni side (if VC CTP)
36 LSB VCI uni side (if VC CTP)
37-45 0 0 0 0 0 0 0 0 padding
II.2.15 Get all alarms

bits 5-1: action = get all alarms
Message identifier 10 entity class = ONT Data
11 0 0 0 0 0 0 0 0 MSB entity instance
12 0 0 0 0 0 0 0 0 LSB entity instance
II.2.16 Get all alarms response

bits 5-1: action = get all alarms
Message contents 13 MSB of the number of subsequent
commands
14 LSB of the number of subsequent commands
15-45 0 0 0 0 0 0 0 0 padding
330 ITU-T Rec. G.983.2 (07/2005)

II.2.17 Get all alarms next

bits 5-1: action = get all alarms next
Message contents 13 MSB of the command sequence number
14 LSB of the command sequence number
15-45 0 0 0 0 0 0 0 0 padding
The command sequence numbers shall start from 0x00 onwards.

II.2.18 Get all alarms next response

bits 5-1: action = get all alarms next
Message contents 13 entity class on which the alarms are
reported
14 MSB entity instance on which the alarms
are reported
15 LSB entity instance on which the alarms are
reported
16-45 x x x x x x x x bitmap alarms
The bitmap that is used in the Get All Alarms Next response for a given managed entity class is
identical to the bitmap that is used in the alarm notifications for that managed entity class.
In the case the ONT has received an Get All Alarms Next request message in which the command
sequence number is out of range, the ONT shall respond with a message in which bytes 13 to 45 are
all set to 0x00. This corresponds to a response with entity class 0x00, entity instance 0x0000, and
bitmap all 0x00s.
ITU-T Rec. G.983.2 (07/2005) 331

II.2.19 MIB upload

bits 5-1: action = MIB upload
II.2.20 MIB upload response

bits 5-1: action = MIB upload
Message contents 13 MSB of the number of subsequent
commands
14 LSB of the number of subsequent
commands
15-45 0 0 0 0 0 0 0 0 padding
II.2.21 MIB upload next

bits 5-1: action = MIB upload next
Message contents 13 MSB of the command sequence number
15-45 0 0 0 0 0 0 0 0 padding
332 ITU-T Rec. G.983.2 (07/2005)

II.2.22 MIB upload next response

bits 5-1: action = MIB upload next
Message contents 13 entity class of object
14 MSB entity instance of object
15 LSB entity instance of object
18 value of first attribute (size depending on
the type of the attribute)
...
value of the last attribute (size depending
on the type of the attribute)
xx-45 0 0 0 0 0 0 0 0 padding
If the ONT receives a MIB Upload Next request message in which the command sequence number
is out of range, it shall respond with a message in which bytes 13 to 45 are all set to 0x00. This
corresponds to a response with entity class 0x00, entity instance 0x0000, attribute mask 0x0000,
and padding from byte 18 to byte 45.
Note that, if all attributes of a managed entity do not fit within one MIB Upload Next response
message, the attributes will be split over several messages. The OLT can use the information in the
attribute mask to determine which attribute values are reported in which MIB upload Next response
message.
II.2.23 MIB reset

bits 5-1: action = MIB reset
ITU-T Rec. G.983.2 (07/2005) 333

II.2.24 MIB reset response

bits 5-1: action = MIB reset
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.25 Alarm

bits 5-1: action = alarm
Message contents 13 alarm mask
…
42 alarm mask
43-44 0 0 0 0 0 0 0 0 padding
45 alarm sequence number
334 ITU-T Rec. G.983.2 (07/2005)

II.2.26 Attribute value change

bits 5-1: action = attribute value change
15 attribute value of first attribute changed
...
attribute value of last attribute changed
xx-45 0 0 0 0 0 0 0 0 padding
II.2.27 Test
The format of the test message is specific to the target entity class. At present, two formats are
defined. Future test extensions for a given entity class can be supported by adding additional
encodings to presently unused bits or bytes. Future specification of tests for other entity classes may
use an existing format or may define new formats for the test message. These extension
mechanisms allow future tests to be supported without changing the principle of operation.
Format for ONTb-pon, ONUb-pon, subscriber line card, PON line card entity classes

Transaction indentifier 6-7
bits 5-1: action = test
NOTE – This format applies to entity
classes ONTb-pon, ONUb-pon, subscriber
line card, PON line card.
13 0 0 0 0 x x x x xxxx = select test
0111 = self test
14-45 0 0 0 0 0 0 0 0 Padding
Format for POTS UNI and PPTP ISDN UNI entity classes
Note that a single message can be used to initiate multiple tests on a given ME if desired.
ITU-T Rec. G.983.2 (07/2005) 335

Bytes 14-27 are used by the dial tone make-break test. A zero value for a timer causes the ONT to
use its built-in defaults. As many as three dial tone frequencies can be specified, or omitted by
setting their values to 0. Other fields are also omitted with the value 0, or controlled by flags. An
ONT can support the dial tone test with internal defaults only, and is not required to support any of
the attributes of bytes 14-27. Likewise, an ONT can use internal defaults for drop test, rather than
the values given in bytes 28-37. The capabilities of an ONT are documented by the vendor and
known through the administration's practices.

Transaction indentifier 6-7
NOTE – This format applies to entity
classes PPTP POTS UNI and
PPTP ISDN UNI.
13 a 0 0 0 x x x x a – test mode
0 = normal; deny test if line busy
1 = forced mode
xxxx = select test
0000 = all MLT tests
0001 = hazardous potential
0010 = foreign EMF
0011 = resistive faults
0100 = receiver off-hook
0101 = ringer
0110 = NT1 dc signature test
0111 = self test
1000 = dial tone make-break test
14 DBDT timer T1 (slow dial tone threshold),
in units of 0.1 seconds. Range 0.1 to
6.0 seconds.
15 DBDT timer T2 (no dial tone threshold), in
units of 0.1 seconds.
Range 1.0 to 10.0 seconds.
16 DBDT timer T3 (slow break dial tone
threshold), in units of 0.1 seconds.
17 DBDT timer T4 (no break dial tone
threshold), in units of 0.1 seconds.
18 d p DBDT control byte
d: dialed digit
1 = dialed digit specified in byte 19
0 = use default digit
p = pulse (1) or tone (0) dialing
336 ITU-T Rec. G.983.2 (07/2005)

Message identifier 19 Digit to be dialed, ASCII character in range
"0"-"9", "*", "#".
20-21 Dial tone frequency 1, in units of Hz
22-23 Dial tone frequency 2, in units of Hz.
0 = unused (i.e., if only one tone is
specified)
24-25 Dial tone frequency 3, in units of Hz.
0 = unused (i.e., if only one or two tones are
specified)
26 Dial tone power threshold, absolute value,
0.1 dB resolution, range [–]0.1 to
[–]25.3 dBm0. E.g., –13 dBm0 = 0x82.
0x00 = unspecified
27 Idle channel power threshold, absolute
value, 1 dB resolution, range [–]1 to
[–]90 dBm0. 0x00 = unspecified
28 DC hazardous voltage threshold, absolute
value, volts 0x00 = unspecified
29 AC hazardous voltage threshold,
volts RMS 0x00 = unspecified
30 DC foreign voltage threshold, absolute
value, volts 0x00 = unspecified
31 AC foreign voltage threshold,
volts RMS 0x00 = unspecified
32 Tip-ground and ring-ground resistance
threshold, kΩ 0x00 = unspecified
33 Tip-ring resistance threshold,
kΩ 0x00 = unspecified
34-35 Ringer equivalence minimum threshold, in
0.01 REN units 0x00 = unspecified
36-37 Ringer equivalence maximum threshold,
in 0.01 REN units 0x00 = unspecified
38-45 0 0 0 0 0 0 0 0 Padding
II.2.28 Test response

If an ONT does not support all tests requested in byte 13 of the test message, it should not execute
any test and should respond with result 0010, command not supported. If an ONT supports all of the
requested tests but cannot support one or more of the explicitly specified threshold attributes, it
should not execute any test and should respond with result 0011, parameter error. The test
command could be re-issued with different thresholds or default thresholds, and would be expected
to succeed.
ITU-T Rec. G.983.2 (07/2005) 337

0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
The Test response message is an indication to the OLT that the test request is received and is being
processed.
II.2.29 Start software download

bits 5-1: action = start software download
Message identifier 10 entity class = software image
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
12 0 0 0 0 0 0 x x LSB entity instance
00 = first instance
01 = second instance
Message contents 13 window size – 1
14-17 image size in bytes
18-45 0 0 0 0 0 0 0 0 padding
338 ITU-T Rec. G.983.2 (07/2005)

II.2.30 Start software download response

bits 5-1: action = start software download
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
0110 = device busy
14 window size – 1
15-45 0 0 0 0 0 0 0 0 padding
II.2.31 Download section

Message type 8 0 x 0 DB = 0, AR = x, AK = 0
x = 0: no response expected (section within
the window)
x = 1: response expected (last section of a
window)
bits 5-1: action = sw download section
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
Message contents 13 download section number
14-45 data
ITU-T Rec. G.983.2 (07/2005) 339

II.2.32 Download section response

bits 5-1: action = sw download section
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
0110 = device busy
14 download section number
15-45 0 0 0 0 0 0 0 0 padding
II.2.33 End software download

bits 5-1: action = end software download
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
Message contents 13-16 CRC-32
17-20 image size in bytes
21-45 0 0 0 0 0 0 0 0 padding
340 ITU-T Rec. G.983.2 (07/2005)

II.2.34 End software download response

bits 5-1: action = end software download
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
(CRC correct)
(CRC incorrect)
(not applicable)
0011 = parameter error (not applicable)
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.35 Activate image

bits 5-1: action = activate image
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
ITU-T Rec. G.983.2 (07/2005) 341

II.2.36 Activate image response

bits 5-1: action = activate image
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.37 Commit image

bits 5-1: action = commit image
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
342 ITU-T Rec. G.983.2 (07/2005)

II.2.38 Commit image response

bits 5-1: action = commit image
0 = ONTB-PON
1, 2, ..., 127 = UNI card
129, 130, ..., 255 = ANI card
00 = first instance
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.39 Synchronize time

bits 5-1: action = synchronize time
ITU-T Rec. G.983.2 (07/2005) 343

II.2.40 Synchronize time response

bits 5-1: action = synchronize time
Message contents 13 Result, reason
0110 = device busy
14-45 0 0 0 0 0 0 0 0 padding
II.2.41 Reboot

Message type 8 0 1 0 DB = 0, AR =1, AK = 0
bits 5-1: action = reboot
344 ITU-T Rec. G.983.2 (07/2005)

II.2.42 Reboot response

bits 5-1: action = reboot
Message contents 13 result, reason
0110 = device busy
14-45 padding
II.2.43 Get next

bits 5-1: action = get next
15 MSB of the command sequence number
17-45 0 0 0 0 0 0 0 0 padding
ITU-T Rec. G.983.2 (07/2005) 345

II.2.44 Get next response

Message type 8 0 0 1 DB = 0, AR = 0, AK =1
bits 5-1: action = get next
0110 = device busy
…
xx-45 0 0 0 0 0 0 0 0 padding
If the ONT receives a "Get next request" message in which the command sequence number is out of
range, the ONT shall respond with a message in which bytes 13 to 45 are all set to 0x00. This
corresponds to a response with entity class 0x00, entity instance 0x0000, attribute mask 0x0000,
and padding from byte 16 to byte 45.
II.2.45 Test result
The test result message is used to report the result of a test. The transaction identifier of the test
result message is identical to the transaction identifier of the test message that initiated the
corresponding test.
Two formats are currently defined, one of which reports the result of a self test (any ME that
supports self test), the other of which reports the results of a dial tone draw-break test (PPTP POTS
UNI) or an MLT test (PPTP POTS UNI or PPTP ISDN UNI). If a new test for the
presently-supported entities is defined in the future, the corresponding test results can be reported
by extending the test result message layout. If a new test for other managed entity classes is defined
in the future, a new test result message layout may be defined.
346 ITU-T Rec. G.983.2 (07/2005)

Format for ONTb-pon, ONUb-pon, subscriber line card, PON line card entity classes

bits 5-1: action = test result
Message identifier 10 entity class.
NOTE – This message format pertains to
ONTb-pon, ONUb-pon, subscriber line
card, PON line card entity classes.
Message contents 13 0 0 0 0 0 0 0 0 Unused
14 0 0 0 0 0 0 x x self test result:
xx = 00: failed
xx = 01: passed
xx = 10: not completed
15-45 0 0 0 0 0 0 0 0 padding
Format for POTS UNI and PPTP ISDN UNI entity classes
Byte 13 reports a summary MLT test result. The result for each test category is limited to the two
values "test passed or was not executed" or "test failed." Bytes 15 and 16 report the results of a dial
tone test.
Byte 14 reports the result of a self test. At present, self test is not supported for the POTS UNI and
PPTP ISDN UNI entity classes, and this byte should be set to 0.
There are four possible outcomes for a given test – it can pass, fail, not be run, or not be recognized
by the ONT. If an ONT does not support or recognize a given test, it is expected to deny the test
request message. To avoid physical damage, an ONT may cease testing if a test fails, and thus some
subsequent test will not be run. In addition, the ONT may support some but not all tests of a given
suite, such as power measurements in the dial tone test sequence. The category summary in byte 13
includes two values. The value 1 indicates either that all tests in a category passed or that nothing in
the category was tested, while 0 indicates that at least one test in the category failed. Further
information appears in flags specific to each test results attribute to indicate whether each detailed
test was run or not, whether it passed or failed and whether a measured result is reported or not.

bits 5-1: action = test result
Message identifier 10 entity class.
NOTE – This message format pertains to
PPTP POTS UNI and PPTP ISDN UNI
entity classes.
ITU-T Rec. G.983.2 (07/2005) 347

Message identifier 12 LSB entity instance
Message contents 13 0 0 a b c d e f MLT drop test result:
0 = fail test a/b/c/d/e/f
1 = pass test, or test not run
a/b/c/d/e/f
a = hazardous potential
b = foreign EMF
c = resistive faults
d = receiver off-hook
e = ringer
f = NT 1 dc signature test
14 0 0 0 0 0 0 x x self test result:
xx = 00: failed
xx = 01: passed
xx = 10: not completed
15 b b b d d d Dial tone make-break flags:
ddd – Dial tone draw
= 000 test not run
= 01m failed, could not draw
= 10m slow draw
= 11m passed
bbb – Dial tone break
= 000 test not run
= 01m failed, could not break
= 10m slow break
= 11m passed
m – measured value flag
= 0 measurement not reported
= 1 measurement reported
16 a a a b b b Dial tone power flags:
aaa – Quiet channel power
bbb – Dial tone power
See Note.
17 a a a b b b Loop test DC voltage flags
aaa – VDC, tip-ground
bbb – VDC, ring-ground
See Note.
18 a a a b b b Loop test AC voltage flags
aaa – VAC, tip-ground
bbb – VAC, ring-ground
See Note.
19 a a a b b b Loop test resistance flags 1
aaa – Resistance, tip-ground
bbb – Resistance, ring-ground
See Note.
348 ITU-T Rec. G.983.2 (07/2005)

Message identifier 20 a a a b b b Loop test resistance flags 2
aaa – Resistance, tip-ring
bbb – Ringer load test
See Note.
21 Time to draw dial tone, in 0.1 second units.
Valid only if byte 15 ddd = xx1.
22 Time to break dial tone, in 0.1 second units.
Valid only if byte 15 bbb = xx1.
23 Total dial tone power measurement,
unsigned absolute value, 0.1 dB resolution,
range 0 to [–]25.5 dBm0. Values above 0
dBm0 are reported as 0. Valid only if byte
16 bbb = xx1.
24 Quiet channel power measurement,
unsigned absolute value, 1 dB resolution,
range 0 to [–]90 dBm0. Valid only if byte
16 aaa = xx1.
25-26 Tip-ground DC voltage, 2's complement,
resolution 1V. Valid only if byte
17 aaa = xx1.
27-28 Ring-ground DC voltage, 2's complement,
resolution 1V. Valid only if byte
17 bbb = xx1.
29 Tip-ground AC voltage, Vrms. Valid only if
byte 18 aaa = xx1.
30 Ring-ground AC voltage, Vrms. Valid only
if byte 18 bbb = xx1.
31-32 Tip-ground DC resistance, kOhm. Infinite
resistance: 0xffff. Valid only if byte 19 aaa
= xx1.
33-34 Ring-ground DC resistance, kOhm. Infinite
resistance: 0xffff. Valid only if byte 19 bbb
= xx1.
35-36 Tip-ring DC resistance, kOhm. Infinite
resistance: 0xffff. Valid only if byte 20 aaa
= xx1.
37 Ringer equivalence, in 0.1 REN units. Valid
only if byte 20 bbb = xx1.
38-45 0 0 0 0 0 0 0 0 padding
NOTE – Coding for 3 bit flag sets is as follows:
= 000 test not run
= 010 fail, measurement not reported
= 011 fail, measurement reported
= 110 pass, measurement not reported
= 111 pass, measurement reported
ITU-T Rec. G.983.2 (07/2005) 349

II.2.46 Get current data

bits 5-1: action = get current data
15-45 0 0 0 0 0 0 0 0 padding
II.2.47 Get current data response

Note that the optional Attribute and Attribute Execution masks should always be assumed to be
present, even if result code 0x1001 is not returned. There is a consideration of interoperability on
this point. Some implementations do not assume the mask is always present (which is deprecated
behaviour). Even in this case, it can be shown that no failure occurs.

bits 5-1: action = get current data
0110 = device busy
…
xx-41 0 0 0 0 0 0 0 0 padding
350 ITU-T Rec. G.983.2 (07/2005)

Message contents 42 "optional attribute" mask (attributes 1-8),
0 = default
0 = default
0 = default
0 = default
Appendix III
Support of F4/F5 maintenance flows in the ONT

III.1 General principle
The general principle regarding F4 and F5 maintenance flows in the ONT is to use the ITU-T
Rec. I.610 [8] procedures wherever possible and to restrict the OMCI requirements to the strictly
essential ones. The use of these procedures is largely independent of OMCI. The objective of this
appendix is to clarify OMCI-related aspects.
III.2 Definition of the F4/F5 segment and end-to-end applicability

III.2.1 Support of F4/F5 maintenance flows with respect to ATM-UNIs
Segment F4 maintenance flow
The ONT always behaves as a Segment end point for the F4 segment maintenance flow towards
the OLT.
The VP Network CTPB-PON located at the UNI side is by default the Segment end point.
End-to-end F4 maintenance flow
By definition the ONT is not involved.
Segment F5 and end-to-end F5 maintenance flows
By definition the ONT is not involved.
III.2.2 Support of F4/F5 maintenance flows with respect to non-ATM-UNIs
Segment F4 and end-to-end F4 maintenance flow
The ONT always behaves as a segment end point for the F4 Segment and End-to-end maintenance
flow towards the OLT.
ITU-T Rec. G.983.2 (07/2005) 351

The VP Network CTPB-PON that supports the Interworking VCC Termination Point is by default the
Segment end point.
Segment F5 and end-to-end F5 maintenance flows
The ONT always behaves as a segment end point for the F5 Segment and End-to-end maintenance
flow towards the OLT.
The Interworking VCC Termination Point is by default a Segment and End-to-end point.
III.3 OMCI support of F4/F5 flows in the ONT

III.3.1 OMCI support of AIS and RDI fault management
Report of End-to-end VP-AIS and VP-RDI, VC-AIS, VC-RDI receiving and generation alarms on
the VP Network CTPB-PON and the Interworking VCC Termination Point respectively.
III.3.2 OMCI support of F4/F5 continuity check procedures
The activation and deactivation of the Continuity Check from the OLT as well as towards the OLT
is done via in-band ITU-T Rec. I.610 [8] activation and deactivation procedures. OMCI supports
the reporting of Loss of Continuity alarm on the VP Network CTPB-PON and the Interworking
III.3.3 OMCI support of F4/F5 loopback procedures
The ONT supports loopback point functionality. The insertion of the loopback cell and the reporting
of the loopback result are not required in the ONT. The OMCI supports setting of the loopback
location identifier in selected PPTP entities described in 7.3.
III.3.4 OMCI support of F4/F5 performance monitoring
The OMCI provides performance monitoring support via the performance monitoring managed
entities. Creation of a PM entity will activate the PM feature, and deletion of the entity will
deactivate the monitoring. In-band control and reporting of the PM features is not supported.
352 ITU-T Rec. G.983.2 (07/2005)

Appendix IV
Traffic management options
Depending on the trade-off between the complexity and the number of supported features, the ONT
can have various traffic management options. Examples of traffic management implementation in
the ONT are described in the following clauses. This appendix also indicates how the MIB defined
in clause 7 is used for each implementation.
It should be pointed out that the ONT traffic management is not limited to these examples. ONT
traffic management is likely a place where every vendor searches for a proprietary feature to give it
a competitive advantage. However, every proprietary feature requires some kind of management
that impacts the OMCI. In fact, it is difficult for the specification given in this Recommendation to
keep up with the technological and feature innovations. It is envisioned that vendor-specific
managed entities will be needed to manage the traffic management related functions in the ONT.
IV.1 Priority QueueB-PON

When the focus is on low complexity implementation, the ONT uses the priority controlled
upstream traffic method. In this case, the ONT has no traffic contract or QoS awareness. The ONT
is configured by the OLT with a priority for each connection for both directions.
Theoretically, UPC is needed at every multiplexing point, including the ONT. A system with the
UPC function has to monitor the traffic volume entering the network from all active VP/VC
connections to ensure that the agreed parameters are not violated and to deploy a cell discard or tag
policy. In the priority queue implementation, the UPC function is moved to the OLT, where it
protects the core network. The PON is protected by the "UPC-like" MAC. The MAC manages all
connections from an ONT as a whole. Essentially, the MAC isolates ONTs from each other.
As such, CPEs sharing one ONT may have to regulate their own connection streams to maintain
quality. A CPE sending out more cells on one connection will do so at the expense of the other
connections established at the same ONT.
OMCI requirements:
The traffic management option in the ONTB-PON managed entity is set to 0x00.
For the VP Network CTPB-PON at the ANI side:
Priority Queue Pointer for Upstream: using priority QueueB-PON managed entity id.
ITU-T Rec. G.983.2 (07/2005) 353

IV.2 Clarification of ONT functional blocks
Figures IV.1 and IV.2 show the ONT functional blocks for the ATM UNI case and for the
non-ATM UNI case.
Figure IV.1/G.983.2 − ONT functional block diagrams for VC service
354 ITU-T Rec. G.983.2 (07/2005)

Figure IV.2/G.983.2 − ONT functional block diagrams for VP service
IV.3 An example of the traffic scheduler configuration

An example of the configuration of the Traffic Scheduler is proposed in Figure IV.3. This model
consists of three stages, such as 2 delay control and 1 guaranteed rate control stages. A delay
control stage can be worked by Head Of the Line (HOL) scheduling. A guaranteed rate control
stage can be worked by WRR.
ITU-T Rec. G.983.2 (07/2005) 355

Figure IV.3/G.983.2 – Architectural model in ONT
There are two operations using the above model, such as delay prioritized and guaranteed
prioritized policies. These configurations can be shown in Figures IV.4 and IV.5.
Figure IV.4/G.983.2 – Configuration of delay prioritized model
356 ITU-T Rec. G.983.2 (07/2005)

Figure IV.5/G.983.2 – Configuration of guaranteed rate prioritized model
Appendix V
MAC addresses and Ether types
Table V.1/G.983.2 – MAC address and Ether type for various protocols
# Protocol MAC address Ether type Standard
1 IPv4 Multicast 0x01005E000000 ~ – RFC 1700 [B-15]
0x01005E7FFFFF
2 IPv6 Multicast 0x333300000000 ~ – RFC 2464 [B-16]
0x3333FFFFFFFF
3 IPv4 Broadcast 0xFFFFFFFFFFFF 0x0800 RFC 1700 [B-15]
4 RARP 0xFFFFFFFFFFFF 0x8035 RFC 1700 [B-15]
0xFFFFFFFFFFFF 0x8137
5 IPX 0x09001BFFFFFF, – RFC 1700 [B-15]
0x09004E000002
6 NetBEUI 0x030000000001 –
0xFFFFFFFFFFFF 0x809B, RFC 1700 [B-15]
0x80F3
7 AppleTalk 0x090007000000 ~ –
0x0900070000FC,
0x090007FFFFFF
8 Bridge Management 0x0180C2000000 ~ – IEEE 802.1D [13]
Information 0x0180C20000FF
9 ARP 0xFFFFFFFFFFFF 0x0806 RFC 1700 [B-15]
10 PPPoE Broadcast 0xFFFFFFFFFFFF 0x8863 RFC 2516 [B-17]
ITU-T Rec. G.983.2 (07/2005) 357

Appendix VI
Transparent support of video return path service

VI.1 Network overview
This clause considers support of the video return path. The following configurations are presented:
Configuration 1:
Figure VI.1/G.983.2 – A B-PON with ONT transparent support of interactive video services
In this type of configuration, the STB is Ethernet capable and can perform the TCP/IP protocols to
configure itself and exchange information between the STB and the video control system.
The ONT transparently bridges the STB data to a BRAS which terminates the ATM layer and
forwards the extracted Ethernet packets to the video control system.
This configuration requires no new B-PON Standardization
Configuration 2:
Figure VI.2/G.983.2 – A B-PON interactive video services with external VRP adaptation
In this configuration, the STB is compliant with SCTE 55-1/-2 and interfaces to an external
VRP device that terminates the RF and performs the adaptation function from RF to Ethernet.
The interface between the ONT and the VRP device is Ethernet.
This configuration does not require new B-PON standardization.
358 ITU-T Rec. G.983.2 (07/2005)

Configuration 3:
Figure VI.3/G.983.2 – A B-PON interactive video services with internal VRP adaptation
In this configuration, the STB is compliant with SCTE 55-1/-2 and interfaces to an internal
VRP device that terminates the RF and performs the adaptation function from RF to Ethernet for
input to the 802.1 D bridge in the ONT.
This configuration does not require new B-PON standardization.
ITU-T Rec. G.983.2 (07/2005) 359

BIBLIOGRAPHY
[B-1] ATM Forum AF-NM-0020.001 (1998), M4 Interface Requirements and Logical MIB: ATM
Network Element View.
[B-2] ATM Forum AF-PHY-0016.000 (1994), DS1 Physical Layer Specification.
[B-3] ATM Forum AF-PHY-0064.000 (1996), E1 Physical Interface Specification.
[B-4] ATM Forum AF-PHY-0029.000 (1995), 6312 kbit/s UNI Specification, Version 1.0.
[B-5] ATM Forum AF-PHY-0040.000 (1995), Physical Interface Specification for 25.6 Mb/s
over Twisted Pair Cable.
[B-6] ATM Forum AF-PHY-0034.000 (1995), E3 Public UNI.
[B-7] ATM Forum AF-PHY-0054.000 (1996), DS3 Physical Layer Interface Specification.
[B-8] ATM Forum AF-UNI-0010.002 (1994), ATM User-Network Interface Specification,
Version 3.1.
[B-9] ATM Forum AF-TM-0056.000 (1996), Traffic Management Specification, Version 4.0.
[B-10] ATM Forum AF-VTOA-0113.000 (1999), ATM Trunking using AAL 2 for Narrowband
Services.
[B-11] ATM Forum AF-VMOA-0145.000 (2000), Voice and Multimedia Over ATM-Loop
Emulation Service Using AAL 2.
[B-12] ETSI TS 101 270-1 (1999-10), Transmission and Multiplexing (TM); Access transmission
systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL);
Part 1: Functional requirements.
[B-13] IETF RFC 815 (1982), IP Datagram Reassembly Algorithms.
[B-14] IETF RFC 1213 (1991), Management Information Base for Network Management of
TCP/IP-based internets: MIB-II.
[B-15] IETF RFC 1700 (1994), Assigned Numbers.
[B-16] IETF RFC 2464 (1998), Transmission of IPv6 Packets over Ethernet Networks.
[B-17] IETF RFC 2516 (1999), A Method for Transmitting PPP Over Ethernet (PPPoE).
[B-18] IETF RFC 2662 (1999), Definitions of Managed Objects for ADSL Lines.
[B-19] IETF RFC 3440 (2002), Definitions of Extension Managed Objects for Asymmetric Digital
Subscriber Lines.
[B-20] ITU-T Recommendation G.992.1 (1999), Asymmetric digital subscriber line (ADSL)
transceivers.
[B-21] ITU-T Recommendation G.992.2 (1999), Splitterless asymmetric digital subscriber line
(ADSL) transceivers.
[B-22] ITU-T Recommendation G.992.3 (2005), Asymmetric digital subscriber line
transceivers 2 (ADSL2).
[B-23] ITU-T Recommendation G.992.4 (2002), Splitterless asymmetric digital subscriber line
transceivers 2 (splitterless ADSL2).
[B-24] ITU-T Recommendation G.992.5 (2005), Asymmetric digital subscriber line (ADSL)
transceivers – Extended bandwidth ADSL2 (ADSL2+).
360 ITU-T Rec. G.983.2 (07/2005)

[B-25] ITU-T Recommendation G.994.1 (2003), Handshake procedures for digital subscriber line
(DSL) transceivers.
[B-26] ITU-T Recommendation T.35 (2000), Procedure for the allocation of ITU-T defined codes
for non-standard facilities.
[B-27] IETF RFC 4069 (2005), Definitions of Managed Object Extensions for Very High Speed
Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding.
[B-28] IETF RFC 4070 (2005), Definitions of Managed Object Extensions for Very High Speed
Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding.
[B-29] DSL Forum TR-057 (2003), VDSL Network Element Management.
ITU-T Rec. G.983.2 (07/2005) 361

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

T Rec G.983.2 200507 I!!pdf e PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

T Rec G.983.2 200507 I!!pdf e PDF

Hochgeladen von

Copyright:

Verfügbare Formate

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

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

ONT management and control interface

ITU-T Recommendation G.983.2

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

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

ONT management and control interface specification for B-PON

ITU-T Rec. G.983.2 (07/2005) i

INTELLECTUAL PROPERTY RIGHTS

ii ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) iii

iv ITU-T Rec. G.983.2 (07/2005)

ONT management and control interface specification for B-PON

ITU-T Rec. G.983.2 (07/2005) 1

2 ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) 3

4 ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) 5

6 ITU-T Rec. G.983.2 (07/2005)

4.1 OMCI in ITU-T Rec. G.983.1

Figure 1/G.983.2 − Reference model

ITU-T Rec. G.983.2 (07/2005) 7

Figure 2/G.983.2 − Protected reference model-1

Figure 3/G.983.2 − Protected reference model-2

8 ITU-T Rec. G.983.2 (07/2005)

Figure 4/G.983.2 − Protected reference model-3

4.2 ONT functions

Figure 5/G.983.2 − ONT functional diagram

4.2.1 Protection switching modelling

ITU-T Rec. G.983.2 (07/2005) 9

Figure 6/G.983.2 − 1+1 model ONT (ANI side)

Figure 7/G.983.2 − 1:1 model ONT (ANI side)

4.2.2 Dynamic bandwidth assignment modelling

10 ITU-T Rec. G.983.2 (07/2005)

Figure 8/G.983.2 − ONT model 1

Figure 9/G.983.2 − ONT model 2

ITU-T Rec. G.983.2 (07/2005) 11

Figure 10/G.983.2 − ONT model with traffic scheduler

4.3 VP and VC Mux functionality in the ONT

5 Requirements of the management interface specification

12 ITU-T Rec. G.983.2 (07/2005)

5.1 Configuration management

ITU-T Rec. G.983.2 (07/2005) 13

Figure 12/G.983.2 − VC cross-connection termination model

14 ITU-T Rec. G.983.2 (07/2005)

5.2 Fault management

5.3 Performance management

ITU-T Rec. G.983.2 (07/2005) 15

5.4 Security management

6 Protocol-independent MIB for the OMCI

16 ITU-T Rec. G.983.2 (07/2005)

6.1 Managed entities

Table 1/G.983.2 − Managed entities in the OMCI

ITU-T Rec. G.983.2 (07/2005) 17

18 ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) 19

20 ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) 21

22 ITU-T Rec. G.983.2 (07/2005)

Figure 13/G.983.2 − Legend for managed entity relation diagrams

ITU-T Rec. G.983.2 (07/2005) 23

24 ITU-T Rec. G.983.2 (07/2005)

ITU-T Rec. G.983.2 (07/2005) 25