T Rec G.988 201210 I!!pdf e

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
ITU-T
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
U n i o n
G.988
(10/2012)
SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Digital sections and digital line system Optical line
systems for local and access networks
ONU management and control interface (OMCI)

specification
Recommendation ITU-T G.988
ITU-T G-SERIES RECOMMENDATIONS

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

ONU management and control interface (OMCI) specification
Summary
Recommendation ITU-T G.988 specifies the optical network unit (ONU) management and control
interface (OMCI) for optical access networks.
This Recommendation specifies the managed entities of a protocol-independent management
information base (MIB) that models the exchange of information between an optical line termination
(OLT) and an optical network unit (ONU). In addition, it covers the ONU management and control
channel, protocol and detailed messages.
History
Edition Recommendation
Approval
Study Group
2010-10-07
15
1.1
ITU-T G.988 (2010) Amd. 1 2011-04-13
15
1.2
ITU-T G.988 (2010) Amd. 2 2012-04-22
15
1.3
ITU-T G.988 (2010) Cor. 1
2012-06-13
15
2012-10-29
15
1.0
2.0
ITU-T G.988
ITU-T G.988
Keywords
G-PON, OMCI, PON, XG-PON.
Rec. ITU-T G.988 (10/2012)
FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on
these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some
other obligatory language such as "must" and the negative equivalents are used to express requirements. The
use of such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may
involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,
validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
outside of the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementers
are cautioned that this may not represent the latest information and are therefore strongly urged to consult the
TSB patent database at http://www.itu.int/ITU-T/ipr/.
ITU 2013
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the
prior written permission of ITU.
ii
Rec. ITU-T G.988 (10/2012)
Table of Contents
Page
1
Scope ............................................................................................................................
References.....................................................................................................................
Definitions ....................................................................................................................
3.1
Terms defined elsewhere ................................................................................
3.2
Terms defined in this Recommendation .........................................................
5
5
5
Abbreviations and acronyms ........................................................................................
Conventions ..................................................................................................................
12
Reference model and terms ..........................................................................................

6.1
OMCI in the access network ..........................................................................
6.2
ONU functions................................................................................................
6.3
Support of multicast connection .....................................................................
6.4
Voice over IP management ............................................................................
13
13
13
13
14
Requirements of the management interface specification ............................................

7.1
Configuration management ............................................................................
7.2
Fault management ..........................................................................................
7.3
Performance management ..............................................................................
7.4
Security management .....................................................................................
15
15
16
16
16
Protocol-independent MIB for the OMCI ....................................................................

8.1
Managed entities .............................................................................................
8.2
Managed entity relation diagrams ..................................................................
16
17
24
MIB description ............................................................................................................

9.1
Equipment management .................................................................................
9.2
ANI management, traffic management ..........................................................
9.3
Layer 2 data services ......................................................................................
9.4
Layer 3 data services ......................................................................................
9.5
Ethernet services .............................................................................................
9.6
This clause is intentionally left blank .............................................................
9.7
xDSL services .................................................................................................
9.8
TDM services .................................................................................................
9.9
Voice services .................................................................................................
9.10
Premises networks ..........................................................................................
9.11
This clause is intentionally left blank .............................................................
9.12
General purpose MEs .....................................................................................
9.13
Miscellaneous services ...................................................................................
9.14
Mid-span PON reach extender .......................................................................
46
49
82
108
184
194
206
206
275
304
338
343
343
360
377
10
This clause is intentionally left blank ...........................................................................
392
11
ONU management and control protocol .......................................................................
392
Rec. ITU-T G.988 (10/2012)
iii
Baseline and extended messages ....................................................................

Common message characteristics ...................................................................
Page
392
393
Annex A OMCI message syntax and common features .......................................................

A.1
General ...........................................................................................................
A.2
Extended message set .....................................................................................
A.3
Baseline message set ......................................................................................
407
407
416
460
Annex B OMCI in ITU-T G.984 and ITU-T G.987 systems ................................................

B.1
Establishing the ONU management and control channel (OMCC) ...............
B.2
OMCI handling within the ONU ....................................................................
502
502
503
Annex C OMCI in Ethernet PON systems ...........................................................................

C.1
Establishing the ONU management and control channel (OMCC) ...............
C.2
Encapsulating OMCI messages in Ethernet frames .......................................
C.3
Relationship between the OMCI and OAM defined in IEEE 802.3,
clause 57 .........................................................................................................
C.4
Adaptation of the G-PON information model to EPON ................................
508
508
509
Appendix I OMCI common services ....................................................................................

I.1
ONU MIB management .................................................................................
I.2
Equipment management .................................................................................
I.3
Software upgrade ............................................................................................
I.4
Performance monitoring .................................................................................
515
515
522
533
538
Appendix II G-PON mechanisms and services.....................................................................

II.1
Layer 2 data service according to [b-BBF TR-156] .......................................
II.2
Dual-managed ONUs .....................................................................................
II.3
Traffic management........................................................................................
II.4
Voice services .................................................................................................
545
545
559
562
577
Appendix III This appendix is intentionally left blank .........................................................
583
Bibliography.............................................................................................................................
584
11.1
11.2
iv
Rec. ITU-T G.988 (10/2012)
510
510

ONU management and control interface (OMCI) specification
1
Scope
This Recommendation specifies the optical network unit (ONU) management and control interface
(OMCI) for optical access networks as defined in [ITU-T G.984.x], [ITU-T G.986],
[ITU-T G.987.x] and potentially others.
The OMCI specification addresses ONU configuration, fault management and performance
management for optical access system operation, and for several services including:
GEM adaptation layers
Ethernet services, including MAC bridged LAN
circuit emulation service
voice services.
This Recommendation defines a protocol necessary to support the capabilities identified for these
ONUs. 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.
[ITU-T E.164]
Recommendation ITU-T E.164 (2005), The international public

telecommunication numbering plan.
[ITU-T G.704]
Recommendation ITU-T G.704 (1998), Synchronous frame structures used at

1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels.
[ITU-T G.722.1]
Recommendation ITU-T G.722.1 (2005), Low-complexity coding at 24 and

32 kbit/s for hands-free operation in systems with low frame loss.
[ITU-T G.722.2]
Recommendation ITU-T G.722.2 (2003), Wideband coding of speech at

around 16 kbit/s using Adaptive Multi-Rate Wideband (AMR-WB).
[ITU-T G.723.1]
Recommendation ITU-T G.723.1 (2006), Dual rate speech coder for

multimedia communications transmitting at 5.3 and 6.3 kbit/s.
[ITU-T G.728]
Recommendation ITU-T G.728 (1992), Coding of speech at 16 kbit/s using

low-delay code excited linear prediction.
[ITU-T G.729]
Recommendation ITU-T G.729 (2007), Coding of speech at 8 kbit/s using

conjugate-structure algebraic-code-excited linear prediction (CS-ACELP).
[ITU-T G.784]
Recommendation ITU-T G.784 (2008), Management aspects of synchronous

digital hierarchy (SDH) transport network elements.
[ITU-T G.826]
Recommendation ITU-T G.826 (2002), End-to-end error performance

parameters and objectives for international, constant bit-rate digital paths and
connections.
Rec. ITU-T G.988 (10/2012)
[ITU-T G.983.2]
Recommendation ITU-T G.983.2 (2005), ONT management and control

interface specification for B-PON.
[ITU-T G.984.x]
Recommendations ITU-T G.984.x-series, Gigabit-capable passive optical

networks (G-PON).
[ITU-T G.984.3]
Recommendation ITU-T G.984.3 (2008), Gigabit-capable Passive Optical

Networks (G-PON): Transmission convergence layer specification.
[ITU-T G.984.4]
Recommendation ITU-T G.984.4 (2008), Gigabit-capable passive optical

networks (G-PON): ONT management and control interface specification.
[ITU-T G.984.6]
Recommendation ITU-T G.984.6 (2008), Gigabit-capable passive optical

networks (GPON): Reach extension.
[ITU-T G.986]
Recommendation ITU-T G.986 (2010), 1 Gbit/s point-to-point Ethernet-based

optical access system.
[ITU-T G.987.x]
Recommendations ITU-T G.987 .x-series, 10 Gigabit-capable passive optical

network (XG-PON) systems.
[ITU-T G.987]
Recommendation ITU-T G.987 (10/2010), 10-Gigabit-capable passive optical

network (XG-PON) systems: Definitions, abbreviations, and acronyms.
[ITU-T G.987.1]
Recommendation ITU-T G.987.1 (2010), 10-Gigabit-capable passive optical

networks (XG-PON): General requirements.
[ITU-T G.987.3]
Recommendation ITU-T G.987.3 (2010), 10-Gigabit-capable passive optical

networks (XG-PON): Transmission convergence (TC) layer specification.
[ITU-T G.992.1]
Recommendation ITU-T G. 992.1 (1999), Asymmetric digital subscriber line

(ADSL) transceivers.
[ITU-T G.992.2]
Recommendation ITU-T G.992.2 (1999), Splitterless asymmetric digital

subscriber line (ADSL) transceivers.
[ITU-T G.992.3]
Recommendation ITU-T G. 992.3 (2009), Asymmetric digital subscriber line

transceivers 2 (ADSL2).
[ITU-T G.992.4]
Recommendation ITU-T G. 992.4 (2002), Splitterless asymmetric digital

subscriber line transceivers 2 (splitterless ADSL2).
[ITU-T G.992.5]
Recommendation ITU-T G. 992.5 (2009), Asymmetric digital subscriber line 2

transceivers (ADSL2) Extended bandwidth ADSL2 (ADSL2plus).
[ITU-T G.993.1]
Recommendation ITU-T G.993.1 (2004), Very high speed digital subscriber

line transceivers (VDSL).
[ITU-T G.993.2]
Recommendation ITU-T G.993.2 (in force), Very high speed digital subscriber
line transceivers 2 (VDSL2).
[ITU-T G.994.1]
Recommendation ITU-T G.994.1 (in force), Handshake procedures for digital

subscriber line transceivers.
[ITU-T G.997.1]
Recommendation ITU-T G.997.1 (2009), Physical layer management for

digital subscriber line (DSL) transceivers.
[ITU-T H.248.x]
Recommendations ITU-T H.248 .x-series, Gateway control protocol.
[ITU-T H.341]
Recommendation ITU-T H.341 (1999), Multimedia management information

base.
[ITU-T I.112]
Recommendation ITU-T I.112 (1993), Vocabulary of terms for ISDNs.
Rec. ITU-T G.988 (10/2012)
[ITU-T I.363.5]
Recommendation ITU-T I.363.5 (1996), B-ISDN ATM Adaptation Layer

specification: Type 5 AAL.
[ITU-T M.3100]
Recommendation ITU-T M.3100 (2005), Generic network information

model.
[ITU-T T.35]
Recommendation ITU-T T.35 (2000), Procedure for the allocation of ITU-T

defined codes for non-standard facilities.
[ITU-T T.38]
Recommendation ITU-T T.38 (2007), Procedures for real-time Group 3

facsimile communication over IP networks.
[ITU-T X.690]
Recommendation ITU-T X.690 (2008)| ISO/IEC 8825-1:2008, Information

technology ASN.1 encoding rules: Specification of Basic EncodingRules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[ITU-T X.731]
Recommendation ITU-T X.731 (1992)| ISO/IEC 10164-2:1993, Information

technology Open Systems Interconnection Systems management: State
management function.
[ITU T X.733]
Recommendation ITU T X.733 (1992) | ISO/IEC 10164-4:1992, Information

technology Open Systems Interconnection Systems management: Alarm
reporting function.
[ITU-T Y.1731]
Recommendation ITU-T Y.1731 (2008), OAM functions and mechanisms for

Ethernet based networks.
[ATIS-0300220]
ATIS-0300220.2011, Representation of the Communications Industry

Manufacturers, Suppliers, and Related Service Companies for Information
Exchange.
[BBF TR-069]
Broadband Forum TR-069 Amendment 2 (2007), CPE WAN Management

Protocol v1.1.
[ETSI TS 101 270-1] ETSI TS 101 270-1 V1.4.1 (2005), Transmission and Multiplexing (TM);
Access transmission systems on metallic access cables; Very high speed
Digital Subscriber Line (VDSL); Part 1: Functional requirements.
[ETSI TS 101 388]
ETSI TS 101 388 V1.4.1 (2007), Access Terminals Transmission and

Multiplexing (ATTM); Access transmission systems on metallic access
cables; Asymmetric Digital Subscriber Line (ADSL) European specific
requirements [Recommendation ITU-T G.992.1 modified].
[IEEE 802]
IEEE 802-2001 (R2007), IEEE Standard for Local and Metropolitan Area
Networks Overview and Architecture.
[IEEE 802.1AB]
IEEE 802.1AB-2009, IEEE Standard for Local and metropolitan area

networks Station and Media Access Control Connectivity Discovery.
[IEEE 802.1ad]
IEEE 802.1ad-2005, IEEE Standard for Local and metropolitan area

networks Virtual Bridged Local Area Networks, Amendment 4: Provider
Bridges.
[IEEE 802.1ag]
IEEE 802.1ag-2007, IEEE Standard for Local and metropolitan area

networks Amendment 5: Connectivity Fault Management.
[IEEE 802.1D]
IEEE 802.1D-2004, IEEE Standard for Local and metropolitan area

networks Media access control (MAC) Bridges.
[IEEE 802.1Q]
IEEE 802.1Q-2005, IEEE Standard for Local and metropolitan area

networks Virtual Bridged Local Area Networks.
Rec. ITU-T G.988 (10/2012)
[IEEE 802.1X]
IEEE 802.1X-2004, IEEE Standard for Local and metropolitan area

networks Port-Based Network Access Control.
[IEEE 802.3]
IEEE 802.3-2008, IEEE Standard for Information technology

Telecommunications and information exchange between systems Local and
metropolitan area networks Specific requirements Part 3: Carrier sense
multiple access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications.
[IEEE 802.11]
IEEE 802.11-2007, IEEE 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.
[IEEE 1588]
IEEE 1588-2008, IEEE Standard for a Precision Clock Synchronization

Protocol for Networked Measurement and Control Systems.
[IETF RFC 1213]
IETF RFC 1213 (1991), Management Information Base for Network

Management of TCP/IP-based internets: MIB-II.
[IETF RFC 2236]
IETF RFC 2236 (1997), Internet Group Management Protocol, Version 2.
[IETF RFC 2464]
IETF RFC 2464 (1998), Transmission of IPv6 Packets over Ethernet

Networks.
[IETF RFC 2474]
IETF RFC 2474 (1998), Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers.
[IETF RFC 2579]
IETF RFC 2579 (1999), Textual Conventions for SMIv2.
[IETF RFC 2597]
IETF RFC 2597 (1999), Assured Forwarding PHB Group.
[IETF RFC 2617]
IETF RFC 2617 (1999), HTTP Authentication: Basic and Digest Access
Authentication.
[IETF RFC 2684]
IETF RFC 2684 (1999), Multiprotocol Encapsulation over ATM Adaptation

Layer 5.
[IETF RFC 2685]
IETF RFC 2685 (1999), Virtual Private Networks Identifier.
[IETF RFC 2819]
IETF RFC 2819 (2000), Remote Network Monitoring Management

Information Base.
[IETF RFC 2863]
IETF RFC 2863 (2000), The Interfaces Group MIB.
[IETF RFC 3246]
IETF RFC 3246 (2002), An Expedited Forwarding PHB (Per-Hop Behavior).
[IETF RFC 3376]
IETF RFC 3376 (2002), Internet Group Management Protocol, Version 3.
[IETF RFC 3417]
IETF RFC 3417 (2002), Transport Mappings for the Simple Network
Management Protocol (SNMP).
[IETF RFC 3551]
IETF RFC 3551 (2003), RTP Profile for Audio and Video Conferences with
Minimal Control.
[IETF RFC 3810]
IETF RFC 3810 (2004), Multicast Listener Discovery Version 2 (MLDv2) for
IPv6.
[IETF RFC 4133]
IETF RFC 4133 (2005), Entity MIB (Version 3).
[IETF RFC 4446]
IETF RFC 4446 (2006), IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3).
Rec. ITU-T G.988 (10/2012)
[IETF RFC 4733]
IETF RFC 4733 (2006), RTP Payload for DTMF Digits, Telephony Tones,
and Telephony Signals.
[IETF RFC 4734]
IETF RFC 4734 (2006), Definition of Events for Modem, Fax, and Text
Telephony Signals.
[IETF RFC 4789]
IETF RFC 4789 (2006), Simple Network Management Protocol (SNMP) over
IEEE 802 Networks.
[IETF RFC 5519]
IETF RFC 5519 (2009), Multicast Group Membership Discovery MIB.
[IETF RFC 5603]
IETF RFC 5603 (2009), Ethernet Pseudowire (PW) Management

Information Base (MIB).
[IETF RFC 5605]
IETF RFC 5605 (2009), Managed Objects for ATM over Packet Switched
Networks (PSNs).
[ISO/IEC 9798-4]
ISO/IEC 9798-4:1999, Information technology Security techniques Entity

authentication Part 4: Mechanisms using a cryptographic check function.
[MEF 8]
Metro Ethernet Forum MEF 8 (2004), Implementation Agreement for the

Emulation of PDH Circuits over Metro Ethernet Networks.
Definitions
3.1
Terms defined elsewhere
This Recommendation uses the following terms defined elsewhere:

3.1.1
10-gigabit passive optical network (XG-PON): [ITU-T G.987] (Note)
3.1.2
Dynamic bandwidth assignment (DBA): [ITU-T G.987]
3.1.3
Gigabit passive optical network (G-PON): [ITU-T G.987] (Note)
3.1.4
Mean optical launch power: [ITU-T G.987]
3.1.5
ONU management and control interface (OMCI): [ITU-T G.987]
3.1.6
Optical line termination (OLT): [ITU-T G.987]
3.1.7
Optical network unit (ONU): [ITU-T G.987]
3.1.8
Passive optical network (PON) system: [ITU-T G.987]
3.1.9
Physical layer OAM (PLOAM): [ITU-T G.987]
3.1.10 Ranging: [ITU-T G.987]

3.1.11 Transmission container (T-CONT): [ITU-T G.987]
3.1.12
User-network interface (UNI): [ITU-T I.112].
NOTE This Recommendation uses the term G-PON to refer generically to either ITU-T G.984 G-PON or
ITU-T G.987 XG-PON. When a distinction is needed, this Recommendation qualifies the usage with an
explicit reference to the appropriate series.
3.2
Terms defined in this Recommendation
This Recommendation defines the following terms:

3.2.1
downstream: Downstream is the direction of traffic flow from the OLT to ONU.
Rec. ITU-T G.988 (10/2012)
3.2.2 policing: Policing causes a flow of input packets to conform to a given peak information
rate (PIR)/peak burst size (PBS) by immediately dropping packets that exceed PIR/PBS. This
typically results in packet loss; packets may be further marked as drop eligible if they exceed
committed information rate (CIR)/committed burst size (CBS).
3.2.3 shaping: Shaping causes a flow of input packets to conform to a given PIR/PBS by
controlling the release rate/burst size of output packets. This typically results in a queueing delay;
packets may be dropped if there is a queue overflow because the input rate or burst size is too great.
3.2.4
upstream: Upstream is the direction of traffic flow from an ONU to the OLT.
Abbreviations and acronyms
This Recommendation uses the following abbreviations and acronyms:

AAL
Asynchronous transfer mode Adaptation Layer
ACS
Autoconfiguration Server
ADSL
Asymmetric Digital Subscriber Line

NOTE The xDSL MEs include the ITU-T G.992 family as well as [ITU-T G.993.2] VDSL2,
but not [ITU-T G.993.1] VDSL.
AES
Advanced Encryption Standard
AF
Assured Forwarding
AIS
Alarm Indication Signal
AK
Acknowledgement
ANI
Access Node Interface
AR
Acknowledge Request
ARC
Alarm Reporting Control
ARP
Address Resolution Protocol
ASCII
American Standard Code for Information Interchange
ATA
Analogue Telephony Adaptor (VoIP)
ATM
Asynchronous Transfer Mode
ATU-C
Asymmetric digital subscriber line Transceiver Unit, Central office (ONU) end (special
case of xTU-C)
ATU-R
Asymmetric digital subscriber line Transceiver Unit, Remote terminal end (special case
of xTU-R)
AVC
Attribute Value Change
BE
Best Effort
BER
Bit Error Rate
BES
Burst Errored Second
BNG
Broadband Network Gateway
B-PON
Broadband Passive Optical Network
CAS
Channel Associated Signalling
CBS
Committed Burst Size
CCM
Continuity Check Message
Rec. ITU-T G.988 (10/2012)
CES
Circuit Emulation Service
CFI
Canonical Format Indicator
CFM
Configuration Fault Management
CIR
Committed Information Rate
CLEI
Common Language Equipment Identification
CLP
Cell Loss Priority
CoS
Class of Service
CPCS-SDU Common Part Convergence Sublayer Service Data Unit

CPCS-UU Common Part Convergence Sublayer User-to-User indication
CPE
Customer Premises Equipment
CPI
Common Part Indicator
CRC
Cyclic Redundancy Check
CS
Convergence Sublayer
CSS
Controlled Slip Second
CTP
Connection Termination Point
DAD
Duplicate Address Detection, IPv6
DBA
Dynamic Bandwidth Assignment
DBDT
Draw-Break Dial Tone
DEI
Discard Eligibility Indicator (bit)
DHCP
Dynamic Host Configuration Protocol
DMT
Discrete Multi-Tone, xDSL
DNS
Domain Name Server
DSCP
Differentiated Services Code Point
DSL
Digital Subscriber Line
DUID
DHCP Unique Identifier
ECB
Electronic Codebook
ECID
Emulated Circuit ID
EF
Expedited Forwarding
EIR
Excess Information Rate
EMS
Element Management System
ES
Errored Second (-L: -line, -P: -path, -FE: -far-end)
EVC
Ethernet Virtual Connection
EVS
Ethernet Virtual Service
FCS
Frame Check Sequence
FDL
Facility Data Link
FEC
Forward Error Correction
FRU
Field-Replaceable Unit
Rec. ITU-T G.988 (10/2012)
FTTx
Fibre to the x (B building, business; H home; C cabinet, curb)
GAL
GEM
GEM Adaptation Layer

Gigabit-capable passive optical network Encapsulation Method, [ITU-T G.984.x]
NOTE Unless explicitly stated otherwise, this term also refers generically to XGEM
encapsulation in [ITU-T G.987] XG-PON.
G-PON
Gigabit-capable Passive Optical Network, [ITU-T G.984.x]

NOTE Unless explicitly stated otherwise, this term also refers generically to [ITU-T
G.987] XG-PON.
Generic Status Portal
GSP
GTC
Gigabit-capable passive
[ITU-T G.984.x]
optical
network
Transmission
Convergence
layer
NOTE Unless explicitly stated otherwise, this term also refers generically to XGTC in
[ITU-T G.987] XG-PON.
HOL
Head Of Line
IA_NA
Identity Association for Non-temporary Addresses, [b-IETF RFC 3315]
IAT
Inter-Arrival Time, xDSL
ICMP
Internet Control Message Protocol
ID
Identifier
IF
Interface
IGMP
Internet Group Management Protocol

NOTE It may also refer generically to IPv6 MLD.
INM
Impulse Noise Monitoring, xDSL
INP
Impulse Noise Protection
IP
Internet Protocol
IW
Interworking
KEK
Key Encryption Key
L2-OCM
Layer 2 OMCI Common Model
LAN
Local Area Network
LBM
Loopback Message
LBO
Line Build-Out
LBR
Loopback Reply
LCT
Local Craft Terminal
LIM
Line Interface Module
LINIT
Line Initialization failure
LL
Limited Link (MoCA)
LLC
Link Layer Control
LLID
Logical Link ID
LMIG
Layer Management Indication Generation
LMIR
Layer Management Indication Receiving
Rec. ITU-T G.988 (10/2012)
LOL
Loss of Link
LOM
Loss-Of-Margin
LOS
Loss Of Signal
LSB
Least Significant Bit
LTM
Linktrace Message
LTR
Linktrace Reply
MA
Maintenance Association
MAC
Medium Access Control
MD
Maintenance Domain
MDU
Multiple Dwelling Unit
ME
Managed Entity
MEG
Maintenance Entity Group
MEP
Maintenance association End Point
MGC
Media Gateway Controller
MHF
Maintenance domain intermediate point Half Function
MIB
Management Information Base
MIC
Message Integrity Check
MIP
Maintenance domain Intermediate Point
MLD
Multicast Listener Discovery

NOTE It is sometimes included generically by the acronym IGMP
MLT
Mechanized Loop Test

Metallic Line Test
Mechanized Loop Testing
MoCA
Multimedia Over Coax Alliance
MP
Maintenance Point
MPCP
Multi-Point Control Protocol
MPCPDU Multi-Point Control Protocol Data Unit

MSB
Most Significant Bit
MT
Message Type
MTU
Maximum Transmission Unit
NSCds
Number of xDSL Subcarriers, downstream
NSCus
Number of xDSL Subcarriers, upstream
OA
Optical Amplifier
Optical Amplification
OEO
Optical-Electrical-Optical (regeneration)
OID
Object Identifier
OLR
On-Line Reconfiguration
Rec. ITU-T G.988 (10/2012)
OLT
Optical Line Termination
OMCC
Optical network unit Management and Control Channel
OMCI
Optical network unit Management and Control Interface
OMI
Optical Modulation Index
ONT
Optical Network Termination
ONU
Optical Network Unit
OS
Operations System
OTL
Optical Trunk Line (reach extension)
OUI
Organizationally Unique Identifier
PBS
Peak Burst Size
PCP
Priority Code Point
PD
Powered Device
PDU
Protocol Data Unit
PHY
Physical interface
PIR
Peak Information Rate
PLOAM
Physical Layer Operations, Administration and Maintenance
PM
Performance Monitoring
PoE
Power over Ethernet
PON
Passive Optical Network
POTS
Plain Old Telephone Service
PPPoE
Point-to-Point Protocol over Ethernet
PPTP
Physical Path Termination Point
PSD
Power Spectral Density
PSE
Power-Sourcing Equipment
PSK
Pre-shared Secret (Key)
PSN
Packet Switched Network
QLN
Quiet Line Noise
QoS
Quality of Service
R'/S'
Reach extender interface to optical trunk line
RA
Router Advertisement, IPv6
RDI
Remote Defect Indication
RE
Reach Extender
REN
Ringer Equivalent Number
RF
Radio Frequency
RFI
Radio Frequency Interference
RG
Residential Gateway
RO
Read Only
10
Rec. ITU-T G.988 (10/2012)
ROC
Robust Operations Channel
ROH
Receiver Off Hook
RS
Router Solicitation, IPv6
RTCP
Real-time Transport Control Protocol
RTP
Real-Time Protocol
RW
Read, Write
RWSC
Read, Write, Set-by-Create
S'/R'
Reach extender interface to optical distribution network
SAR
Segmentation And Reassembly
SD
Signal Degrade
SDU
Service Data Unit
SES
Severely Errored Second (-L: -line, -P: -path, -FE: -far-end)
SF
Signal Fail
SIP
Session Initiation Protocol
SLAAC
Stateless Address Autoconfiguration, IPv6
SNMP
Simple Network Management Protocol
SNR
Signal-to-Noise Ratio
SPR
Snooping with Proxy Reporting
SRA
Seamless Rate Adaptation
TC
Transmission Convergence
TCA
Threshold Crossing Alert
TCI
Tag Control Information
T-CONT
Transmission Container
TCP
Transmission Control Protocol
TDM
Time Division Multiplex
TLP
Transmission Level Point
TLV
Type-Length-Value syntax
TP
Termination Point
TQ
Time Quantum
TTL
Time To Live
UA
User Agent
UAS
Unavailable Second (-L: -line, -P: -path, -FE: -far-end)
UDP
User Datagram Protocol
UNI
User Network Interface
UPBO
Upstream Power Back-Off
VBES
VLANs for Business Ethernet Services
VC
Virtual Circuit
Rec. ITU-T G.988 (10/2012)
11
VCC
Virtual Circuit Connection
VCI
VDSL
Virtual Circuit Identifier

Very high speed Digital Subscriber Line
NOTE [ITU-T G.993.2] VDSL2 is managed under the xDSL family of MEs
VEIP
Virtual Ethernet Interface Point
VID
Virtual local area network Identifier
VLAN
Virtual Local Area Network
VoIP
Voice Over Internet Protocol
VP
Virtual Path
VPI
Virtual Path Identifier
VPN
Virtual Private Network
VRP
Video Return Path
VTU-O
Very high speed digital subscriber line Transceiver Unit, Operator end
VTU-R
Very high speed digital subscriber line Transceiver Unit, Remote end
WFQ
Weighted Fair Queueing
WRR
Weighted Round Robin
xDSL
Digital Subscriber Line

NOTE This is an inclusive term for any of the DSL Recommendations, excluding [ITU-T
G.993.1].
XGEM
XG-PON Encapsulation Method [ITU-T G.987]

NOTE Sometimes this abbreviation is included generically under the acronym GEM.
XG-PON
10-gigabit passive optical network [ITU-T G.987]
xTU-C
x digital subscriber line Transceiver Unit at the Central office end (in the case of PON,
the ONU)
NOTE This is used as a generic term referring to both the ATU-C of ITU-T G.992.x
Recommendations and the VTU-O of [ITU-T G.993.2]
xTU-R
x digital subscriber line Transceiver Unit at the Remote end (subscriber premises)
NOTE This is used as a generic term referring to both the ATU-R of ITU-T G.992.x
Recommendations and the VTU-R of [ITU-T G.993.2]
Conventions
In bit vectors indicated in this Recommendation, the rightmost bit is bit 1. This 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 bit numbering starts from the least significant byte onwards.
In attribute descriptions that refer to the Boolean values true and false, true is coded as 0x01 in
hexadecimal and false is coded as 0x00. A Boolean attribute is always one byte.
In attribute descriptions that refer to spaces, the ASCII space character (value 0x20) must be used
for the entire size of the attribute.
An ASCII string is a sequence of ASCII encoded characters, terminated by the null character
(0x00). If a string occupies the entire allocated size of an attribute, the terminating null is not
required.
12
Rec. ITU-T G.988 (10/2012)
This Recommendation frequently states that the OLT makes certain decisions or takes certain
actions. While the OMCI commands may emanate from the OLT, there is no implication that the
actual decision or action impetus comes from logic internal to the OLT, rather than from a separate
management system or a human operator.
6
Reference model and terms
6.1
OMCI in the access network
The network architecture reference model for PON is described in [ITU-T G.984.x] and
[ITU-T G.987.x]. An access system according to [ITU-T G.986] has a single ONU on each fibre
subtended from the OLT.
The OMCI fits into the overall model for an access network system as illustrated in Figure 6.1-1.
The dotted line shows a path for OMCI signals between an OLT and ONU.
ONU
OLT
ODN
ONU
S/R PON
interface
Physical link.
OMCC of each ONU
R/S PON
interface
U
G.988(12)_F6.1-1
Figure 6.1-1 Reference model, OMCI

6.2
ONU functions
As shown in Figure 6.2-1, the functions of the ONU are:

a)
access network line termination;
b)
user network interface line termination, noting that in the fibre to the business case, the
UNIs from one ONU may belong to different users;
c)
service multiplexing and de-multiplexing.
ONU
ANI
UNI LT
UNI
UNI LT
UNI
AN LT
Optional second ANI

can be supported for
survivability
Service
multiplex and
demultiplex
G.988(12)_F6.2-1
Figure 6.2-1 ONU functional block diagram

6.3
Support of multicast connection
Multicast traffic can be supported in an optical access network. While a GEM port-ID is assigned to
a single UNI in a unicast connection, a GEM port-ID is shared by multiple UNIs in multiple ONUs
in a multicast connection. The multicast connection set-up process is the same as the unicast
connection set-up process. It is the responsibility of the OLT to manage the members of a multicast
group and control the multicast connection in ONUs.
Rec. ITU-T G.988 (10/2012)
13
In the downstream direction of G-PON, a multicast connection is useful for bandwidth savings. On
the other hand, in the upstream direction, it is impossible to support a multicast connection with a
shared port-ID because the OLT could not reassemble segmented GEM packets correctly if it
received several GEM packets with the same port-ID from different ONUs. Therefore, upstream
traffic associated with a multicast service must be sent to the OLT over a separate unicast
connection.
6.4
Voice over IP management
While the OMCI is always used to manage PON services and ONU equipment, a VoIP service may
optionally be managed by means external to the OMCI. This allows operators more flexibility in
choosing how to manage their overall VoIP service regardless of the access technology involved. A
VoIP service on an ONU may be managed via one of two paths:
1)
OMCI path OMCI has full view and control of all VoIP service attributes.
2)
IP path OMCI is only used to configure attributes that allow non-OMCI based control of
VoIP service attributes.
Specifically, if the OMCI path is used to manage a VoIP service, all of the managed entities defined
here may be read and/or written.
If the IP path is used to manage an SIP VoIP service, only the following SIP-related MEs may be
read and/or written (all other MEs are unaffected):
IP host config data
IP host PM history data
VoIP config data
PPTP POTS UNI
Call control PM history data
RTP PM history data
SIP call initiation PM history data
SIP agent PM history data
SIP config portal
VoIP line status.

If the IP path is used to manage an ITU-T H.248 VoIP service, only the following
ITU-T H.248-related MEs may be read and/or written (all other MEs are unaffected):
IP host config data
IP host PM history data
VoIP config data
PPTP POTS UNI
Call control PM history data
RTP PM history data
MGC PM history data
ITU-T H.248 config portal
VoIP line status.
14
Rec. ITU-T G.988 (10/2012)
Requirements of the management interface specification
The ONU management and control interface defined by this Recommendation is used by the OLT
to manage the ONU in the following areas:
a)
configuration management
b)
fault management
c)
performance management
d)
security management.
This interface allows the OLT to:
a)
establish and release connections across the ONU
b)
manage the UNIs at the ONU
c)
request configuration information and performance statistics.
The OMCI also allows the ONU to inform the OLT autonomously of alarms, performance threshold
crossings and changes to the values of many of the MIB attributes.
The OMCI protocol is asymmetric: the controller in the OLT is the master, while the ONU is the
slave. A single OLT controller using multiple instances of the protocol over separate control
channels typically controls multiple ONUs.
In G-PON, the OMCI protocol runs across a GEM connection between the OLT controller and the
ONU controller. The GEM connection is established at ONU initialization. OMCI transport in
ITU-T G.986 applications is defined in [ITU-T G.986].
7.1
Configuration management
Configuration management provides functions to identify the ONU's capabilities and to exercise
control over the ONU. Areas of configuration management include:
a)
configuration of equipment
b)
configuration of PON and RE protection
c)
configuration of the UNIs
d)
configuration of GEM port network CTPs in G-PON applications
e)
configuration of interworking termination points
f)
configuration of OAM flows
g)
configuration of physical ports
h)
configuration of GAL profiles in G-PON applications
i)
configuration of service profiles
j)
configuration of traffic descriptors
k)
configuration of AAL profiles, when needed for ADSL UNIs.
All G-PON ONUs support GEM transport of user traffic. There is only one connection model for
GEM transport, which is the simple point-to-point transfer of user data via a GEM connection
across the PON, and with downstream multicast capability. GEM interworking always occurs in the
OLT and the ONU, and GEM never extends beyond the PON link.
When the ONU supports an ATM UNI (ADSL), the ATM connection from the subscriber
terminates at the ONU. The OMCI supports the required configuration methods to manage this
function.
Rec. ITU-T G.988 (10/2012)
15
7.2
Fault management
As modelled by the OMCI, the ONU detects and reports equipment, software and interface failures
and declares the corresponding alarms. The OMCI supports failure reporting on many managed
entities as described in clause 9. An alarm table is defined for each of these entities.
To avoid erratic floods of alarm messages, it is common to filter, or soak, defects such as facility
impairments before declaring them as alarms, and to soak defect clearing before retiring the alarm.
The declaration soak time is typically 2.50.5 seconds, while the retirement soak time is typically
10.50.5 seconds. Which alarms are to be soaked, and what the soak intervals should be, are
regarded as vendor-specific choices. Interoperability considerations, however, require that alarms
be soaked exactly once, either at the OLT or at the ONU. This Recommendation specifies that they
be soaked at the ONU.
In addition to failure reporting, the OMCI supports test, measurement and in-service monitoring,
including:
a)
metallic tests of copper drops (voice and/or xDSL)
b)
optical and other parameters of the optical distribution network
c)
[IEEE 802.1ag] connectivity fault management
d)
directed loopback, for example of DS1/E1 services.
The OMCI also provides for the reporting of protection switch events.
7.3
Performance management
The ONU has only limited performance monitoring. The OMCI supports performance monitoring
using a number of managed entities that are described throughout clause 9. These managed entities
can be identified by the words "performance monitoring history data" or "extended PM" in their
names.
All performance monitoring-related managed entities are created at the request of the OLT.
All history data is maintained in the OLT. The ONU maintains only a current counter and one
15-minute previous-interval counter.
Clause I.4 describes performance monitoring in detail.
7.4
Security management
Different access technologies specify differing degrees of security capability [ITU-T G.984.x],
[ITU-T G.986], [ITU-T G.987.x]. The OMCI supports a mechanism to allow mutual authentication
of the OLT and ONU and subsequent secure communication of encryption keys.
8
Protocol-independent MIB for the OMCI
The OMCI is defined such that vendors can offer modular, incremental capabilities to meet
different levels of customer needs. This Recommendation defines a protocol necessary to support
capabilities specified in [ITU-T G.984.x], [ITU-T G.986], [ITU-T G.987.x] and possibly other
access technologies, as well as a variety of services and features. The OMCI supports
interoperability, yet it allows for optional components and future extensions.
A protocol-independent MIB describes the exchange of information across the OMCI. Clause 8 lists
the managed entities and illustrates key relationships between them to implement some of the
important features that may be offered by ONUs. Clause 9 defines each managed entity in detail.
16
Rec. ITU-T G.988 (10/2012)
8.1
Managed entities
The protocol-independent MIB presented in this Recommendation is defined in terms of managed

entities (MEs). Managed entities are abstract representations of resources and services in an ONU.
Only a small subset of the list of MEs is mandatory. The existence of other MEs depends on the
architecture and feature set supported by the vendor.
Table 8-1 lists all the managed entities. The designation M in a column indicates that the specified
managed entity is mandatory for systems complying with the corresponding Recommendation. The
designation M/E in a column indicates that the corresponding ME is mandatory and that its
definition is adapted to [IEEE 802.3] applications in accordance with Annex C. N/A indicates that
the specified ME is not applicable. Other managed entities are present according to the architecture
and the feature set offered by a given ONU.
Table 8-1 Managed entities of the OMCI
Clause
Managed entity
ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
9.13.6
AAL5 performance monitoring

history data
N/A
9.13.5
AAL5 profile
N/A
9.2.1
ANI-G
9.12.10
Attribute
9.12.4
Authentication security method
9.12.16
BBF TR-069 management server
9.9.12
Call control performance

monitoring history data
9.1.5
Cardholder
9.8.4
CES physical interface

performance monitoring history
data
9.8.12

data 2
9.8.13

data 3
9.8.3
CES service profile
9.1.6
Circuit pack
9.3.18
Dot1 rate limiter
9.3.25
Dot1ag CFM stack
9.3.26
Dot1ag chassis-management info
9.3.21
Dot1ag default MD level
9.3.20
Dot1ag maintenance association
9.3.19
Dot1ag maintenance domain
9.3.22
Dot1ag MEP
Rec. ITU-T G.988 (10/2012)
17

Clause
Managed entity
9.3.24
Dot1ag MEP CCM database
9.3.23
Dot1ag MEP status
9.3.15
Dot1X configuration profile
9.3.16
Dot1X performance monitoring

history data
9.3.14
Dot1X port extension package
9.2.14
Energy consumption
data
9.13.11
Enhanced security control
9.1.9
Equipment extension package
9.1.11
Equipment protection profile
9.8.9
Ethernet flow termination point
9.3.32
Ethernet frame extended PM
9.3.31
Ethernet frame performance

downstream
9.3.30
Ethernet frame performance

monitoring history data upstream
9.5.2
Ethernet performance
9.5.3
monitoring history data 2
9.5.4
monitoring history data 3
9.8.18
Ethernet pseudowire parameters
9.3.13
Extended VLAN tagging

operation configuration data
9.2.9
FEC performance monitoring

history data
9.12.13
ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
File transfer controller
9.2.8
GAL Ethernet performance

N/A
9.2.7
GAL Ethernet profile
N/A
9.2.4
GEM interworking termination

point
M/E
9.2.3
GEM port network CTP
M/E
9.2.13
GEM port network CTP performance monitoring history data
18
Rec. ITU-T G.988 (10/2012)
N/A

Clause
Managed entity
9.12.12
General purpose buffer
9.12.14
Generic status portal
9.3.10
IEEE 802.1p mapper service

profile
9.13.4
Interworking VCC termination

point
9.4.1
IP host config data
9.4.2
IP host performance monitoring

history data
9.4.5
IPv6 host config data
9.12.5
Large string
9.8.2
Logical N 64 kbit/s sub-port

connection termination point
9.3.2
MAC bridge configuration data
9.3.3
MAC bridge performance

9.3.8
MAC bridge port bridge table

data
9.3.4
MAC bridge port configuration

data
9.3.5
MAC bridge port designation

data
9.3.7
MAC bridge port filter preassign table
9.3.6
MAC bridge port filter table data
9.3.33
MAC bridge port ICMPv6

process pre-assign table
9.3.9
MAC bridge port performance

9.3.1
MAC bridge service profile
9.12.9
Managed entity
9.9.16
MGC config data
9.9.20
MGC config portal
9.9.17
MGC performance monitoring

history data
9.10.2
MoCA Ethernet performance

9.10.3
MoCA interface performance

ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
Rec. ITU-T G.988 (10/2012)
19

Clause
Managed entity
9.8.14
MPLS pseudowire termination

point
9.2.5
Multicast GEM interworking

termination point
9.3.27
Multicast operations profile
9.3.28
Multicast subscriber config info
9.3.29
Multicast subscriber monitor
9.12.3
Network address
9.9.10
Network dial plan table
9.12.11
Octet string
9.12.2
OLT-G
9.12.8
OMCI
9.1.3
ONU data
9.1.14
ONU dynamic power

management control
9.1.7
ONU power shedding
9.1.12
ONU remote debug
9.1.2
ONU2-G
9.1.13
ONU-E
9.1.1
ONU-G
9.8.1
Physical path termination point

CES UNI
9.5.1

Ethernet UNI
9.13.3

LCT UNI
9.10.1

MoCA UNI
9.9.1

POTS UNI
9.14.2

RE UNI
9.13.2

video ANI
9.13.1

video UNI
9.7.1

xDSL UNI part 1
20
Rec. ITU-T G.988 (10/2012)
ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
M
M
N/A
M

Clause
Managed entity
9.7.2

xDSL UNI part 2
9.5.6
PoE control
9.1.8
Port mapping package
9.2.10
Priority queue
9.1.10
Protection data
9.8.7
Pseudowire maintenance profile
9.8.8
Pseudowire performance
9.8.5
Pseudowire termination point
9.8.15
PW ATM configuration data
9.8.16
PW ATM performance
9.8.17
PW Ethernet configuration data
9.3.17
Radius performance monitoring

history data
9.14.1
RE ANI-G
9.14.6
RE common amplifier
parameters
9.14.5
RE config portal
9.14.4
RE downstream amplifier
9.14.3
RE upstream amplifier
9.9.13
RTP performance monitoring

history data
9.9.7
RTP profile data
9.8.6
RTP pseudowire parameters
9.9.3
SIP agent config data
9.9.14
SIP agent performance

9.9.15
SIP call initiation performance

9.9.19
SIP config portal
9.9.2
SIP user data
9.12.15
ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
SNMP configuration data
9.1.4
Software image
9.7.25
TC adaptor performance
monitoring history data xDSL
Rec. ITU-T G.988 (10/2012)
21

Clause
Managed entity
9.2.2
T-CONT
9.4.3
TCP/UDP config data
9.4.4
TCP/UDP performance
9.12.6
Threshold data 1
9.12.7
Threshold data 2
9.2.12
Traffic descriptor
9.2.11
Traffic scheduler
9.12.1
UNI-G
9.7.6
VDSL2 line configuration

extensions
9.7.26
VDSL2 line configuration

extensions 2
9.7.16
VDSL2 line inventory and status

data part 1
9.7.17

data part 2
9.7.18

data part 3
9.5.5
Virtual Ethernet interface point
9.3.11
VLAN tagging filter data
9.3.12
VLAN tagging operation

configuration data
9.9.6
Voice service profile
9.9.8
VoIP application service profile
9.9.18
VoIP config data
9.9.9
VoIP feature access codes
9.9.11
VoIP line status
9.9.5
VoIP media profile
9.9.4
VoIP voice CTP
9.13.9
VP network CTP
9.13.10
VP performance monitoring
history data
9.7.7
xDSL channel configuration

profile
9.7.19
xDSL channel downstream

status data
22
Rec. ITU-T G.988 (10/2012)
ITU-T G.984,
ITU-T G.987
M
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
M

Clause
Managed entity
9.7.20
xDSL channel upstream status

data
9.7.11
xDSL downstream RFI bands

profile
9.7.27
xDSL impulse noise monitor

data
9.7.3
xDSL line configuration profile

part 1
9.7.4

part 2
9.7.5

part 3
9.7.12
xDSL line inventory and status

data part 1
9.7.13

data part 2
9.7.14

data part 3
9.7.15

data part 4
9.7.28

data part 5
9.7.29

data part 6
9.7.30

data part 7
9.7.10
xDSL PSD mask profile
9.7.8
xDSL subcarrier masking

downstream profile
9.7.9
xDSL subcarrier masking

upstream profile
9.7.23
xDSL xTU-C channel

data
9.7.21
xDSL xTU-C performance

9.7.24
xDSL xTU-R channel

data
9.7.22
xDSL xTU-R performance

ITU-T G.984,
ITU-T G.987
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
Rec. ITU-T G.988 (10/2012)
23

Clause
ITU-T G.984,
ITU-T G.987
Managed entity
9.2.16
XG-PON downstream
management performance
9.2.15
XG-PON TC performance
9.2.17
XG-PON upstream management

data
8.2
ITU-T G.986
IEEE 802.3,
IEEE 802.3av
Managed entity relation diagrams
This clause shows the relationships between managed entities. Unless indicated otherwise, figures
illustrate G-PON access according to [ITU-T G.984.x] and [ITU-T G.987.x]. With suitable
modifications, part or all of the same models may be used by other access technologies.
Although the figures bear some resemblance to signal flows, it is important to recognize that they in
fact illustrate the relationships among the entities of the management model.
Figure 8.2-1 gives the legend of symbols used in these diagrams. The name of the managed entity,
sometimes abbreviated for ease of documentation, appears in each box, with the clause in which it
is defined shown in the lower right corner.
Managed
entity A
Entity created by ONU
9.xx.xx
Managed
entity B
Entity created by OLT
9.xx.xx
xx PM
history data
9.xx.xx
Managed
entity A
Managed
entity B
9.xx.xx
Managed
entity B
9.xx.xx
Entity A has implicit ID relationship to

entity B (ME IDs are equal)
9.xx.xx
1
0..X
9.xx.xx
Managed
entity A
Entity A has explicit pointer to entity B
9.xx.xx
Managed
entity A
Managed
entity A
A performance monitoring (PM) entity,

always created by the OLT, optionally
associated with an instance of threshold
data 1 and 2
1
1
9.xx.xx
Managed
entity B
There can be 0..X instances of A related to B
9.xx.xx
Managed
entity B
There is a 1 to 1 relationship of A to B
9.xx.xx
OR
Only one of the options is active for any

one instance
G.988(12)_F8.2-1
Figure 8.2-1 Legend for managed entity relation diagrams

24
Rec. ITU-T G.988 (10/2012)
8.2.1
G-PON ONU common functions

Software
image
9.1.4
ONU data
1
1
1
9.1.3
Cardholder
2
ONU-G
1..127
9.1.5
Cardholder
9.1.1
0..1
9.1.5
ONU2-G
0..1
9.1.2
Circuit pack
0,2
Port
1 mapping
package
0..1
9.1.6
1..255
1..127
0..1
Equipment
extension
1 package
0..1
1
UNI-G
0..n
OR
9.2.10
9.2.3
Traffic
descriptor
0,2
1..255
1
1
9.2.2
GEM port
network CTP
9.12.1
9.1.6
0..256
T-CONT
0..n
Circuit pack
0..256
0..n
0..n
0..256
0..256
OR
9.2.10
Priority
queue (down)
9.2.11
Priority
queue (up)
0..n
1
Traffic
scheduler
0..n
9.1.9
PPTP
xx
UNI
9.1.8
0..1
0..n
9.2.12
ANI-G
0..1
1
9.2.1
GEM port
network CTP
PM history
data
9.2.13
G.988(12)_F8.2.1-1
User data
ME complex
Figure 8.2.1-1 G-PON ONU core
Rec. ITU-T G.988 (10/2012)
25
Working side
Protecting side
Traffic
scheduler
9.2.11
0..n 0..1
Priority
queue (up)
0..256
OR
0..256
0..n
9.2.10
0..n
T-CONT
9.2.2
Traffic
scheduler
When protection
is activated,
pointers to
T-CONTs and
schedulers are
mapped from
working side to
protecting side
9.2.11
0..256
OR
0..256
T-CONT
9.2.2
0..n
1
OR
0..256
0..256
Circuit pack
Circuit pack
1
9.1.6
1..255
9.1.6
1..255
GEM port
network CTP
9.2.3
Protected
traffic
ANI-G
9.2.1
1
Protection
data
ANI-G
9.1.10
9.2.1
G.988(12)_F8.2.1-2
Figure 8.2.1-2 1+1 PON protection (G-PON)

Working side
Protecting side
Traffic
scheduler
0..n
0..1
9.2.11
0..256
OR
Priority
queue (up)
0..256
0..n
9.2.10
0..n
T-CONT
When protection
is activated,
pointers to
T-CONTs and
schedulers are
mapped from
working side to
protecting side
Traffic
scheduler
0..n
0..1
Priority
queue (up)
9.2.11
1
OR
9.2.10
0..n
0..256
0..256
T-CONT
0..n
9.2.2
9.2.2
0..n
1
OR
OR
0..256
0..256
Circuit pack
9.1.6
1..255
1
ANI-G
Circuit pack
1
9.1.6
GEM port
network CTP
GEM port
network CTP
9.2.3
9.2.3
Protected
traffic
9.2.1
Protection
data
Extra
traffic
9.1.10
1..255
1
ANI-G
9.2.1
G.988(12)_F8.2.1-3
Figure 8.2.1-3 1:1 PON protection (G-PON)
26
Rec. ITU-T G.988 (10/2012)
8.2.2
Layer 2 functions
The OMCI supports two major layer 2 traffic mapping models: MAC bridging and "IEEE 802.1p
mapping". MAC bridging is described in [IEEE 802.1D] and [IEEE 802.1Q]. The bridge illustrated
in Figure 8.2.2-1 has many features, and can be used to direct traffic based on a MAC address (that
is, true bridging) or on VLAN characteristics (using the VLAN filter feature). The mapping
function describes the steering of traffic from one UNI-side entity to 1-8 ANI-side ports, as shown
in Figure 8.2.2-2 below. The mapper is equivalent to a MAC bridge with VLAN filters that only
operate on the priority bits of the VLAN tags.
Extended
VLAN tag
op
VLAN tag
op config
data
9.3.13
9.3.12
Any ME to which
VLAN tagging
can be assigned
9.3.18
MAC bridge
port config
data
0..w 0..m
MAC bridge
service
profile
9.2.3
0..1
0..n
9.2.7
0..1
9.3.4
1
1
UNI-G
9.12.1
9.3.11
MAC bridge
port filter
table
9.3.6
1
1
0..1
9.3.2
VLAN
tagging filter
data
9.3.3
MAC bridge
config data
GAL
Ethernet
profile
MAC
bridge PM
MAC bridge
port config
data
MAC bridge
port bridge
table
MB port filter
pre-assign
table
9.3.8
PPTP
xx UNI
GAL
Ethernet
PM
9.2.8
0..1
0..1
9.2.4
9.3.4
0..p
GEM port
network
CTP
GEM
interworking
TP
9.3.1
9.3.32
1
0..1
Dot1 rate
limiter
0..1
Enet frame
extended
PM
(Flexible
association)
9.3.7
0..1
0..1
MB port
ICMPv6 proc
pre-assign table
1
1
Enet frame
PM, up/dn
9.3.30-31
MB port
designation
data
9.3.33
9.3.5
1
1
MB port
PM
9.3.9
G.988(12)_F8.2.2-1
Figure 8.2.2-1 MAC bridged LAN

NOTE A bridge port may be associated with any IEEE 802.3 UNI, such as Ethernet or xDSL, or another
IEEE 802.3 function such as an IP host config data ME.
Rec. ITU-T G.988 (10/2012)
27
Extended
VLAN tag
op
VLAN tag
op config
data
9.3.13
9.3.12
Any ME to which
VLAN tagging
can be assigned
GEM port
network
CTP
1
1
9.2.3
GEM
interworking
TP
0..1
9.2.8
9.2.4
0..1
1
0..n
8
0..8
GAL
Ethernet
PM
GAL
Ethernet
profile
9.2.7
802.1p
mapper svc
profile
9.3.10
0..1
1
Dot1 rate
limiter
9.3.18
UNI-G
PPTP
xx UNI
9.12.1
G.988(12)_F8.2.2-2
Figure 8.2.2-2 MAC bridged LAN

NOTE A mapper service profile may be associated with any IEEE 802.3 UNI, such as Ethernet or xDSL,
or another IEEE 802.3 function such as an IP host config data ME.
The two basic layer 2 services can be used in various combinations to achieve different overall
connectivities. There are three major functional styles of layer 2 connectivity, illustrated in
figures 8.2.2-3 to 8.2.2-5:
N:1 bridging, where a bridge is used to serve multiple UNI ports from a single ANI service.
1:M mapping, where a mapper is used to serve a single UNI with multiple ANI
connections, based on IEEE 802.1p priorities.
1:P filtering, where a bridge with filters is used to serve a single UNI with multiple ANI
connections, based on some VLAN information other than IEEE 802.1p priorities.
Given these three basic possibilities, there are also four more complex combinations as well,
illustrated in figures 8.2.2-6 to 8.2.2-9. It is strongly encouraged that these applications be utilized
before other, more exotic styles of usage.
28
Rec. ITU-T G.988 (10/2012)
GEM
interworking
TP
1
1
9.2.4
MAC bridge
port config
data
9.3.4
1
1
Dot1 rate
limiter
0..1
9.3.18
9.3.1
MAC bridge
port config
data
1
1
9.3.12-13
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
MAC bridge
service
profile
9.3.4
1
1
(Extended)
VLAN tag
op
9.3.12-13
PPTP
xx
UNI
PPTP
xx
UNI
G.988(12)_F8.2.2-3
Figure 8.2.2-3 Illustration of N:1 bridging

GEM port
network CTP
GEM port
network CTP
GEM
interworking
TP
9.2.4
GEM
interworking
TP
9.2.4
1
M
Dot1 rate
limiter
9.3.18
1
1
0..1
802.1p
mapper service
profile
9.3.10
1
1
(Extended)
VLAN tag
op
9.3.12-13
1
1
PPTP
xx
UNI
G.988(12)_F8.2.2-4
Figure 8.2.2-4 Illustration of 1:M mapping
Rec. ITU-T G.988 (10/2012)
29
GEM port
network CTP
GEM port
network CTP
GEM
interworking
TP
GEM
interworking
TP
9.2.4
9.2.4
MAC bridge
port config
data
9.3.4
VLAN
tagging filter
data
MAC bridge
port config
data
1
9.3.4
VLAN
tagging filter
data
9.3.11
9.3.11
MAC bridge
service
profile
9.3.1
Dot1 rate
limiter
0..1
9.3.18
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
9.3.12-13
1
1
1
PPTP
xx
UNI
Figure 8.2.2-5 Illustration of 1:P filtering
30
Rec. ITU-T G.988 (10/2012)
VLAN
tagging filter
data
9.3.11
G.988(12)_F8.2.2-5
GEM port
network CTP
GEM port
network CTP
GEM
interworking
TP
GEM
interworking
TP
1
M
802.1p
mapper service
profile
9.2.4
1
1
9.2.4
1
1
1
9.3.10
1
1
Dot1 rate
limiter
0..1
9.3.18
MAC bridge
port config
data
9.3.4
MAC bridge
service
profile
9.3.1
N
1
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
1
1
9.3.12-13
PPTP
xx
UNI
MAC bridge
port config
data
9.3.4
1
1
(Extended)
VLAN tag
op
9.3.12-13
PPTP
xx
UNI
G.988(12)_F8.2.2-6
Figure 8.2.2-6 Illustration of N:M bridge-mapping
Rec. ITU-T G.988 (10/2012)
31
GEM port
network CTP
1
GEM
interworking
TP
9.3.10
9.2.4
9.2.4
802.1p
mapper service
profile
1
GEM
interworking
TP
GEM
interworking
TP
9.2.4
GEM port
network CTP
GEM
interworking
TP
9.2.4
GEM port
network CTP
GEM port
network CTP
1
1
MAC bridge
port config
data
1
P
9.3.4
9.3.11
MAC bridge
port config
data
9.3.4
VLAN
tagging filter
data
9.3.1
Dot1 rate
limiter
802.1p
mapper service
profile
9.3.10
MAC bridge
service
profile
VLAN
tagging filter
data
0..1
9.3.11
9.3.18
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
1
1
9.3.12-13
PPTP
xx
UNI
VLAN
tagging filter
data
9.3.11
G.988(12)_F8.2.2-7
Figure 8.2.2-7 Illustration of 1:MP map-filtering
32
Rec. ITU-T G.988 (10/2012)
1
1
GEM port
network CTP
GEM port
network CTP
GEM
interworking
TP
GEM
interworking
TP
9.2.4
9.2.4
VLAN
tagging filter
data
9.3.11
MAC bridge
port config
data
VLAN
tagging filter
data
9.3.11
MAC bridge
port config
data
9.3.4
MAC bridge
service
profile
0..1
1
P
9.3.4
Dot1 rate
limiter
9.3.18
9.3.1
N
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
9.3.12-13
1
1
1
PPTP
xx
UNI
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
9.3.12-13
1
1
1
PPTP
xx
UNI
VLAN
tagging filter
data
9.3.11
G.988(12)_F8.2.2-8
Figure 8.2.2-8 Illustration of N:P bridge-filtering
Rec. ITU-T G.988 (10/2012)
33
GEM port
network CTP
1
GEM
interworking
TP
802.1p
mapper service
profile
1
1
1
1
P
9.3.4
9.3.11
MAC bridge
port config
data
VLAN
tagging filter
data
9.3.1
9.3.11
9.3.4
1
1
9.3.12-13
PPTP
xx
UNI
802.1p
mapper service
profile
9.3.4
MAC bridge
port config
data
9.3.10
MAC bridge
service
profile
VLAN
tagging filter
data
1
1
MAC bridge
port config
data
(Extended)
VLAN tag
op
9.2.4
9.2.4
9.3.10
1
GEM
interworking
TP
GEM
interworking
TP
9.2.4
GEM port
network CTP
GEM
interworking
TP
9.2.4
GEM port
network CTP
GEM port
network CTP
MAC bridge
port config
data
9.3.4
(Extended)
VLAN tag
op
1
1
9.3.12-13
PPTP
xx
UNI
VLAN
tagging filter
data
9.3.11
G.988(12)_F8.2.2-9
Figure 8.2.2-9 Illustration of N:MP bridge-map-filtering
34
Rec. ITU-T G.988 (10/2012)
Figure 8.2.2-10 illustrates the use of the multicast interworking termination point. A bridge is used
to multiplex the multiple ANI-side ports into the single (in this case) UNI-side port. It is essential to
have a unicast path in parallel to the multicast path because the unicast path carries the upstream
signalling that is required for control of multicast transmissions. In most scenarios, a unicast path
already exists for other user communications.
1
Multicast
GEM IW TP
1
Extended
VLAN tag op
(optional)
GEM
interworking
TP
9.2.5
9.2.4
1..n
MAC bridge
port config
data
MAC bridge
port config
data
1
1
9.3.4
9.3.4
MAC bridge
service
profile
9.3.1
(Extended)
VLAN tag
op
1
MC
subscriber
config
9.3.28
9.3.12-13
MAC bridge
port config
data
9.3.4
MC
subscriber
monitor
9.3.29
MC
operations
profile
PPTP
xx
UNI
9.3.27
G.988(12)_F8.2.2-10
Figure 8.2.2-10 Illustration of a multicast service

GEM port
network CTP
1
GEM IW TP
(Note)
9.2.4
1..n
1
1
MAC bridge
port config
data
9.3.4
VLAN
tagging filter
data
9.3.11
MAC bridge
port config
data
9.3.4
MAC bridge
service
profile
9.3.1
VLAN
tagging filter
data
9.3.11
MAC bridge
service
profile
9.3.1
G.988(12)_F8.2.2-11
NOTE Interworking option set to downstream broadcast.
Figure 8.2.2-11 Illustration of the downstream broadcast configuration

Rec. ITU-T G.988 (10/2012)
35
MAC bridge
service
profile
M
1
0..1
9.3.1
MAC bridge
port config
data
Dot1ag
CFM stack
9.3.4
Dot1ag MEP
status
9.3.23
9.3.25
Dot1ag
default MD
level
Dot1ag
chassis mgt
info
9.3.21
Dot1ag
MEP
9.3.26
1
0..p
9.3.22
Dot1ag
MEP CCM
database
Dot1ag
maintenance
assoc
9.3.24
9.3.20
Dot1ag
maintenance
domain
9.3.19
G.988(12)_F8.2.2-12
Figure 8.2.2-12 Illustration of [IEEE 802.1ag] in a MAC bridge model

Dot1ag MEP
status
802.1p
mapper service 0..1
profile
M
1
9.3.23
9.3.10
Dot1ag
CFM stack
Dot1ag
MEP
9.3.22
Dot1ag
MEP CCM
database
9.3.24
9.3.25
Dot1ag
default MD
level
0..p
Dot1ag
chassis mgt
info
9.3.21
Dot1ag
maintenance
assoc
9.3.20
9.3.26
Dot1ag
maintenance
domain
9.3.19
G.988(12)_F8.2.2-13
NOTE If a mapper is associated with the ports of a bridge, the 802.1ag entities should be associated with the bridge and its ports,
rather than with the mapper.
Figure 8.2.2-13 Illustration of [IEEE 802.1ag] in an IEEE 802.1p mapper model
36
Rec. ITU-T G.988 (10/2012)
8.2.3
This clause is intentionally left blank
8.2.4
xDSL service
xDSL
subcarrier
mask dn
From layer 2 ME (802.1p or

MAC bridge port configuration 0..q
data) or VP network CTP
1
0..4
9.7.10
9.7.8
PPTP xDSL
UNI 1
xDSL down
RFI bands
profile
0..r
9.7.1
xDSL line
config 1..3
0..p
xDSL PSD
mask
0..s
9.7.11
xDSL
subcarrier
mask up
9.7.9
9.7.3-5
xDSL channel
config
profile
xDSL line inv

and status 1..7
9.7.7
9.7.12-15, .28-30
PPTP xDSL
UNI 2
VDSL2 line
config ext
1..2
0..n
8
9.7.2
9.7.6, .26
VDSL2 line
inv and status
1..3
1..4
xDSL channel
downstream
status
9.7.19
9.7.16-18
xDSL channel
upstream status
UNI-G
xTU-C PM
history
9.12.1
9.7.21
9.7.20
xTU-C
channel
PM
xTU-R PM
history
9.7.22
9.7.23
xTU-R
channel
PM
Impulse
noise PM
TC adaptor
PM history
xDSL
9.7.27
9.7.25
9.7.24
G.988(12)_F8.2.4-1
Figure 8.2.4-1 xDSL

From layer 2 ME (802.1p
mapper or MAC bridge
port configuration data)
0..n
0..1
0..n
9.13.9
VP PM
history data
9.13.5
Interworking
VCC TP
1
VP network
CTP
AAL5
profile
9.13.4
AAL5 PM
history data
1
0..4
9.13.6
PPTP xDSL UNI part 1

(Note)
9.13.10
G.988(12)_F8.2.4-2
NOTE Individual bearer channels accessible via 2 MSBs of PPTP ME ID
Figure 8.2.4-2 ATM interworking for xDSL
Rec. ITU-T G.988 (10/2012)
37
8.2.5
8.2.6
MoCA service
1
MoCA
interface
PM
0..1
9.10.3
PPTP MoCA
UNI
9.10.1
MoCA
Ethernet
PM
UNI-G
9.10.2
9.12.1
G.988(12)_F8.2.6-1
Figure 8.2.6-1 Multimedia over Coax Alliance

8.2.7
8.2.8
VoIP service
Per-UNI MEs
Global MEs
VoIP config
data
9.9.18
SIP config
portal
9.9.19
9.9.1
VoIP line
status
9.9.11
SIP agent
PM history
9.9.14
PPTP POTS
UNI
SIP call
initiation
PM
9.9.15
RTP PM
history data
9.9.13
UNI-G
9.12.1
Call ctrl
PM history
9.9.12
G.988(12)_F8.2.8-1
NOTE MEs that require long character strings point to large string MEs. MEs that require a network address point to network
address MEs.
Figure 8.2.8-1 IP-path managed SIP VoIP
38
Rec. ITU-T G.988 (10/2012)
Global MEs
VoIP config
data
Per-UNI MEs
PPTP POTS
UNI
MGC PM
history
9.9.18
9.9.1
VoIP line
status
9.9.17
UNI-G
9.9.11
MGC config
portal
9.9.20
9.12.1
Call ctrl
PM history
RTP PM
history data
9.9.13
9.9.12
G.988(12)_F8.2.8-2
address MEs.
Figure 8.2.8-2 IP path managed ITU-T H.248 VoIP

RTP profile
data
9.9.7
RTP PM
history data
9.9.18
VoIP media
profile
1
Voice
service
profile
VoIP config
data
0..m
9.9.13
VoIP line
status
0..m
1
9.9.5
9.9.11
VoIP voice
CTP
9.9.6
0..1
9.9.4
Network dial
plan table
0..m
1
0..m
9.9.10
VoIP feature
access codes
9.9.1
SIP user data
UNI-G
9.9.2
9.9.12
PPTP POTS
UNI
0..1
0..1
Call ctrl
PM history
9.9.9
9.12.1
Authentication
security
method
9.12.4
SIP agent
PM history
data
9.9.14
SIP agent
config data
0..m
0..m
9.9.3
TCP/UDP
config data
9.4.3
1
0..1
VoIP appl
service
profile
9.9.8
SIP call
initiation
PM
9.9.15
G.988(12)_F8.2.8-3
address MEs.
Figure 8.2.8-3 OMCI managed SIP VoIP
Rec. ITU-T G.988 (10/2012)
39
RTP profile
data
9.9.7
9.9.18
VoIP media
profile
1
Voice
service
profile
RTP PM
history data
VoIP config
data
0..m
9.9.13
VoIP line
status
0..m
1
9.9.5
9.9.11
VoIP voice
CTP
9.9.6
0..1
9.9.4
1
1
9.9.1
MGC config
data
9.9.17
UNI-G
9.9.16
MGC PM
history data
9.9.12
PPTP POTS
UNI
0..1
0..1
Call
control PM
0..1
9.12.1
TCP/UDP
config data
9.4.3
G.988(12)_F8.2.8-4
address MEs.
Figure 8.2.8-4 OMCI managed ITU-T H.248 VoIP

Any ME that requires
a network address

0..1
Network
address
1
Large string
9.12.5
9.12.3
IP or IPv6
host config
data
9.4.1, 9.4.5
0..m
Authentication
security
method
9.12.4
Rec. ITU-T G.988 (10/2012)
9.4.2
TCP/UDP
config data
9.4.3
Figure 8.2.8-5 Common IP services
40
IP host PM
history data
G.988(12)_F8.2.8-5
GEM port
network
CTP
0..m
1
9.2.3
PPTP POTS
UNI
0..1
9.9.1
0..1
GEM
interworking
TP
9.2.4
0..1
1
1
0..m
1
MAC bridge
port config
data
0..1
SIP user data
9.3.4
VoIP voice
CTP
9.9.4
1
0..m
9.9.2
MAC bridge
service
profile
SIP agent
config data
9.3.1
9.9.3
0..p
1
MAC bridge
port config
data
TCP/UDP
config data
9.3.4
Ext VLAN
tagging op
9.3.13
1
1
1
0..1
1
0..1
9.4.3
IP or IPv6
host config
data
1
0..m
9.4.1, 9.4.5
G.988(12)_F8.2.8-6
NOTE ITU-T H.248 connectivity is very similar to this SIP example.
Figure 8.2.8-6 VoIP connectivity
Rec. ITU-T G.988 (10/2012)
41
8.2.9
Pseudowire service
CES service
profile
GEM port
network CTP
9.8.3
TCP/UDP
config data
N
1
GEM
IW TP
(Extended)
VLAN tag
op
9.3.12-13
MPLS PW
TP
1
TCP/UDP
config data
9.4.3
9.8.14
1
9.2.4
9.4.3
OR
Over IP
Ethernet
flow TP
0..1
9.8.9
Over MPLS
OR

Over Ethernet
1
Pseudowire
maintenance
profile
1
1
9.8.7
1..n
1
RTP
pseudowire
parms
9.8.6
Pseudowire
PM history
data
Pseudowire
termination
point
9.8.8
9.8.5
Structured
OR
Unstructured
1
1
Logical
N 64 kbit/s
CTP
9.8.2
CES phy
PM 1, 2, 3
1..n
9.8.4, -.12-13
PPTP CES
UNI
9.8.1
UNI-G
9.12.1
G.988(12)_F8.2.9-1
Figure 8.2.9-1 TDM pseudowire
42
Rec. ITU-T G.988 (10/2012)
GEM port
network CTP
TCP/UDP
config data
GEM
IW TP
9.4.3
(Extended)
VLAN tag
op
9.2.4
Over UDP
Over GEM

9.3.12-13
MPLS PW
TP
1
TCP/UDP
config data
9.4.3
9.8.14
Ethernet
flow TP
OR
Over MPLS
Over UDP
OR
0..1
9.8.9
Over Ethernet
1
PW ATM
PM history
data
PW ATM
config data
9.8.16
1..n ITU-T G.983.2

traffic descriptor
9.8.15
[ITU-T G.983.2], 7.5.2
1
1..n
ITU-T G.983.2
UNI B-PON
ITU-T G.983.2
PPTP ATM UNI
[ITU-T G.983.2], 7.3.1
[ITU-T G.983.2], 7.3.5

G.988(12)_F8.2.9-2
Figure 8.2.9-2 ATM pseudowire
Rec. ITU-T G.988 (10/2012)
43
GEM port
network CTP
TCP/UDP
config data
GEM
IW TP
9.4.3
9.2.4
Over UDP
Over GEM
OR

Ethernet
flow TP
0..1
9.8.9
Over MPLS
MPLS PW
TP
9.8.14
(Extended)
VLAN tag
op
9.3.12-13
Ethernet
pseudowire
parms
PW Ethernet
config data
9.8.17
OR
9.8.18
1..n
MAC bridge
port config
data
9.3.4
1..n
UNI-G
PPTP
xx
UNI
9.12.1
G.988(12)_F8.2.9-3
Figure 8.2.9-3 Ethernet pseudowire

8.2.10 Mid-span PON reach extenders
The PON reach extender is modelled as an ONU (the management entity) containing cardholders
and circuit packs whose functions are to extend the reach of one or more PONs. The PON reach
extender's own management ONU is understood to exist as a member of one of the extended PONs.
PPTP
RE UNI
0..255
RE
ANI-G
9.14.2
9.14.1
G.988(12)_F8.2.10-1
NOTE In many cases, the RE ANI-G and PPTP RE UNI are implemented on the same circuit pack. If so, the port mapping package
can be used to create the hybrid line card.
Figure 8.2.10-1 Mid-span PON reach extender core (repeater)

RE common
amplifier
parms
RE common
amplifier
parms
9.14.6
RE upstream
amplifier
9.14.3
9.14.6
0..255 RE downstream
amplifier
9.14.4
G.988(12)_F8.2.10-2
NOTE In many cases, the RE upstream amplifier and RE downstream amplifier are implemented on the same circuit pack. If so,
the port mapping package can be used to create the hybrid line card.
Figure 8.2.10-2 Mid-span PON reach extender core (optical amplifier)
44
Rec. ITU-T G.988 (10/2012)
RE common
amplifier
parms
9.14.6
RE upstream
amplifier
9.14.3
PPTP
RE UNI
0..255
RE
ANI-G
9.14.1
9.14.2
G.988(12)_F8.2.10-3
Figure 8.2.10-3 Mid-span upstream PON reach extender core (hybrid)

RE common
amplifier
parms
9.14.6
RE downstream
amplifier
9.14.4
PPTP
RE UNI
0..255
RE
ANI-G
9.14.1
9.14.2
G.988(12)_F8.2.10-4
Figure 8.2.10-4 Mid-span downstream PON reach extender core (hybrid)

MAC bridge
port config
data
0..1
9.3.4
IP or IPv6
host config
data
9.4.1, 9.4.5
0..m
1
TCP/UDP
config data
To MAC bridge service per

existing in-band management
protocol server
0..1
9.4.3
RE config
portal
9.14.5
G.988(12)_F8.2.10-5
Figure 8.2.10-5 In-band management for the mid-span PON reach extender
8.2.11 Point-to-point gigabit Ethernet fed ONU
PPTP
Ethernet UNI
9.5.1
ONU-E
9.1.13
1
1
ONU data
9.1.3
G.988(12)_F8.2.11-1
Figure 8.2.11-1 P2P GbE-fed ONU
Rec. ITU-T G.988 (10/2012)
45
MIB description
This clause defines all ONU managed entities (MEs) of interest to the Recommendations that
subscribe to it. Recognizing the heritage of the OMCI through [ITU-T G.983.2], code points for a
number of managed entities are permanently reserved for legacy implementations. In a few cases,
managed entities defined in earlier Recommendations have proven to be of little interest. As
reserved code points, such managed entities remain available for use in new applications, if needed,
but their definitions appear only in the original Recommendations.
Managed entity (ME) descriptions include:
a)
The purpose of the entity.
b)
The relationships of the managed entity with other managed entities.
c)
The attributes of the entity, an ordered list that specifies both syntax and semantics.
d)
The management operations (actions) that may be performed on the entity. Generic actions
such as create, delete, get, get next, set and get current data are merely listed in the
description of a given ME; details appear in Annex A. Specialized actions are described in
more detail in the ME description itself.
e)
The notifications generated by the managed entity. These may be attribute value changes
(AVCs), alarms or performance monitoring threshold crossing alerts (TCAs). Tables define
each of these three classes as needed for each ME type.
These clauses are organized as follows:
9.1
Equipment management
9.2
ANI management, traffic management
9.3
Layer 2 data services
9.4
9.5
Ethernet services
9.6
This clause is intentionally left blank.
9.7
xDSL services
9.8
TDM services
9.9
Voice services
9.10
Premises networks
9.11
This clause is intentionally left blank.
9.12
General purpose MEs
9.13
Miscellaneous services
9.14
Mid-span PON reach extender
Attribute access
Some managed entities are instantiated by the ONU autonomously. Others are instantiated on
explicit request of the OLT via a create command, and a few ME types may be instantiated in either
way, depending on the ONU architecture or circumstances.
Attributes of a managed entity that is auto-instantiated by the ONU can be (R), (W), or (R, W).
On the other hand, attributes of a managed entity that is instantiated by the OLT can be either (R),
(W), (R, W), (R, Set-by-create) or (R, W, Set-by-create). Where appropriate, this Recommendation
specifies a default value, to be assigned to the attribute on instantiation of the managed entity.
46
Rec. ITU-T G.988 (10/2012)
The following explains each case in more detail:

(R):
At instantiation or initialization, the ONU sets the attribute to a default

value or to a value that reflects a current state or measurement. During
continued operation, the ONU may update the value of the attribute to
reflect state or measurement changes. The OLT can only read the value of
the attribute. In case of an autonomous attribute value change, the ONU
may send an attribute value change notification (AVC) to the OLT.
(W):
The OLT can only write the value of this attribute type. An attribute of this
type is typically used to trigger an action in the ONU. Such an attribute
never triggers an AVC notification to the OLT.
(R, W):
On instantiation of the managed entity, either autonomously or on request of

the OLT via a create action, the ONU sets the attribute to a default value.
The OLT can both read and write the value of the attribute. In case of an
autonomous attribute value change, the ONU may send an AVC 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 ONU sets the attribute to the value specified in the
create command. Subsequently, the OLT cannot change the value of the
attribute. This combination is used mostly for managed entity IDs, but
occasionally for other attributes that cannot meaningfully change after ME
creation.
(R, W, Set-by-create): On instantiation of the managed entity, by necessity on request of the OLT
via a create action, the ONU sets the attribute to the value specified in the
create command. Subsequently, the OLT can both read and write the value
of the attribute. In case of an autonomous attribute value change, the ONU
may send an AVC notification to the OLT. In a number of cases, it is
logically impossible to change (write) the value of an attribute after the ME
has been created. However, chicken and egg issues can arise when several
such MEs point to each other. Allowing such attributes to be set after
creation is intended to avoid these issues.
Managed entity identifiers
The identifier of a managed entity (ME ID) may be a fixed value, stated in its definition. The ME
ID may be specified as 0 when the ME is instantiated automatically and there is only one. The
ONU-G ME is a good example of this class. In other cases, the definition of an ME specifies a rule
for the assignment of an ME ID, such as a slot-port model.
When an ME is created by the OLT, and its ME ID is unconstrained by the ME definition in
clause 9, it is preferred to avoid ME IDs 0 and 0xFFFF, which create ambiguity in pointers that may
need to refer to the ME.
Likewise, when an ME is created by the ONU, and its ME ID is free for the ONU to choose, the
ONU should avoid ME IDs 0 and 0xFFFF.
Optional pointers
In many cases, populating a pointer attribute may be optional (a prime example being the threshold
data 1/2 ID attribute). When this happens, it is useful to be able to specify a null pointer in the
OMCI. Because the OLT defines the pointers and the MEs to which they point, if the OLT has the
intention to not populate the optional pointer, it can do so by filling in any value that does not
correspond to an ME that exists. The ONU can determine that the pointer points to nothing, and is
therefore null. Both 0 and 0xFFFF are often used by convention to designate a null pointer, but
Rec. ITU-T G.988 (10/2012)
47
especially the value 0 can sometimes be a valid ME ID, so this convention should be used
judiciously.
Interdependent attribute handling
Some attributes within an ME are interdependent. For example, attribute B may be used to
enable/disable the use of attribute A. In these cases, it is recommended that the OLT provision the
dependent attribute (A) first or in the same set message. If the attributes are provisioned in an order
that causes the use of an unprovisioned attribute with no well-defined default, the OLT cannot
necessarily expect an error indication from the ONU and the correct operation of the ONU cannot
be guaranteed. In most cases, default values are defined in clause 9 to minimize the risk of this
event.
Notifications
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. The alarm
reporting message contains a field of 224 bits, which is mapped to as many as 208 specific alarms
by the definition of each managed entity. The last 16 bits are reserved for vendor-specific alarms
and are not to be standardized. Alarm bits are numbered from 0 upwards. The general schema is
illustrated in the following table, where each managed entity definition may specify some of the 208
reserved points for its own alarms. Different ME types can reuse the same code points because the
alarm report message includes the ME type (and instance).
Generic alarm bit assignment
Alarm number
Alarm
0..207
Reserved
208..223
Vendor-specific alarms
Description
Not to be standardized
AVCs are reported via attribute value change messages. A managed entity cannot encompass more
than 16 attributes, in addition to its ME ID, and the attribute value change message contains a bit
map of 16 bits that match the attributes in order, starting with 1. If a managed entity can generate
AVCs, its definition includes an AVC table that matches attributes with their corresponding bit
numbers for easy reference. Attributes that do not trigger AVC notifications are shown as N/A,
while bit positions for non-existent attributes are shown as reserved.
Test results are reported:
a)
via an expected test result message if the test is invoked by a test command from the OLT,
or
b)
via an autonomous test result message if a test failure is detected autonomously by the
ONU, or
c)
via an alarm message in the case of autonomous self-test failure in the start-up phase.
Details of these messages and their coding appear in Annex A.
IPv6 address representation
The OMCI management information model was developed in the context of IPv4, which uses 4
byte addresses. IPv6 requires 16 bytes to fully represent an address. It is undesirable to define
completely new MEs for IPv6, and both versions are likely to coexist for some time.
It is observed that 0.0.x.y is not a valid IPv4 address, although 0.0.0.0 may appear occasionally, for
example in IGMP messages.
48
Rec. ITU-T G.988 (10/2012)
This Recommendation specifies that, for any 4-byte attribute defined as an IP address, mask or
gateway, if the value is 0.0.x.y, where x and y are not both 0, then x.y is to be interpreted as a
pointer to a large string managed entity that represents an IPv6 address. The syntax of the
representation is described in [b-IETF RFC 4291]. When explicitly allowed for an individual
attribute, the large string may also contain a URI.
Usually, large strings are created and deleted by the OLT. For IPv6 address representation, the
ONU may also need to create and delete a large string. To avoid numbering conflicts, it is
recommended that the OLT number large strings from 1 upwards, while the ONU number
auto-created large strings from 65534 downwards.
MEs whose IP addresses are treated in accordance with this section include:
Dot 1X configuration profile.
Multicast operations profile, querier IP address attribute. In this attribute, 0.0.0.0 is legal in
IPv4.
SIP agent config data, SIP DNS address attributes.
SNMP configuration data.

The mechanism described in this section is suitable for individual IPv6 address attributes, but it
does not scale well for managed entities that contain tables of IP addresses. Each of these MEs has
its own definition of IPv6 treatment. In the future, any new MEs are to be defined with inbuilt IPv6
support.
9.1
An ONU may be physically implemented as a single module (integrated ONU) or as a shelf

containing plug-in field-replaceable units (FRUs). An ONU containing FRUs always instantiates a
cardholder ME for each of its physical slots; a cardholder can then be populated with a circuit pack.
It is recommended that physical slots be numbered from left to right, then from bottom to top.
Because the cardholder ID (slot number) is used in the ME ID of many MEs, an integrated ONU
may also be conveniently modelled with virtual cardholders and virtual circuit packs. When an
ONU is modelled with virtual cardholders and circuit packs, it makes sense that all ports of a given
virtual circuit pack have the same type, for example, 802.3 Ethernet.
However, a physical circuit pack may have several port types, for example a PON ANI, a video
UNI and a craft port. The port mapping package provides a flexible way to associate port numbers
with a heterogeneous assortment of ports.
In the same way, the port mapping package supports an integrated ONU that is modelled without
virtual cardholders. In such an ONU, ME IDs are assigned with the understanding that all MEs exist
in cardholder 0.
9.1.1
ONU-G
This managed entity represents the ONU as equipment. The ONU automatically creates an instance
of this managed entity. It assigns values to read-only attributes according to data within the ONU
itself.
This managed entity has evolved from the ONT-G of [ITU-T G.984.4].
Relationships
In ITU-T G.984 and ITU-T G.987 applications, all other managed entities in this
Recommendation are related directly or indirectly to the ONU-G entity.
Rec. ITU-T G.988 (10/2012)
49
Attributes
Managed entity ID: This attribute uniquely identifies each instance of this managed entity.
There is only one instance, number 0. (R) (mandatory) (2 bytes)
Vendor ID:
This attribute identifies the vendor of the ONU. It is the same as the four
most significant bytes of the ONU serial number as specified in [ITU-T
G.984.3] and [ITU-T G.987.3]. (R) (mandatory) (4 bytes)
Version:
This attribute identifies the version of the ONU as defined by the vendor. The
character value 0 indicates that version information is not available or
applicable. (R) (mandatory) (14 bytes)
Serial number: The serial number is unique for each ONU. It is defined in [ITU-T G.984.3]
and [ITU-T G.987.3] and contains the vendor ID and version number. The
first four bytes are an ASCII-encoded four-letter vendor ID. The second four
bytes are a binary encoded serial number, under the control of the ONU
vendor. (R) (mandatory) (8 bytes)
Traffic management option: This attribute identifies the upstream traffic management
function implemented in the ONU. There are three options:
0 Priority controlled and flexibly scheduled upstream traffic. The traffic
scheduler and priority queue mechanism are used for upstream traffic.
1 Rate controlled upstream traffic. The maximum upstream traffic of
each individual connection is guaranteed by shaping.
2 Priority and rate controlled. The traffic scheduler and priority queue
mechanism are used for upstream traffic. The maximum upstream
traffic of each individual connection is guaranteed by shaping.
For a further explanation, see Appendix II.
Downstream priority queues are managed via the GEM port network CTP
ME.
Upon ME instantiation, the ONU sets this attribute to the value that describes
its implementation. The OLT must adapt its model to conform to the ONU's
selection. (R) (mandatory) (1 byte)
Deprecated: This attribute is not used. If it is present, it should be set to 0. (R) (optional)
(1 byte)
Battery backup: This Boolean attribute controls whether the ONU performs backup battery
monitoring (assuming it is capable of doing so). False disables battery alarm
monitoring; true enables battery alarm monitoring. (R, W) (mandatory)
(1 byte)
Administrative state: This attribute locks (1) and unlocks (0) the functions performed by
the ONU as an entirety. Administrative state is further described in clause
A.1.6. (R, W) (mandatory) (1 byte)
Operational state: This attribute reports whether the managed entity is currently capable of
performing its function. Valid values are enabled (0) and disabled (1). (R)
(optional) (1 byte)
ONU survival time: This attribute indicates the minimum guaranteed time in milliseconds
between the loss of external power and the silence of the ONU. This does not
include survival time attributable to a backup battery. The value zero implies
that the actual time is not known. (R) (optional) (1 byte)
Logical ONU ID: This attribute provides a way for the ONU to identify itself. It is a text
string, null terminated if it is shorter than 24 bytes, with a null default value.
50
Rec. ITU-T G.988 (10/2012)
The mechanism for creation or modification of this information is beyond the

scope of this Recommendation, but might include for example a web page
displayed to a user. (R) (optional) (24 bytes)
Logical password: This attribute provides a way for the ONU to submit authentication
credentials. It is a text string, null terminated if it is shorter than 12 bytes,
with a null default value. The mechanism for creation or modification of this
information is beyond the scope of this Recommendation. (R) (optional)
(12 bytes)
Credentials status: This attribute permits the OLT to signal to the ONU whether its
credentials are valid or not. The behaviour of the ONU is not specified, but
might for example include displaying an error screen to the user. (R, W)
(optional) (1 byte)
Values include:
0 Initial state, status indeterminate
1 Successful authentication
2 LOID error
3 Password error
4 Duplicate LOID
Other values are reserved.
Extended TC-layer options: This attribute is meaningful in ITU-T G.984 systems only. It
is a bit map that defines whether the ONU supports (1) or does not support
(0) various optional TC-layer capabilities of [ITU-T G.984.3]. Bits are
assigned as follows:
Bit
Meaning
1 (LSB) ITU-T G.984.3 Annex C, PON-ID maintenance.
2
ITU-T G.984.3 Annex D, PLOAM channel enhancements:
swift_POPUP and Ranging_adjustment messages.
3..16
Reserved
(R) (optional) (2 bytes)
Actions
Get, set
Reboot:
Reboot the ONU.
Test:
Test the ONU. The test action can be used either to perform equipment
diagnostics or to measure parameters such as received optical power, video
output level, battery voltage, etc. Test and test result messages are defined in
Annex A.
Synchronize time: This action synchronizes the start time of all performance monitoring
managed entities of the ONU with the reference time of the OLT. All
counters of all performance monitoring managed entities are cleared to 0 and
restarted. Also, the value of the interval end time attribute of the performance
monitoring managed entities is set to 0 and restarted. See clause I.4 for
further discussion of PM.
NOTE This function is intended only to establish rough 15-minute boundaries for
PM collection. High precision time of day synchronization is a separate function,
supported by the OLT-G managed entity.
Rec. ITU-T G.988 (10/2012)
51
Notifications
Test results are reported via a test result message if the test is invoked by a
test command from the OLT.
Test result:
Attribute value change

Numbe
r
1..7
Attribute value
change
Description
N/A
Op state
N/A
10
LOID
Logical ONU ID
11
Lpw
Logical password
12..16
Operational state change
Reserved
Alarm
Alarm
number
52
Alarm
Description
Equipment alarm
Functional failure on an internal interface
Powering alarm
Loss of external power to battery backup unit. This alarm is

typically derived through an external interface to a battery
backup unit, and indicates that AC is no longer available to
maintain battery charge.
Battery missing
Battery is provisioned but missing
Battery failure
Battery is provisioned and present but cannot recharge
Battery low
Battery is provisioned and present but its voltage is too low
Physical intrusion
Applies if the ONU supports detection such as door or box

open
ONU self-test failure
ONU has failed autonomous self-test
Dying gasp
ONU is powering off imminently due to loss of power to the

ONU itself. This alarm may be sent in conjunction with the
powering alarm if the backup unit cannot supply power and the
ONU is shutting down.
Temperature yellow
No service shutdown at present, but the circuit pack is

operating beyond its recommended range.
Temperature red
Some services have been shut down to avoid equipment

damage. The operational state of the affected PPTPs indicates
the affected services.
10
Voltage yellow
No service shutdown at present, but the line power voltage is

below its recommended minimum. Service restrictions may be
in effect, such as permitting no more than N lines off-hook or
ringing at one time.
11
Voltage red
Some services have been shut down to avoid power collapse.

The operational state of the affected PPTPs indicates the
affected services.
12
ONU manual power

off
The ONU is shutting down because the subscriber has turned

off its power switch.
Rec. ITU-T G.988 (10/2012)
Alarm
Alarm
number
Alarm
Description
13
Inv-Image
Software image is invalid (Note)
14
PSE overload yellow
Indicates that the ONU is nearing its maximum ability to

supply the known PoE demand of the attached PDs. The
thresholds for declaring and clearing this alarm are vendorspecific.
15
PSE overload red
Indicates that the ONU is unable to supply all of the PoE

demand of the attached PDs and has removed or reduced
power to at least one PD.
16..207
Reserved
208..223
Vendor-specific
alarms
NOTE The ONU should declare this alarm only outside the software download process.
9.1.2
ONU2-G
This managed entity contains additional attributes associated with a PON ONU. The ONU
automatically creates an instance of this managed entity. Its attributes are populated according to
data within the ONU itself.
This managed entity is the same as the ONT2-G of [ITU-T G.984.4], with extensions.
Relationships
This managed entity is paired with the ONU-G entity.
Attributes
Equipment ID: This attribute may be used to identify the specific type of ONU. In some
environments, this attribute may include the equipment CLEI code. (R)
(optional) (20 bytes)
OMCC version: This attribute identifies the version of the OMCC protocol being used by
the ONU. This allows the OLT to manage a network with ONUs that support
different OMCC versions. Release levels of [ITU-T G.984.4] are supported
with code points of the form 0x8y and 0x9y, where y is a hexadecimal digit
in the range 0..F. Support for continuing revisions of this Recommendation is
defined in the 0xAy range.
0x80
ITU-T G.984.4 (06/04)
NOTE For historical reasons, this code point may also appear in
ONUs that support later versions of [ITU-T G.984.4].
0x81
0x82
0x83
0x84
0x85
0x86
0x96
ITU-T G.984.4 2004 Amd.1 (06/05)

ITU-T G.984.4 2004 Amd.2 (03/06)
ITU-T G.984.4 2004 Amd.3 (12/06)
ITU-T G.984.4 2008 (02/08)
ITU-T G.984.4 2008 Amd.1 (06/09)
ITU-T G.984.4 2008 Amd.2 (2009). Baseline message set
only, without the extended message set option
ITU-T G.984.4 2008 Amd.2 (2009). Extended message set
option, in addition to the baseline message set.
Rec. ITU-T G.988 (10/2012)
53
0xA0
0xA1
0xA2
0xA3
0xB0
0xB1
0xB2
0xB3
ITU-T G.988 (2010). Baseline message set only, without the

extended message set option
ITU-T G.988 Amd.1 (2011). Baseline message set only
ITU-T G.988 Amd.2 (2012). Baseline message set only
ITU-T G.988 (2012). Baseline message set only
ITU-T G.988 (2010). Baseline and extended message set
ITU-T G.988 Amd.1 (2011). Baseline and extended message
set
ITU-T G.988 Amd.2 (2012). Baseline and extended message
set
ITU-T G.988 (2012). Baseline and extended message set
(R) (mandatory) (1 byte)

Vendor product code: This attribute contains a vendor-specific product code for the ONU.
Security capability: This attribute advertises the security capabilities of the ONU. The
following code points are defined:
0
Reserved
1
AES-128 payload encryption supported
2..255 Reserved
Security mode: This attribute specifies the current security mode of the ONU. All secure
GEM ports in an ONU must use the same security mode at any given time.
The following code points are defined:
0
Reserved
1
AES-128 algorithm
2..255 Reserved
Upon ME instantiation, the ONU sets this attribute to 1, AES-128. Attribute
value 1 does not imply that any channels are encrypted; that process is
negotiated at the PLOAM layer. It only signifies that AES with 128-bit keys
is the security mode to be used on any channels that the OLT may choose to
encrypt. (R, W) (mandatory) (1 byte)
Total priority queue number: This attribute reports the total number of upstream priority
queues that are not associated with a circuit pack, but with the ONU in its
entirety. Upon ME instantiation, the ONU sets this attribute to the value that
represents its capabilities. (R) (mandatory) (2 bytes)
Total traffic scheduler number: This attribute reports the total number of traffic schedulers
that are not associated with a circuit pack, but with the ONU in its entirety.
The ONU supports null function, strict priority scheduling and WRR from
the priority control and guarantee of minimum rate control points of view,
respectively. If the ONU has no global traffic schedulers, this attribute is 0.
Deprecated: This attribute should always be set to 1 by the ONU and ignored by the OLT.
Total GEM port-ID number: This attribute reports the total number of GEM port-IDs
supported by the ONU. The maximum value is specified in the corresponding
transmission convergence (TC) Recommendations, [ITU-T G.984.3] or
[ITU-T G.987.3]. Upon ME instantiation, the ONU sets this attribute to the
value that represents its capabilities. (R) (optional) (2 bytes)
54
Rec. ITU-T G.988 (10/2012)
SysUpTime: This attribute counts 10 ms intervals since the ONU was last initialized. It
rolls over to 0 when full (see [IETF RFC 1213]). (R) (optional) (4 bytes)
Connectivity capability: This attribute indicates the Ethernet connectivity models that the
ONU can support. The value 0 indicates that the capability is not supported; 1
signifies support. The following code points are defined:
Bit
Model
1 (LSB)
N:1 bridging, Figure 8.2.2-3
1:M mapping, Figure 8.2.2-4
1:P filtering, Figure 8.2.2-5
N:M bridge-mapping, Figure 8.2.2-6
1:MP map-filtering, Figure 8.2.2-7
N:P bridge-filtering, Figure 8.2.2-8
N:MP bridge-map-filtering, Figure 8.2.2-9
816
Reserved
NOTE 1 It is not implied that an ONU may not support other connectivity models.

Current connectivity mode: This attribute specifies the Ethernet connectivity model that
the OLT wishes to use. The following code points are defined:
Value
Connectivity model
No selection (default)
N:1 bridging
1:M mapping
1:P filtering
N:M bridge-mapping
1:MP map-filtering
N:P bridge-filtering
N:MP bridge-map-filtering
8255
Reserved
NOTE 2 It is not implied that an ONU supports a given connectivity model only
when that model is explicitly selected by this attribute. The ONU is free to support
additional models at any and all times.
(R, W) (optional) (1 byte)

QoS configuration flexibility: This attribute reports whether various managed entities in
the ONU are fixed by the ONU's architecture or whether they are
configurable. For backward compatibility, and if the ONU does not support
this attribute, all such attributes are understood to be hard-wired. (R)
Rec. ITU-T G.988 (10/2012)
55
Bit
Interpretation when bit value = 1
1 (LSB)
Priority queue ME: Port field of related port attribute is read-write and
can point to any T-CONT or UNI port in the same slot
Priority queue ME: The traffic scheduler pointer is permitted to refer to

any other traffic scheduler in the same slot
Traffic scheduler ME: T-CONT pointer is read-write
Traffic scheduler ME: Policy attribute is read-write
T-CONT ME: Policy attribute is read-write
Priority queue ME: Priority field of related port attribute is read-write
7..16
Reserved
Discussion:
To allow for the possibility that the OLT does not support flexible
configuration, the ONU vendor must assure that the priority queues and
traffic schedulers are configured in a meaningful and useful way by factory
default, and that this default configuration is restored upon ONU
initialization and MIB reset. The specifics of such a configuration are beyond
the scope of this Recommendation.
The managed entity ID of both the T-CONT and traffic scheduler contains a
slot number. Even when attributes in the above list are read-write, it is never
permitted to change the slot number in a reference. That is, configuration
flexibility never extends across slots. It is also not permitted to change the
directionality of an upstream queue to downstream, or vice versa.
Priority queue scale factor: If this optional attribute is implemented, it specifies the scale
factor of several attributes of the priority queue managed entity of
clause 9.2.10. The default value of this attribute is 1. (R, W) (optional)
(2 bytes)
NOTE 3 Some legacy implementations may take the queue scale factor from the
GEM block length attribute of the ANI-G managed entity. That option is
discouraged in new implementations.
Actions
Get, set
Notifications
Number
9.1.3
N/A
OMCC version
3..11
N/A
12..16
Reserved
Description
OMCC version supported in the ONU
ONU data
This managed entity models the MIB itself. Clause I.1.3 explains the use of this managed entity
with respect to MIB synchronization.
The ONU automatically creates an instance of this managed entity, and updates the associated
attributes according to data within the ONU itself.
56
Rec. ITU-T G.988 (10/2012)
Relationships
One instance of this managed entity is contained in an ONU.
Attributes
MIB data sync: This attribute is used to check the alignment of the MIB of the ONU with
the corresponding MIB in the OLT. MIB data sync relies on this attribute,
which is a sequence number that can be checked by the OLT to see if the
MIB snapshots for the OLT and ONU match. Refer to clause I.1.2.1 for a
detailed description of this attribute. Upon ME instantiation, the ONU sets
this attribute to 0. (R, W) (mandatory) (1 byte)
Actions
Get, set
Get all alarms: Latch a snapshot 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 (entities)
within the current snapshot.
MIB reset:
Reset the MIB data sync attribute to 0 and reset the MIB of the ONU to its
default. The default MIB comprises those MEs that are designated mandatory
in the corresponding Recommendation, along with other auto-created MEs
whose existence is implicit in the architecture or physical configuration of the
ONU.
For G-PON applications, the minimum default MIB comprises one instance
of the ONU-G managed entity pair, one instance of the ONU data managed
entity, and two instances of the software image managed entity.
MIB upload: Latch a snapshot (i.e., copy) of the current MIB. Not every managed entity or
every attribute is included in a MIB upload. Table attributes are excluded.
Only the control block attributes of performance monitoring MEs are
uploaded. Other MEs and attributes, such as the PPTP for the local craft
terminal, are excluded as documented in their specific definitions.
MIB upload next: Get the latched attribute values of the next managed entity (entities)
within the current snapshot.
Notifications
None.
9.1.4
Software image
This managed entity models an executable software image stored in the ONU (documented here as
its fundamental usage). It may also be used to represent an opaque vendor-specific file
(vendor-specific usage).
Fundamental usage
The ONU automatically creates two instances of this managed entity upon the creation of each
managed entity that contains independently-manageable software, either the ONU itself or an
individual circuit pack. It populates ME attributes according to data within the ONU or the circuit
pack.
Rec. ITU-T G.988 (10/2012)
57
Some pluggable equipment may not contain software. Others may contain software that is
intrinsically bound to the ONU's own software image. No software image ME need exist for such
equipment, though it may be convenient for the ONU to create them to support software version
audit from the OLT. In this case, the dependent MEs would support only the get action.
A slot may contain various equipment over its lifetime, and if software image MEs exist, the ONU
must automatically create and delete them as the equipped configuration changes. The identity of
the software image is tied to the cardholder.
When an ONU controller packs are duplicated, each can be expected to contain two software image
MEs, managed through reference to the individual controller packs themselves. When this occurs,
the ONU should not have a global pair of software images MEs (instance 0), since an action
(download, activate, commit) directed to instance 0 would be ambiguous.
Relationships
Two instances of the software image managed entity are associated with each instance of the
ONU or cardholder whose software is independently managed.
Attributes
The first byte indicates the physical location of the equipment hosting the
software image, either the ONU (0) or a cardholder (1..254). The second byte
distinguishes between the two software image ME instances (0..1). (R)
(mandatory) (2 bytes)
Version:
This string attribute identifies the version of the software. (R) (mandatory)
(14 bytes)
Is committed: This attribute indicates whether the associated software image is committed
(1) or uncommitted (0). By definition, the committed software image is
loaded and executed upon reboot of the ONU and/or circuit pack. During
normal operation, one software image is always 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
could be uncommitted at the same time if both were invalid. Upon ME
instantiation, instance 0 is initialized to committed, while instance 1 is
initialized to uncommitted (that is, the ONU ships from the factory with
image 0 committed). (R) (mandatory) (1 byte)
58
Is active:
This attribute indicates whether the associated software image is active (1) or
inactive (0). By definition, the active software image is one that is currently
loaded and executing in the ONU or circuit pack. Under normal operation,
one software image is always 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 could be inactive at the same
time if both were invalid. (R) (mandatory) (1 byte)
Is valid:
This attribute indicates whether the associated software image is valid (1) or
invalid (0). 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, it should include at least a data integrity (e.g.,
CRC) check of the entire code image. Upon ME instantiation or software
download completion, the ONU validates the associated code image and sets
this attribute according to the result. (R) (mandatory) (1 byte)
Rec. ITU-T G.988 (10/2012)
Product code: This attribute provides a way for a vendor to indicate product code
information on a file. It is a character string, padded with trailing nulls if it is
shorter than 25 bytes. (R) (optional) (25 bytes)
Image hash: This attribute is an MD5 hash of the software image. It is computed at
completion of the end download action. (R) (optional) (16 bytes)
Actions
Get
Software upgrade is described in clause I.3. All of the following actions are mandatory for ONUs
with remotely manageable software.
Start download: Initiate a software download sequence. This action is valid only for a
software image instance that is neither active nor committed.
Download section: Download a section of a software image. This action is valid only for a
software image instance that is currently being downloaded (image 1 in
state S2, image 0 in state S2').
End download: Signal the completion of a download image sequence, providing both CRC
and version information for final verification. This action is valid only for a
software image instance that is currently being downloaded (image 1 in
state S2, image 0 in state S2').
Activate image: Load/execute a 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 (that is, the
associated entity reboots on the previously inactive image). When this action
is applied to a software image that is already active, a soft restart is
performed. The software image is not reloaded from non-volatile memory;
the current volatile code image is simply restarted. This action is only valid
for a valid software image.
Commit image: Set the is committed attribute value to 1 for the target software image ME
and set the is committed attribute value to 0 for the other software image.
This causes the committed software image to be loaded and executed by the
boot code upon subsequent start-ups. This action is only applicable when the
target software image is valid.
Notifications
Number
Version
Is committed
Is active
Is valid
Product code
Image hash
7..16
Description
If an autonomous change to this attribute is associated

with an ONU re-boot, the ONU should send the AVC
(one for each primary software image instance) after the
re-boot.
Reserved
Rec. ITU-T G.988 (10/2012)
59
NOTE Older implementations of the OMCI may not support these notifications, which have been
introduced in this version of this Recommendation.
Vendor-specific usage
In this application, the software image ME is flexible, in keeping with the needs of particular
vendors and applications. The distinction between fundamental and vendor-specific usage is that the
ME ID must not be a value that could be used in the fundamental usage application. That is, the
second byte of the ME ID must be neither 0x00 nor 0x01.
The ONU automatically instantiates as many instances as it is prepared to support.
In its vendor-specific usage, the attributes of the software image ME are optional.
The actions are optional.
Files may or may not exist in versioned pairs (previous revision, next revision).
Relationships
A vendor-specific instance of the software image managed entity represents an externally
visible file on the ONU. The content and use of the file are not specified.
Attributes
The first byte indicates the physical location of the equipment hosting the
software image, either the ONU (0) or a cardholder (1..254). The second byte
distinguishes between software image ME instances, and in vendor-specific
usage is required to have neither the value 0x00 nor the value 0x01. To
facilitate discovery by the OLT, it is suggested that the first byte of the ME
ID be 0, and that the second byte be numbered consecutively from 2. (R)
Version:
If this attribute is supported, its meaning is the same as that of the

fundamental usage application. (R) (optional) (14 bytes)
Is committed: This attribute indicates whether the associated file is committed (1) or
uncommitted (0). Vendor-specific instances may or may not exist in pairs,
and may or may not support the concept of a commit. (R) (optional) (1 byte)
Is active:
This attribute indicates whether the associated file is active (1) or inactive
(0). Vendor-specific instances may or may not support the concept of an
active state. (R) (optional) (1 byte)
Is valid:
This attribute indicates whether the associated file is valid (1) or invalid (0).
Vendor-specific instances may or may not include a way to determine their
validity. (R) (optional) (1 byte)
Product code: This attribute provides a way for a vendor to indicate product code
information on a file. It is a character string, padded with trailing nulls if it is
shorter than 25 bytes. (R) (optional) (25 bytes)
Image hash: This attribute is an MD5 hash of the software image. It is computed at
completion of the end download action. (R) (optional) (16 bytes)
Actions
Get
The following actions are available for vendor-specific use, but optional. If the ONU does not
support a given action, it should respond with a command not supported result and reason code.
60
Rec. ITU-T G.988 (10/2012)
Start download: Initiate a software download sequence.

Download section: Download a section of a file.
End download: Signal the completion of a file download, providing CRC and version
information for final verification, if supported. This action causes the file to
be stored in the ONU's non-volatile memory.
NOTE There is no explicit way to delete a file. It is suggested that the ONU
recognize downloading a file of size zero as a delete operation, that is, a start
download command specifying zero image size, followed by an immediate end
download, with a zero CRC and also specifying zero image size.
Activate image: Effectuate the file, for example by loading its contents into ONU hardware.
If appropriate, the hardware or application may be reinitialized.
Commit image: Set the is committed attribute value to 1 for the target file ME, if supported.
The semantics of this operation are vendor-specific; there is no de-commit
action.
Notifications
Number
Version
Is committed
Is active
Is valid
Product code
Image hash
7..16
Description
If an autonomous change to this attribute is associated

with an ONU re-boot, the ONU should send the AVC
(one for each primary software image instance) after the
re-boot.
Reserved
NOTE Older implementations of the OMCI may not support these notifications, which have been
9.1.5
Cardholder
The cardholder represents the fixed equipment slot configuration of the ONU. Each cardholder can
contain 0 or 1 circuit packs; the circuit pack models equipment information that can change over the
lifetime of the ONU, e.g., through replacement.
One instance of this managed entity exists for each physical slot in an ONU that has pluggable
circuit packs. One or more instances of this managed entity may also exist in an integrated ONU, to
represent virtual slots. Instances of this managed entity are created automatically by the ONU, and
the status attributes are populated according to data within the ONU itself.
Slot 0 is intended to be used only in an integrated ONU. If an integrated ONU is modelled with a
universal slot 0, it is recommended that it does not contain additional (non-zero) virtual slots. A
cardholder for virtual slot 0 is recommended.
There is potential for conflict in the semantics of the expected plug-in unit type, the expected port
count and the expected equipment ID, both when the slot is not populated and when a new circuit
pack is inserted. The expected plug-in unit type and the plug-in type mismatch alarm are
mandatory, although plug-and-play/unknown (circuit pack type 255) may be used as a way to
Rec. ITU-T G.988 (10/2012)
61
minimize their significance. It is recommended that an ONU deny the provisioning of inconsistent
combinations of expected equipment attributes.
When a circuit pack is plugged into a cardholder, or when a cardholder is pre-provisioned to expect
a circuit pack of a given type, it may trigger the ONU to instantiate a number of managed entities
and update the values of others, depending on the circuit pack type. The ONU may also delete a
variety of other managed entities when a circuit pack is reprovisioned to not expect a circuit pack or
to expect a circuit pack of a different type. These actions are described in the definitions of the
various managed entities.
Expected equipment ID and expected port count are alternate ways to trigger the same
pre-provisioning effects. These tools may be useful if an ONU is prepared to accept more than one
circuit pack of a given type but with different port counts, or if a circuit pack is a hybrid that
matches none of the types in Table 9.1.5-1, but whose identification (e.g., part number) is known.
Relationships
An ONU may contain zero or more instances of the cardholder, each of which may contain
an instance of the circuit pack managed entity. The slot ID, real or virtual, is a fundamental
identification mechanism for managed entities that bear some relationship to a physical
location.
Attributes
The ONU sets the first byte of this two-byte identifier to:
0 if the ONU contains pluggable equipment modules
1 if the ONU is a single piece of integrated equipment.
The second byte of this identifier is the slot number. In integrated ONUs, this
byte may be used as a virtual slot or set to 0 to indicate a universal
pseudo-slot.
Slot numbering schemes differ among vendors. It is only required that slot
numbers be unique across the ONU. Up to 254 equipment slots are supported
in the range 1..254 (Note 1). The value 0 is reserved for possible use in an
integrated ONU to indicate a universal pseudo-slot. The value 255 is also
reserved. (R) (mandatory) (2 bytes)
NOTE 1 Some xDSL managed entities use the two most significant bits of the slot
number for other purposes. An ONU that supports these services may have slot
limitations or restrictions.
Actual plug-in unit type: This attribute is equal to the type of the circuit pack in the
cardholder, or 0 if the cardholder is empty. When the cardholder is populated,
this attribute is the same as the type attribute of the corresponding circuit
pack managed entity. Circuit pack types are defined in Table 9.1.5-1. (R)
(mandatory) (1 byte)
The three following attributes permit the OLT to specify its intentions for any future equipped
configuration of a slot. Once some or all of these are set, the ONU can proceed to instantiate circuit
pack and PPTP MEs, along with other predeterminable MEs, and allow the OLT to create related
discretionary MEs, thereby supporting service pre-provisioning.
Expected plug-in unit type: This attribute provisions the type of circuit pack for the slot.
For type coding, see Table 9.1.5-1. The value 0 means that the cardholder is
not provisioned to contain a circuit pack. The value 255 means that the
cardholder is configured for plug-and-play. Upon ME instantiation, the ONU
62
Rec. ITU-T G.988 (10/2012)
sets this attribute to 0. For integrated interfaces, this attribute may be used to
represent the type of interface. (R, W) (mandatory) (1 byte)
Expected port count: This attribute permits the OLT to specify the number of ports it
expects in a circuit pack. Prior to provisioning by the OLT, the ONU
initializes this attribute to 0. (R, W) (optional) (1 byte)
Expected equipment ID: This attribute provisions the specific type of expected circuit
pack. This attribute applies only to ONUs that do not have integrated
interfaces. In some environments, this may contain the expected equipment
CLEI code. Upon ME instantiation, the ONU sets this attribute to all spaces.
(R, W) (optional) (20 bytes)
Actual equipment ID: This attribute identifies the specific type of circuit pack, once it is
installed. This attribute applies only to ONUs that do not have integrated
interfaces. In some environments, this may include the equipment CLEI
code. When the slot is empty or the equipment ID is not known, this attribute
should be set to all spaces. (R) (optional) (20 bytes)
Protection profile pointer: This attribute specifies an equipment protection profile that may
be associated with the cardholder. Its value is the least significant byte of the
managed entity ID of the equipment protection profile with which it is
associated, or 0 if equipment protection is not used. (R) (optional) (1 byte)
Invoke protection switch: The OLT may use this attribute to control equipment protection
switching. Code points have the following meaning when set by the OLT:
0
Release protection switch
1
Operate protection switch, protect cardholder unspecified
2
Operate protection switch, use first protect cardholder
3
Operate protection switch, use second protect cardholder
The ONU should deny attempts to switch to an unequipped, defective or
already active protection cardholder.
Upon the get action from the OLT, this attribute should return the current
value of the actual protection configuration. Code points are as defined
above; the value 1 is never returned.
When circuit packs that support a PON IF function are switched, the response
should be returned on the same PON that received the command. However,
the OLT should also be prepared to accept a response on the redundant PON.
ARC:
See clause A.1.4.3. (R, W) (optional) (1 byte)
ARC interval: See clause A.1.4.3. (R, W) (optional) (1 byte)

Actions
Get, set
Notifications
Number
1
2..4
5

Actual type
Description
Actual type of circuit pack in cardholder
N/A
Actual equipment id
Actual equipment ID of circuit pack in cardholder
Rec. ITU-T G.988 (10/2012)
63
6..7
N/A
ARC
N/A
10..16
ARC timer expiration
Reserved
Alarm (Note 2)
Alarm
number
Alarm
Description
Plug-in circuit pack

missing
Configured circuit pack is not present. If this alarm is

active, none of the mismatch alarms are declared.
Plug-in type mismatch

alarm
Inserted circuit pack is wrong type
Improper card removal
Circuit pack has been removed without being deprovisioned or administratively locked. This is a redundant
alarm that helps the OLT distinguish between transitions
from state S2 to state S1 (Figure 9.1.5-1) and transitions
from state S4 to state S1. This alarm is sent only when a
transition occurs from state S2 to state S1.
Plug-in equipment ID
mismatch alarm
Inserted circuit pack has the wrong equipment ID
Protection switch
An autonomous equipment protection switch has occurred.

This notification is reported by the protected cardholder.
5..207
208..223
Reserved
Vendor-specific
NOTE 2 If no circuit pack is configured or if the cardholder is configured for plug-and-play with no
expected equipment ID, no alarms are raised. No cardholder alarms are defined for ONUs with integrated
interfaces.
Figure 9.1.5-1 is a state diagram that describes insertion and removal of a particular circuit pack
into/from a cardholder that is provisioned to a specific type or to plug-and-play.
NOTE 3 The state diagram is not applicable for ONUs with integrated interfaces.
64
Rec. ITU-T G.988 (10/2012)
state S3
Cardholder
actual type: Y
expected type: no circuit pack
set expected type = no circuit

pack
auto-delete: circuit pack, UNI,
PPTP, PQs
Alarm: plugInTypeMismatch off
state S4
state S3'
Cardholder
actual type: X
Cardholder
actual type: Y
expected type: X
set expected type = X

auto-create: circuit pack,
UNI, PPTP, PQs
Alarm: plugInTypeMismatch on
remove circuit pack Y
AVC: actual type = no
circuit pack
insert circuit pack Y

AVC: actual type = Y
state S0
Cardholder
actual type: no circuit pack

auto-create: circuit
pack, UNI, PPTP,
PQs

plugInMissing on
AVC: actual type = no circuit pack
set expected type = no circuit

pack
auto-delete: circuit pack,UNI,
PPTP, PQs
Alarm: <all> off

<others> off
state S1
Cardholder
expected type: X

auto-create: circuit pack
UNI, PPTP, PQs
Alarm: plugInMissing on
set expected type =
plug-and-play
Cardholder
expected type: plug-and-play
remove circuit pack X

state S2
Alarm: improperRemoval on
AVC: actual type = no circuit
Cardholder
pack
actual type: X
expected type: X
insert circuit pack X
Alarm: improperRemoval off
AVC: actual type = X
NOTE The secondary MEs shown as auto-created
or auto-deleted are appropriate for circuit packs
that provide subscriber interface (UNI)
functions. Other types of circuit packs have
different secondary MEs, or no secondary MEs
according to the definition of the MEs and the
function of the circuit pack.
set expected type =

no circuit pack
state S5
set expected type = no

circuit pack
auto-delete: circuit pack,
UNI, PPTP, PQs
delete circuit pack X

delete: circuit pack
auto-delete: UNI, PPTP, PQs
state S6
Cardholder
create circuit pack X

create: circuit pack
auto-create: UNI,
PPTP, PQs

AVC: actual type = no
circuit pack

state S7
Cardholder
actual type: X
delete circuit pack X
delete: circuit pack
auto-delete: UNI, PPTP, PQs


state S8
state S9
Cardholder
actual type: X
Cardholder
actual type: Y
create circuit pack X
create: circuit pack
auto-create: UNI, PPTP, PQs
G.988(12)_F9.1.5-1
Figure 9.1.5-1 Cardholder state diagram

Some of the following circuit pack types are obsolete in current applications. Their code points and
definitions are reserved for backward compatibility, but in the interest of brevity, they are not listed.
Rec. ITU-T G.988 (10/2012)
65
Table 9.1.5-1 Plug-in unit types

Coding
0
Content
No LIM
Default value
See [ITU-T G.983.2]
Various ATM based UNIs
13
C1.5 (DS1)
1.544 Mbit/s local (T-interface) module
14
C2.0 (E1)
15
C6.3 (J2)
16
C-DS1/E1
Configurable DS1/E1 module
17
C-DS1/E1/J1
Configurable DS1/E1/J1 module
See [ITU-T G.984.4]
Various CES services
22
10BASE-T
10BASE-T Ethernet LAN IF
23
100BASE-T
100BASE-T Ethernet LAN IF
24
10/100 BASE-T
10/100 BASE-T Ethernet LAN IF (Note)
See [ITU-T G.983.2]
Various non-Ethernet LAN technologies
C1.5 (J1)
See [ITU-T G.984.4]
Various ATM interfaces
32
POTS
Plain old telephony service
33
ISDN-BRI
ISDN basic rate interface (deprecated)
34
Gigabit optical Ethernet
Gigabit Ethernet optical IF (Note)
35
xDSL
xDSL IF
36
SHDSL
SHDSL IF
37
VDSL
VDSL IF [ITU-T G.993.1]
38
Video service
Video module
39
LCT
Local craft terminal interface
40
802.11
Wireless interface [IEEE 802.11]
41
xDSL/POTS
Combination xDSL and POTS interfaces
42
VDSL/POTS
Combination VDSL [ITU-T G.993.1] and POTS interfaces
43
Common equipment
Circuit packs such as removable power supply modules or ONU

controllers
44
Combined video UNI and

PON interface
Circuit pack that combines both functions
45
Mixed services equipment
Circuit pack with several types of ANI and/or UNI. Suggested

for use with the port mapping package managed entity.
46
MoCA
MoCA
47
10/100/1000 BASE-T
10/100/1000 BASE-T Ethernet LAN IF (Note)
48
VEIP
49
10G Ethernet
10G Ethernet LAN I/F
1..12
18..21
25..27
28
29..31
50..191
Reserved
192..223
Vendor-specific
224..236
Reserved
237
66
Description
XG-PON10G2488
Rec. ITU-T G.988 (10/2012)
Reserved for vendor use, not to be standardized

XG-PON interface, 10G downstream and 2.488G upstream
Table 9.1.5-1 Plug-in unit types

Coding
Content
Description
238
XG-PON10G10
XG-PON interface, 10G downstream and 10G upstream
239
Mid-span PON reach

extender UNI
The UNI of a mid-span PON reach extender
240
Mid-span PON reach

extender ANI
The ANI of a mid-span PON reach extender
241
Mid-span PON reach

extender upstream optical
amplifier
Upstream optical amplifier 1270 or 1310 nm
242
Mid-span PON 2488/1244

reach extender
downstream optical
amplifier
2488/1244 1490 nm downstream optical amplifier with no

corresponding RE ANI-G
See [ITU-T G.984.4]
G-PON interfaces of diverse rates
GPON24881244
GPON interface, 2488 Mbit/s downstream and 1244 Mbit/s

upstream
249..254
See [ITU-T G.983.2] and

[ITU-T G.984.4]
G-PON and B-PON interfaces of diverse rates
255
Plug-and-play/Unknown
Plug-and-play (for the cardholder managed entity only).

Unrecognized module (for the circuit pack managed entity
only)
243..247
248
NOTE Code points 24 and 34 were used by some implementations to represent the 10/100/1000
BASE-T interface because code point 47 was not defined at the time. While code point 47 should be
adopted for this interface at the earliest opportunity, interoperability may require the flexible recognition
of these other code points.
9.1.6
Circuit pack
This managed entity models a real or virtual circuit pack that is equipped in a real or virtual ONU
slot. For ONUs with integrated interfaces, this managed entity may be used to distinguish available
types of interfaces (the port mapping package is another way).
For ONUs with integrated interfaces, the ONU automatically creates an instance of this managed
entity for each instance of the virtual cardholder managed entity. The ONU also creates an instance
of this managed entity when the OLT provisions the cardholder to expect a circuit pack, that is,
when the OLT sets the expected plug-in unit type or equipment ID of the cardholder to a circuit
pack type, as defined in Table 9.1.5-1. The ONU also creates an instance of this managed entity
when a circuit pack is installed in a cardholder whose expected plug-in unit type is
255 = plug-and-play, and whose equipment ID is not provisioned. Finally, when the cardholder is
provisioned for plug-and-play, an instance of this managed entity can be created at the request of
the OLT.
The ONU deletes an instance of this managed entity when the OLT de-provisions the circuit pack
(i.e., when the OLT sets the expected plug-in unit type or equipment ID of the cardholder to 0 = no
LIM). The ONU also deletes an instance of this managed entity on request of the OLT if the
expected plug-in unit type attribute of the corresponding cardholder is equal to 255, plug-and-play,
and the expected equipment ID is blank (a string of all spaces). ONUs with integrated interfaces do
not delete circuit pack instances.
NOTE Creation and deletion by the OLT is retained for backward compatibility.
Rec. ITU-T G.988 (10/2012)
67
Relationships
An instance of this managed entity is contained by an instance of the cardholder managed
entity.
Attributes
Its value is the same as that of the cardholder managed entity containing this
circuit pack instance. (R, Set-by-create if applicable) (mandatory) (2 bytes)
Type:
This attribute identifies the circuit pack type. This attribute is a code as
defined in Table 9.1.5-1. The value 255 means unknown or undefined, i.e.,
the inserted circuit pack is not recognized by the ONU or is not mapped to an
entry in Table 9.1.5-1. In the latter case, the equipment ID attribute may
contain inventory information. Upon autonomous ME instantiation, the ONU
sets this attribute to 0 or to the type of the circuit pack that is physically
present. (R, Set-by-create if applicable) (mandatory) (1 byte)
Number of ports: This attribute is the number of access ports on the circuit pack. If the port
mapping package is supported for this circuit pack, this attribute should be
set to the total number of ports of all types. (R) (optional) (1 byte)
Serial number: The serial number is expected to be unique for each circuit pack, at least
within the scope of the given vendor. Note that the serial number may contain
the vendor ID and/or version number. For integrated ONUs, this value is
identical to the value of the serial number attribute of the ONU-G managed
entity. Upon creation in the absence of a physical circuit pack, this attribute
comprises all spaces. (R) (mandatory) (8 bytes)
Version:
This attribute is a string that identifies the version of the circuit pack as
defined by the vendor. The value 0 indicates that version information is not
available or applicable. For integrated ONUs, this value is identical to the
value of the version attribute of the ONU-G managed entity. Upon creation in
the absence of a physical circuit pack, this attribute comprises all spaces. (R)
Vendor ID:
This attribute identifies the vendor of the circuit pack. For ONUs with
integrated interfaces, this value is identical to the value of the vendor ID
attribute of the ONU-G managed entity. Upon creation in the absence of a
physical circuit pack, this attribute comprises all spaces. (R) (optional)
(4 bytes)
this managed entity. Administrative state is further described in clause A.1.6.
(R, W) (mandatory) (1 byte)
Operational state: This attribute indicates whether or not the circuit pack is capable of
performing its function. Valid values are enabled (0), disabled (1) and
unknown (2). Pending completion of initialization and self-test on an
installed circuit pack, the ONU sets this attribute to 2. (R) (optional) (1 byte)
Bridged or IP ind: This attribute specifies whether an Ethernet interface is bridged or
derived from an IP router function.
0 Bridged
1 IP router
2 Both bridged and IP router functions
68
Rec. ITU-T G.988 (10/2012)
(R, W) (optional, only applicable for circuit packs with Ethernet interfaces)
(1 byte)
Equipment ID: This attribute may be used to identify the vendor's specific type of circuit
pack. In some environments, this attribute may include the CLEI code. Upon
ME instantiation, the ONU sets this attribute to all spaces or to the equipment
ID of the circuit pack that is physically present. (R) (optional) (20 bytes)
Card configuration: This attribute selects the appropriate configuration of configurable
circuit packs. Table 9.1.5-1 specifies two configurable card types: 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
C-DS1/E1
DS1
E1
DS1
E1
J1
C-DS1/E1/J1
Upon autonomous instantiation, this attribute is set to 0. (R, W, Set-by-create

if applicable) (mandatory for configurable circuit packs) (1 byte)
Total T-CONT buffer number: This attribute reports the total number of T-CONT buffers
associated with the circuit pack. Upon ME instantiation, the ONU sets this
attribute to 0 or to the value supported by the physical circuit pack. (R)
(mandatory for circuit packs that provide a traffic scheduler function)
(1 byte)
Total priority queue number: This value reports the total number of priority queues
associated with the circuit pack. Upon ME instantiation, the ONU sets the
attribute to 0 or to the value supported by the physical circuit pack. (R)
(mandatory for circuit packs that provide a traffic scheduler function)
(1 byte)
Total traffic scheduler number: This value reports the total number of traffic schedulers
associated with the circuit pack. The ONU supports null function, strict
priority scheduling and WRR (weighted round robin) from the priority
control and guarantee of minimum rate control points of view, respectively.
If the circuit pack has no traffic scheduler, this attribute should be absent or
have the value 0. Upon ME instantiation, the ONU sets the attribute to 0 or to
the value supported by the physical circuit pack. (R) (mandatory for circuit
packs that provide a traffic scheduler function) (1 byte)
Power shed override: This attribute allows ports to be excluded from the power shed
control defined in clause 9.1.7. It is a bit mask that takes port 1 as the MSB; a
bit value of 1 marks the corresponding port to override the power shed timer.
For hardware that cannot shed power per port, this attribute is a slot override
rather than a port override, with any non-zero port value causing the entire
circuit pack to override power shedding. (R, W) (optional) (4 bytes)
Actions
Get, set
Create, delete: Optional, only when plug-and-play is supported.
Rec. ITU-T G.988 (10/2012)
69
Reboot:
Reboot the circuit pack.
Test:
Test the circuit pack (optional). The test action may be used either to perform
equipment diagnostics or to measure parameters such as received optical
power, video output level, battery voltage, etc. Test and test result messages
are defined in Annex A.
Notifications
Number
1..6
7
Description
N/A
Op state
8..14
N/A
15..16
Reserved
Alarm
Alarm
number
Description
Equipment alarm
A failure on an internal interface or failed self-test
Powering alarm
Fuse failure or failure of DC/DC converter
Self-test failure
Failure of circuit pack autonomous self-test
Laser end of life
Failure of transmit laser imminent
Temperature yellow
No service shutdown at present, but the circuit pack is

operating beyond its recommended range.
Temperature red
Service has been shut down to avoid equipment damage.

The operational state of the affected PPTPs indicates the
affected services.
6..207
208..223
9.1.7
Alarm
Reserved
ONU power shedding
This managed entity models the ONU's ability to shed services when the ONU goes into battery
operation mode after AC power failure. Shedding classes are defined below, which may span
multiple circuit pack types. This feature works in conjunction with the power shed override attribute
of the circuit pack managed entity, which can selectively prevent power shedding of priority ports.
An ONU that supports power shedding automatically creates an instance of this managed entity.
The following table defines the binding of shedding class and PPTP type. The coding is taken from
Table 9.1.5-1. In the case of hybrid circuit pack types, multiple shedding classes may affect a circuit
pack if the hardware is capable of partial power shedding.
An ONU may choose to model its ports with the port mapping package of clause 9.1.8, rather than
with real or virtual circuit packs. In this case, power shedding pertains to individual PPTPs, as listed
in the second column of the table.
70
Rec. ITU-T G.988 (10/2012)
Shedding class
PPTP type
Coding
Content
ATM
ATM PPTP
1..12
CES
CES PPTP
13
C1.5 (DS1)
14
C2.0 (E1)
15
C6.3 (J2)
16
C-DS1/E1
17
C-DS1/E1/J1
22
10BASE-T
23
100BASE-T
24
10/100 BASE-T
Data
Ethernet PPTP
Various ATM UNIs
Frame
Unspecified
25..27
CES
CES PPTP
28
Sdh-sonet
Sdh-sonet
29..31
Voice
POTS PPTP
32
POTS
ISDN PPTP
33
ISDN BRI (deprecated)
Data
Ethernet PPTP
34
Gigabit optical Ethernet
DSL
xDSL PPTP
35
xDSL
SHDSL
36
SHDSL
VDSL PPTP
37
ITU-T G.993.1 VDSL
N/A
Video UNI
38
RF video service
N/A
LCT PPTP
39
Local craft terminal
Data
IEEE 802.11
PPTP
40
Wireless
Voice (DSL may also apply) xDSL + POTS
41
xDSL/POTS
VDSL + POTS
42
ITU-T G.993.1 VDSL/POTS
Unspecified
43
Common equipment
Unspecified
44
Combined video, PON
Unspecified
45
Mixed services (Power shedding

based on port type)
Data
MOCA PPTP
46
MoCA
Data
Ethernet PPTP
47
10/100/1000 BASE-T
49
10G Ethernet
N/A
N/A
PON PPTP
Video overlay
Video ANI PPTP
Video return
Video RPD
Non-Ethernet LANs
C1.5 (J1)
ATM sdh-sonet interfaces
237..238 XG-PON ANIs
Relationships
One instance of this managed entity is associated with the ONU managed entity.
Attributes
Rec. ITU-T G.988 (10/2012)
71
Restore power timer reset interval: The time delay, in seconds, before resetting the
power-shedding timers after full power restoration. Upon ME instantiation,
the ONU sets this attribute to 0. (R, W) (mandatory) (2 bytes)
For each class of service, an interval attribute is defined below. The value 0 disables power
shedding, while the value 1 enables immediate power shedding, that is, as soon as AC power fails.
Other values specify the time, in seconds, to keep the service active after AC failure before shutting
them down and shedding power. Upon ME instantiation, the ONU sets each of the interval
attributes to 0.
Data class shedding interval:
(R, W) (mandatory) (2 bytes)
Voice class shedding interval: This attribute only pertains to voice services that terminate
on the ONU and are under the management control of the OMCI.
Video overlay class shedding interval: (R, W) (mandatory) (2 bytes)
Video return class shedding interval:
DSL class shedding interval:
ATM class shedding interval:
CES class shedding interval:
Frame class shedding interval:
Sdh-sonet class shedding interval:
Shedding status: Binary indication of power shedding status for each shedding class. If this
two-byte field is depicted 0b ABCD EFGH IJKL MNOP, its bits are
assigned:
A
Data class
B
Voice class
C
Video overlay class
D
Video return class
E
DSL class
F
ATM class
G
CES class
H
Frame class
I
Sdh-sonet class
J..P Reserved and set to 0
The ONU sets each bit to 1 when power shedding is active, and clears it to 0
when the service is restored. (R) (optional) (2 bytes)
Actions
Get, set
Notifications
Number
1..10
11
12..16
72
Description
N/A
Shedding status
Reserved
Rec. ITU-T G.988 (10/2012)
State change of a shedding function
9.1.8
NOTE In [ITU-T G.984.4], this managed entity is called a port mapping package-G.
This managed entity provides a way to map a heterogeneous set of physical path termination points
(ports) to a parent equipment, which may be a cardholder or the ONU itself. It could be useful, for
example, if a single plug-in circuit pack contained a PON ANI as port 1, a video UNI as port 2, and
a craft UNI as port 3. Another application of the port mapping package is the case where more than
one UNI or ANI ME is associated with a single physical port, for example, the reach extender ANI
and downstream amplifier. This ME also provides an option for an integrated ONU to represent its
ports without the use of virtual cardholders and virtual circuit packs.
If the port mapping package is supported for the ONU as a whole, it is automatically created by the
ONU. If the port mapping package is supported for plug-in circuit packs, it is created and destroyed
by the ONU when the corresponding circuit pack is installed or pre-provisioned in a cardholder.
The port list attributes specify ports 1..64 sequentially. Each port list is a sequence of ME types, as
defined in Table 11.2.4-1. These ME type codes define what kind of PPTP or ANI corresponds to
the specific port number. For example, for a circuit pack with 4 POTS ports, 2 xDSL ports, and 1
video UNI port, numbered sequentially in that order, the attributes would be coded:
Max ports:
Port list 1
53, 53, 53, 53, 98, 98, 82, 0
Port list 2..8 All zero

Relationships
A port mapping package may be contained by an ONU-G or a cardholder.
Attributes
Through an identical ID, this managed entity is implicitly linked to an
instance of the ONU-G or cardholder. (R) (mandatory) (2 bytes)
Max ports:
This attribute indicates the largest port number contained in the port list
attributes. Ports are numbered from 1 to this maximum, possibly with
embedded 0 entries, but no port may exist beyond the maximum. (R)
Each of the following attributes is a list of 8 ports, in increasing port number sequence. Each list
entry is a two-byte field containing the managed entity type of the UNI or ANI corresponding to the
port number. Managed entity types are defined in Table 11.2.4-1. Placeholders for non-existent port
numbers are indicated with the value 0.
Port list 1:
(R) (mandatory) (16 bytes)
Port list 2:
Port list 3:
Port list 4:
Port list 5:
Port list 6:
Port list 7:
Port list 8:
Rec. ITU-T G.988 (10/2012)
73
Combined port table: This attribute permits the implicit linking of multiple port-level MEs
to a single physical port. For example, a single physical port may be linked to
both an RE ANI-G and an RE downstream amplifier, as illustrated in
Figure 8.2.10-4. The combination of RE ANI-G and RE downstream
amplifier cannot be directly represented in the port list attributes.
Each row of the combined port table comprises the following fields:
Field name
Size,
bytes
Description
Physical port
Duplicates are allowed.

The corresponding physical port in the port list
attribute should be 0.
Equipment type 1
ME type 1, from Table 11.2.4-1. The first

equipment type in the list is understood to be the
master (in the first row of the table, in case of
duplicate physical ports). The administrative
state, operational state and ARC attributes of the
master override the corresponding attributes of
secondary MEs.
secondary MEs that share the physical port
Equipment type 12
Secondary ME type 12
As many as twelve ME types can be associated with a given physical port,

and even more by duplicating the physical port field. (R) (optional) (N rows
* 25 bytes)
Actions
Get, get next
Notifications
None.
9.1.9
This managed entity supports optional extensions to circuit pack managed entities. If the circuit
pack supports these features, the ONU creates and deletes this managed entity along with its
associated real or virtual circuit pack.
Relationships
An equipment extension package may be contained by an ONU-G or cardholder.
Attributes
instance of the ONU-G or cardholder. (R) (mandatory) (2 bytes)
Environmental sense: This attribute provisions an ONU that supports external sense points,
for example, physical security detectors at an enclosure. Each pair of bits is
defined as follows:
00 Sense point disabled (default)
01 Report contact closure
10 Report contact open
11 Sense point disabled (same as 00)
74
Rec. ITU-T G.988 (10/2012)
If the byte is represented in binary as 0B hhgg ffee ddcc bbaa, bits hh

correspond to sense point 1, while bits aa correspond to sense point 8. (R, W)
NOTE Some specific sense point applications are already defined on the ONU-G
managed entity. It is the vendor's choice how to configure and report sense points
that appear both generically and specifically.
Contact closure output: This attribute provisions an ONU that supports external contact
closure outputs, for example, sump pump or air conditioner activation at an
ONU enclosure. A contact point is said to be released when it is not
energized. Whether this corresponds to an open or a closed electrical circuit
depends on the ONU's wiring options. Upon ONU initialization, all contact
points should go to the released state.
If the byte is represented in binary as 0B hhgg ffee ddcc bbaa, bits hh
correspond to contact output point 1, while bits aa correspond to contact
output point 8.
On write, the bits of this attribute have the following meaning:
0x No change to contact output point state
10 Release contact output point
11 Operate contact output point
On read, the left bit in each pair should be set to 0 at the ONU and ignored at
the OLT. The right bit indicates a released output point with 0 and an
operated contact point with 1. (R, W) (optional) (2 bytes)
Actions
Get, set
Notifications
Alarm
Alarm
number
Alarm
Description
Reserved
Sense point 1
Environmental sense point 1 active
Sense point 2
Sense point 3
Sense point 4
Sense point 5
Sense point 6
Sense point 7
Sense point 8
9..207
208..223
Reserved
9.1.10 Protection data

This managed entity models the capability and parameters of PON protection. An ONU that
supports PON protection automatically creates one instance of this managed entity. A chassis-based
reach extender could have the capability of protecting a number of PONs, possibly by way of circuit
packs configured in arbitrary (rather than predefined) slots. Protection data managed entities in a
Rec. ITU-T G.988 (10/2012)
75
multi-PON reach extender may therefore be auto-created or created by the OLT, depending on the
reach extender's architecture, and the ANI-G pointers may be either populated by the ONU itself
(read-only) or configured by the OLT (read-write, set-by-create). Likewise, the nature of protection
may be set read-only by the ONU's architecture, or may be settable by the OLT.
NOTE 1 Equipment protection is modelled with the equipment protection profile and cardholder managed
entities.
NOTE 2 For ONUs that implement reach extender functions, this ME can be used to describe OMCI
protection, reach extender R'/S' protection, or both. For reach extender R'/S' protection, the protection type
must be 1:1 without extra traffic, because the switching is done on a link-by-link basis, and the protection
link is in cold standby mode. The instance that pertains to OMCI protection has ME ID = 0.
Relationships
One instance of this managed entity is associated with two instances of the ANI-G, RE
ANI-G or RE upstream amplifier. One of the ANI managed entities represents the working
side; the other represents the protection side.
Attributes
If there is more than one protection data ME, they are numbered in ascending
order from 0. (R, Set-by-create if applicable) (mandatory) (2 bytes)
Working ANI-G pointer: This attribute points to the ANI-G, RE ANI-G or RE upstream
amplifier managed entity that represents the working side of a protected
PON. (R, W if applicable, Set-by-create if applicable) (mandatory) (2 bytes)
NOTE 3 It is possible, and indeed likely, that an ANI-G will have the same ME ID
as the RE ANI-G or even the RE upstream amplifier that supports its physical PON
interface. The ANI-G represents the embedded ONU that terminates the OMCC.
Since it is not expected that protection of management communications will be
implemented independently from protection of the optical layer, the ambiguity is not
expected to cause a problem.
Protection ANI-G pointer: This attribute points to the ANI-G, RE ANI-G or RE upstream
amplifier managed entity that represents the protection side of a protected
PON. (R, W if applicable, Set-by-create if applicable) (mandatory) (2 bytes)
Protection type: This attribute indicates the type of PON protection. Valid values are:
0 1+1 protection
1 1:1 protection without extra traffic
2 1:1 protection with ability to support extra traffic
(R, W if applicable, Set-by-create if applicable) (mandatory) (1 byte)
Revertive ind: This attribute indicates whether protection is revertive (1) or non-revertive
(0). (R, W if applicable, Set-by-create if applicable) (mandatory) (1 byte)
Wait to restore time: This attribute specifies the time, in seconds, to wait after a fault clears
before switching back to the working path. Upon ME instantiation, the ONU
sets this attribute to 3 seconds. (R, W, Set-by-create if applicable)
Switching guard time: This attribute specifies the time, in milliseconds, to wait after the
detection of a fault before performing a protection switch. Specification 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,
Set-by-create if applicable) (optional) (2 bytes)
76
Rec. ITU-T G.988 (10/2012)
Actions
Get, set
If applicable: create, delete
Notifications
None.
9.1.11 Equipment protection profile
This managed entity supports equipment protection. There can be as many as two protection slots
protecting as many as eight working slots. Each of the working and protect cardholder managed
entities should refer to the equipment protection profile that defines its protection group. Instances
of this managed entity are created and deleted by the OLT.
An ONU should deny pre-provisioning that would create impossible protection groupings because
of slot or equipment incompatibilities. In the same way, the ONU should deny creation or addition
to protection groups that cannot be supported by the current equipped configuration. Even so, an
inconsistent card type alarm is defined, for example, to cover the case of a plug-and-play circuit
pack installed in a protection group cardholder that cannot support it.
Relationships
An instance of this object points to the working and protect cardholders, which in turn point
back to this managed entity.
Attributes
The first byte is 0. The second byte is assigned by the OLT, and must be
unique and non-zero. (R, Set-by-create) (mandatory) (2 bytes)
Protect slot 1, Protect slot 2:This pair of attributes describes the protecting cardholder
entities in an equipment protection group. There can be one or two protecting
entities.
0
Undefined entry (default), a place-holder if there are fewer than
two protecting entities in the protection group.
1..254 Slot number of the protecting circuit pack.
(R, W, Set-by-create) (protect slot 1 mandatory, protect slot 2 optional)
(1 byte * 2 attributes)
Working slot 1, Working slot 2, Working slot 3, Working slot 4, Working slot 5,
Working slot 6, Working slot 7, Working slot 8: This group of attributes
describes the working cardholder entities in an equipment protection group.
There can be up to eight working entities.
0
Undefined entry (default), a place-holder if there are fewer than
eight working entities in the protection group.
1..254 Slot number of the working circuit pack.
(R, W, Set-by-create) (working slot 1 mandatory, other working slots
optional) (1 byte * 8 attributes)
Protect status 1, Protect status 2: This pair of attributes indicates whether each protection
cardholder is currently protecting another cardholder, and if so, which one.
0
Not protecting any other cardholder.
1..254 Slot number of the working cardholder currently being protected
by this ME.
Rec. ITU-T G.988 (10/2012)
77
(R) (mandatory) (1 byte * 2 attributes)

Revertive ind: This attribute specifies whether equipment protection is revertive. The
default value 0 indicates revertive switching; any other value indicates nonrevertive switching. (R, W, Set-by-create) (optional) (1 byte)
Wait to restore time: This attribute specifies the time, in minutes, during which a working
equipment must be free of error before a revertive switch occurs. It defaults
to 0. (R, W, Set-by-create) (optional) (1 byte)
Actions
Create, delete, get, set
Notifications
Alarm
Alarm
number
0
1..207
208..223
Alarm
Inconsistent card type
Description
The expected or actual circuit pack type in a slot is incapable
of participating in the equipment protection group, either
because it is not subject to equipment protection or because
its type or equipment ID differs from that previously defined
for the other cardholders of the group. When possible, the
ONU should deny provisioning attempts that would create
incompatibilities, but for example, in the case of plug-andplay, it may not be possible to forestall the inconsistency.
Reserved
9.1.12 ONU remote debug

This managed entity is used to send vendor-specific debug commands to the ONU and receive
vendor-specific replies back for processing on the OLT. This allows for the remote debugging of an
ONU that may not be accessible by other means. The command format may have two modes, one
being text and the other free format. In text format, both the command and reply are ASCII strings,
but are otherwise unconstrained. In free format, the content and format of command and reply are
vendor-specific.
An ONU that supports remote debugging automatically creates an instance of this managed entity.
It is not reported during a MIB upload.
Relationships
Attributes
Command format: This attribute defines the format of the command and reply attributes.
The value 0 defines ASCII string format, while 1 specifies free format. (R)
Command:
78
This attribute is used to send a command to the ONU. The format of the
command is defined by the command format. If the format is ASCII string,
the command should be null terminated unless the string is exactly 25 bytes
long. The action of setting this attribute should trigger the ONU to discard
Rec. ITU-T G.988 (10/2012)
any previous command reply information and execute the current debugging
command. (W) (mandatory) (25 bytes)
Reply table: This attribute is used to pass reply information back to the OLT. Its format is
defined by the command format attribute. The get, get next action sequence
must be used with this attribute, since its size is unspecified. (R) (mandatory)
(N bytes)
Actions
Get, get next, set
Notifications
None.
9.1.13 ONU-E
This managed entity represents a point-to-point gigabit Ethernet-fed ONU as equipment, as defined
in [ITU-T G.986]. The ONU automatically creates an instance of this managed entity. It assigns
values to read-only attributes according to data within the ONU itself.
Relationships
In ITU-T G.986 applications, all other managed entities in this Recommendation are related
directly or indirectly to the ONU-E entity.
Attributes
There is only one instance, number 0. (R) (mandatory) (R)(mandatory)
(2 bytes)
Vendor ID:
This attribute identifies the vendor of the ONU. Both the code set for the
vendor_ID specified in [ATIS-0300220] and organizationally unique
identifier (OUI) specified in clause 9 of [IEEE 802] may be applied to this
attribute.
When the code set for the vendor_ID specified in [ATIS-0300220] is applied
to this attribute, the four characters are mapped into the 4-byte field by
concatenating the ASCII/ANSI character codes.
When the OUI is applied to this attribute, the three characters are mapped
into the 4-byte field with 0xFF assigned to the first octet.
Content
Octet
Vendor_ID in [ATIS-0300220]
Version:
OUI in [IEEE 802]
First byte of Vendor_ID
0xFF
Second byte of Vendor_ID
First byte of OUI
Third byte of Vendor_ID
Second byte of OUI
Fourth byte of Vendor_ID
Third byte of OUI
This attribute identifies the version of the ONU as defined by the vendor. The
character value "0" indicates that version information is not available or
applicable. (R) (mandatory) (14 bytes)
Rec. ITU-T G.988 (10/2012)
79
Serial number: The serial number is unique for each ONU. It is defined by the vendor. The
character value "0" indicates that serial number information is not available
or applicable. (R) (mandatory) (8 bytes)
Actions
Get
Reboot:
Reboot the ONU
Notifications
Alarm
Alarm
number
0
1..207
208..223
Alarm
Equipment alarm
Description
Functional failure on an internal interface
Reserved
Vendor-specific
alarms
9.1.14 ONU dynamic power management control

This managed entity models the ONU's ability to enter power conservation modes in cooperation
with the OLT in an ITU-T G.987 system. [ITU-T G.987.3] specifies two modes, doze and cyclic
sleep.
An ONU that supports power conservation modes automatically creates an instance of this managed
entity.
Relationships
Attributes
Power reduction management capability: This attribute declares the ONU's support for
managed power conservation modes, as defined in [ITU-T G.987.3]. It is a
bit map in which the bit value 0 indicates no support for the specified mode,
while the bit value 1 indicates that the ONU does support the specified mode.
Bits are assigned as follows:
Bit
Meaning
1 (LSB) Doze mode
2
Cyclic sleep mode
3..8
Reserved
Power reduction management mode: This attribute enables one or more of the ONU's
managed power conservation modes. It is a bit map in which the bit value 0
disables the mode, while the value 1 enables the mode. Bit assignments are
the same as those of the power reduction management capability attribute.
The default value of each bit is 0. (R, W) (mandatory) (1 byte)
Itransinit:
80
This attribute is the ONU vendor's statement of the complete transceiver

initialization time: the time required for the ONU to regain full functionality
when leaving the asleep state (i.e., turning on both the receiver and the
Rec. ITU-T G.988 (10/2012)
transmitter and acquiring synchronization to the downstream flow), measured

in units of 125-microsecond frames. The value zero indicates that the
sleeping ONU can respond to a bandwidth grant without delay. (R)
Itxinit:
This attribute is the ONU vendor's statement of the transmitter initialization

time: the time required for the ONU to regain full functionality when leaving
the listen state (i.e., turning on the transmitter), measured in units of
125-microsecond frames. The value zero indicates that the dozing ONU can
respond to a bandwidth grant without delay. (R) (mandatory) (2 bytes)
Maximum sleep interval: The Isleep attribute specifies the maximum time the ONU spends
in its asleep or listen states, as a count of 125-microsecond frames. Local or
remote events may truncate the ONU's sojourn in these states. The default
value of this attribute is 0. (R, W) (mandatory) (4 bytes)
Minimum aware interval: The Iaware attribute specifies the time the ONU spends in its
aware state, as a count of 125-microsecond frames, before it re-enters asleep
or listen states. Local or remote events may independently cause the ONU to
enter an active state rather than returning to a sleep state. The default value of
this attribute is 0. (R, W) (mandatory) (4 bytes)
Minimum active held interval: The Ihold attribute specifies the minimum time during
which the ONU remains in the active held state, as a count of
125-microsecond frames. Its initial value is zero. (R, W) (mandatory)
(2 bytes)
Maximum sleep interval extension: This attribute designates maximum sleep interval
values for doze mode and cyclic sleep mode separately. When it supports this
attribute, the ONU ignores the value of the maximum sleep interval attribute.
Maximum sleep interval for doze mode
4 bytes
Maximum sleep interval for cyclic sleep mode
4 bytes
Maximum sleep interval for doze mode specifies the maximum time the
ONU spends in its listen state, as a count of 125 microsecond frames. Local
or remote events may truncate the ONU's sojourn in these states. The default
value is 0.
Maximum sleep interval for cyclic sleep mode specifies the maximum time
the ONU spends in its asleep state, as a count of 125 microsecond frames.
Local or remote events may truncate the ONU's sojourn in these states. The
default value is 0.
NOTE The dynamic power management control in EPON is basically the same as
the function in [ITU-T G.987.3]. That is, EPON has two types of power-down
modes, which are equivalent to doze mode and cyclic sleep mode, where the former
is defined as Tx mode and the latter is defined as TRx mode in [b-IEEE P1904.1].
Moreover, listen state and asleep state are defined as POWER_DOWN state in
[b-IEEE P1904.1].
Actions
Get, set
Notifications
None.
Rec. ITU-T G.988 (10/2012)
81
9.2
ANI management, traffic management
9.2.1
ANI-G
This managed entity organizes data associated with each access network interface supported by a
G-PON ONU. The ONU automatically creates one instance of this managed entity for each PON
physical port.
Relationships
An instance of this managed entity is associated with each instance of a physical PON
interface.
Attributes
Its value indicates the physical position of the PON interface. The first byte is
the slot ID, defined in clause 9.1.5. The second byte is the port ID. (R)
SR indication: This Boolean attribute indicates the ONU's capability to report queue status
for DBA. The value true means that status reporting is available for all
T-CONTs that are associated with the ANI. (R) (mandatory) (1 byte)
Total T-CONT number: This attribute indicates the total number of T-CONTs that can be
supported on this ANI. (R) (mandatory) (2 bytes)
GEM block length: This attribute specifies the queue occupancy reporting granularity for
DBA, in units of bytes. This attribute is meaningful only in [ITU-T G.984.x]
systems. (R, W) (mandatory) (2 bytes)
In ITU-T G.984 systems, the value set by the OLT is used by all T-CONTs
on this ANI. Upon ME instantiation, the ONU sets this attribute to 48. See
[ITU-T G.984.3] for further details.
In ITU-T G.987 systems, the unit for queue occupancy reporting is fixed in
[ITU-T G.987.3] at 4 bytes.
Piggyback DBA reporting: This attribute indicates the ONU's piggyback DBA reporting
format capabilities. [ITU-T G.984.3] defines two possible piggyback
reporting modes. For reporting mode 0, the single field is the entire report.
For reporting mode 1, the DBA report is two fields long. Mode 0 is
mandatory for ITU-T G.984 ONUs that support piggyback DBA reporting;
mode 1 is optional. [ITU-T G.987.3] allows only one mode, which should be
reported in this attribute as code point 0.
The following coding indicates the ONU's piggyback DBA reporting mode
capabilities:
0 Mode 0 only
1 Modes 0 and 1
2 Deprecated
3 Deprecated
4 Piggyback DBA reporting not supported
Deprecated: This attribute should be set to 0 by the ONU and ignored by the OLT. (R)
82
Rec. ITU-T G.988 (10/2012)
SF threshold: This attribute specifies the downstream BER threshold to detect the signal
fail (SF) alarm. When this value is y, the BER threshold is 10y. Valid values
are 3..8. Upon ME instantiation, the ONU sets this attribute to 5. (R, W)
SD threshold: This attribute specifies the downstream BER threshold to detect the signal
degrade (SD) alarm. When this value is x, the BER threshold for SD is 10x.
Valid values are 4..10. The SD threshold must be lower than the SF
threshold; that is, x > y. Upon ME instantiation, the ONU sets this attribute to
9. (R, W) (mandatory) (1 byte)
ARC:

Optical signal level: This attribute reports the current measurement of the total downstream
optical signal level. Its value is a 2s complement integer referred to 1 mW
(i.e., dBm), with 0.002 dB granularity. (R) (optional) (2 bytes)
Lower optical threshold: This attribute specifies the optical level the ONU uses to declare
the downstream low received optical power alarm. Valid values are
127 dBm (coded as 254) to 0 dBm (coded as 0) in 0.5 dB increments. The
default value 0xFF selects the ONU's internal policy. (R, W) (optional)
(1 byte)
Upper optical threshold: This attribute specifies the optical level the ONU uses to declare
the downstream high received optical power alarm. Valid values are
default value 0xFF selects the ONU's internal policy. (R, W) (optional)
(1 byte)
ONU response time: This attribute indicates the ONU's actual response time.
[ITU-T G.984.3] and [ITU-T G.987.3] specify that this attribute is in the
range 34..36 microseconds. Although this attribute is expressed in
nanoseconds, its accuracy is likely to be more coarse. Furthermore, the value
may change from one activation cycle to the next. Valid values are:
0 (Null, function not supported)
34000 to 36000 (response time in nanoseconds)
All other values reserved
Transmit optical level: This attribute reports the current measurement of mean optical
launch power. Its value is a 2s complement integer referred to 1 mW (i.e.,
dBm), with 0.002 dB granularity. (R) (optional) (2 bytes)
Lower transmit power threshold: This attribute specifies the minimum mean optical
launch power that the ONU uses to declare the low transmit optical power
alarm. Its value is a 2s complement integer referred to 1 mW (i.e., dBm),
with 0.5 dB granularity. The default value 63.5 (0x81) selects the ONU's
internal policy. (R, W) (optional) (1 byte)
Upper transmit power threshold: This attribute specifies the maximum mean optical
launch power that the ONU uses to declare the high transmit optical power
with 0.5 dB granularity. The default value 63.5 (0x81) selects the ONU's
internal policy. (R, W) (optional) (1 byte)
Rec. ITU-T G.988 (10/2012)
83
Actions
Get, set
Test the ANI-G. The test action can be used to perform optical line
supervision tests; refer to Annex A.
Test:
Notifications

Number
1..7
N/A
ARC
9..16
N/A
Description
Alarm reporting control cancellation
Alarm
Alarm
number
Alarm
Low received optical

power
Received downstream optical power below threshold.
High received optical

power
Received downstream optical power above threshold.
SF
Bit error-based signal fail. Industry practice normally

expects the BER to improve by at least an order of
magnitude before clearing the alarm.
SD
Bit error-based signal degrade. Industry practice normally

expects the BER to improve by at least an order of
magnitude before clearing the alarm.
Low transmit optical

power
Transmit optical power below lower threshold
High transmit optical

power
Transmit optical power above upper threshold
Laser bias current
Laser bias current above threshold determined by vendor;

laser end of life pending
7..207
208..223
Reserved
Test result:
9.2.2
Description
The ONU may report a test result autonomously if it performs self-test

functions autonomously.
T-CONT
An instance of the traffic container managed entity T-CONT represents a logical connection group
associated with a G-PON PLOAM layer alloc-ID. A T-CONT can accommodate GEM packets in
priority queues or traffic schedulers that exist in the GEM layer.
The ONU autonomously creates instances of this ME. The OLT can discover the number of
T-CONT instances via the ANI-G ME. When the ONU's MIB is reset or created for the first time,
all supported T-CONTs are created. The OLT provisions alloc-IDs to the ONU via the PLOAM
channel. Via the OMCI, the OLT must then set the alloc-ID attributes in the T-CONTs that it wants
to activate for user traffic, to create the appropriate association with the allocation ID in the
84
Rec. ITU-T G.988 (10/2012)
PLOAM channel. There should be a one-to-one relationship between allocation IDs and T-CONT
MEs; the connection of multiple T-CONTs to a single allocation ID is undefined.
The allocation ID that matches the ONU-ID itself is defined to be the default alloc-ID. This
alloc-ID is used to carry the OMCC. The default alloc-ID can also be used to carry user traffic, and
hence can be assigned to one of the T-CONT MEs. However, this OMCI relationship only pertains
to user traffic, and the OMCC relationship is unaffected. It can also be true that the OMCC is not
contained in any T-CONT ME construct; rather, that the OMCC remains outside of the OMCI, and
that the OMCI is not used to manage the OMCC in any way. Multiplexing of the OMCC and user
data in G-PON systems is discussed in clause B.2.4.
Relationships
One or more instances of this managed entity are associated with an instance of a circuit
pack that supports a PON interface function, or with the ONU-G itself.
Attributes
This two-byte number indicates the physical capability that realizes the
T-CONT. It may be represented as 0xSSBB, where SS indicates the slot ID
that contains this T-CONT (0 for the ONU as a whole), and BB is the
T-CONT id, numbered by the ONU itself. T-CONTs are numbered in
ascending order, with the range 0..255 in each slot. (R) (mandatory) (2 bytes)
Alloc-ID:
This attribute links the T-CONT with the alloc-ID assigned by the OLT in the
assign_alloc-ID PLOAM message. In [ITU-T G.984.3], legal values range
from 0 to 0x0FFF, with some values having special meaning. In
[ITU-T G.987.3], legal values range from 0 to 0x3FFF, with some values
having special meaning. Prior to the setting of this attribute by the OLT, this
attribute has an unambiguously unusable initial value, namely the value
0x00FF or 0xFFFF for ITU-T G.984 systems, and the value 0xFFFF for
ITU-T G.987 systems. (R, W) (mandatory) (2 bytes)
Deprecated: The ONU should set this attribute to the value 1, and the OLT should ignore
it. (R) (mandatory) (1 byte)
Policy:
This attribute indicates the T-CONT's traffic scheduling policy. Valid values:
0 Null
1 Strict priority
2 WRR Weighted round robin
NOTE This attribute is read-only, unless otherwise specified by the QoS
configuration flexibility attribute of the ONU2-G managed entity. If flexible
configuration is not supported, the ONU should reject an attempt to set it with a
parameter error result-reason code.
Actions
Get, set
Notifications
None.
Rec. ITU-T G.988 (10/2012)
85
9.2.3
This managed entity represents the termination of a GEM port on an ONU. This managed entity
aggregates connectivity functionality from the network view and alarms from the network element
view as well as artefacts from trails.
Instances of the GEM port network CTP managed entity are created and deleted by the OLT. An
instance of GEM port network CTP can be deleted only when no GEM interworking termination
point or GEM port network CTP PM history data is associated with it. It is the responsibility of the
OLT to make sure that the ONU configuration meets this condition.
In ITU-T G.984 systems, when a GEM port network CTP is created, its encryption state is by
default not encrypted. If the OLT wishes to configure the GEM port to use encryption, it must send
the appropriate PLOAM message. This applies equally to new CTPs and to CTPs that are re-created
after a MIB reset.
In ITU-T G.987 systems, GEM ports are dynamically encrypted. If it is intended to encrypt the
GEM port, the OLT must configure a key ring to be used, and the key must be known to the ONU
at run time.
Relationships
An instance of the GEM port network CTP managed entity may be associated with an
instance of the T-CONT and GEM interworking termination point managed entities.
Attributes
(R, Set-by-create) (mandatory) (2 bytes)
Port-ID:
This attribute is the port-ID of the GEM port associated with this CTP.
(R, W, Set-by-create) (mandatory) (2 bytes)
NOTE 1 While nothing forbids the existence of several GEM port network CTPs
with the same port-ID value, downstream traffic is modelled as being delivered to all
such GEM port network CTPs. Be aware of potential difficulties associated with
defining downstream flows and aggregating PM statistics.
T-CONT pointer: This attribute points to a T-CONT instance. (R, W, Set-by-create)

Direction:
This attribute specifies whether the GEM port is used for UNI-to-ANI (1),
ANI-to-UNI (2), or bidirectional (3) connection. (R, W, Set-by-create)
Traffic management pointer for upstream: If the traffic management option attribute in
the ONU-G ME is 0 (priority controlled) or 2 (priority and rate controlled),
this pointer specifies the priority queue ME serving this GEM port network
CTP. If the traffic management option attribute is 1 (rate controlled), this
attribute redundantly points to the T-CONT serving this GEM port network
CTP. (R, W, Set-by-create) (mandatory) (2 bytes)
Traffic descriptor profile pointer for upstream: This attribute points to the instance of the
traffic descriptor managed entity that contains the upstream traffic parameters
for this GEM port network CTP. This attribute is used when the traffic
management option attribute in the ONU-G ME is 1 (rate controlled),
specifying the PIR/PBS to which the upstream traffic is shaped. This attribute
is also used when the traffic management option attribute in the ONU-G ME
is 2 (priority and rate controlled), specifying the CIR/CBS/PIR/PBS to which
the upstream traffic is policed. (R, W, Set-by-create) (optional) (2 bytes)
86
Rec. ITU-T G.988 (10/2012)
See also Appendix II.

UNI counter: This attribute reports the number of instances of UNI-G managed entity
associated with this GEM port network CTP. (R) (optional) (1 byte)
Priority queue pointer for downstream: This attribute points to the instance of the priority
queue used for this GEM port network CTP in the downstream direction. It is
the responsibility of the OLT to provision the downstream pointer in a way
that is consistent with the bridge and mapper connectivity. If the pointer is
null, downstream queueing is determined by other mechanisms in the ONU.
NOTE 2 If the GEM port network CTP is associated with more than one UNI
(downstream multicast), the downstream priority queue pointer defines a pattern
(e.g., queue number 3 for a given UNI) to be replicated (i.e., to queue number 3) at
the other affected UNIs.
Encryption state: This attribute indicates the current state of the GEM port network CTP's
encryption. Legal values are defined to be the same as those of the security
mode attribute of the ONU2-G, with the exception that attribute value 0
indicates an unencrypted GEM port. (R) (optional) (1 byte)
Traffic descriptor profile pointer for downstream: This attribute points to the instance of
the traffic descriptor managed entity that contains the downstream traffic
parameters for this GEM port network CTP. This attribute is used when the
traffic management option attribute in the ONU-G ME is 1 (rate controlled),
specifying the PIR/PBS to which the downstream traffic is shaped. This
attribute is also used when the traffic management option attribute in the
ONU-G ME is 2 (priority and rate controlled), specifying the
CIR/CBS/PIR/PBS to which the downstream traffic is policed. (R, W,
Set-by-create) (optional) (2 bytes)
Encryption key ring: This attribute is defined in ITU-T G.987 systems only. It specifies
whether the associated GEM port is encrypted or not, and if so, which key
ring it uses. (R, W, Set-by-create) (optional) (1 byte)
0 (default) No encryption. The downstream key index is ignored, and
upstream traffic is transmitted with key index 0.
1 Unicast payload encryption in both directions. Keys are generated by
the ONU and transmitted to the OLT via the PLOAM channel.
2 Broadcast (multicast) encryption. Keys are generated by the OLT and
distributed via the OMCI.
3 Unicast encryption, downstream only. Keys are generated by the
ONU and transmitted to the OLT via the PLOAM channel.
Actions
Rec. ITU-T G.988 (10/2012)
87
Notifications
Alarm
Alarm
number
0..4
5
6..207
208..223
9.2.4
Alarm
Description
Reserved
End-to-end loss of continuity
Loss of continuity can be detected when the GEM port

network CTP supports a GEM interworking
termination point (optional).
Reserved
GEM interworking termination point
An instance of this managed entity represents a point in the ONU where the interworking of a
bearer service (usually Ethernet) to the GEM layer takes place. At this point, GEM packets are
generated from the bearer bit stream (e.g., Ethernet) or the bearer bit stream is reconstructed from
GEM packets.
Instances of this managed entity are created and deleted by the OLT.
Relationships
One instance of this managed entity exists for each transformation of a data stream into
GEM frames and vice versa.
Attributes
GEM port network CTP connectivity pointer: This attribute points to an instance of the
GEM port network CTP. (R, W, Set-by-create) (mandatory) (2 bytes)
Interworking option: This attribute identifies the type of non-GEM function that is being
interworked. The options are:
0 Circuit-emulated TDM
1 MAC bridged LAN
2 Reserved
3 Reserved
4 Video return path
5 IEEE 802.1p mapper
6 Downstream broadcast
7 MPLS PW TDM service
(R, W, Set-by-create) (mandatory) (1 byte)
Service profile pointer: This attribute points to an instance of a service profile:
CES service profile
if interworking option = 0
Video return path service profile
IEEE 802.1p mapper service profile if interworking option = 5
Null pointer
CES service profile
NOTE The video return path service profile is defined in [ITU-T G.984.4].
88
Rec. ITU-T G.988 (10/2012)
Interworking termination point pointer: This attribute is used for the circuit emulation
service and IEEE 802.1p mapper service without a MAC bridge. Depending
on the service provided, it points to the associated instance of the following
managed entities:
Physical path termination point CES UNI
Logical N 64 kbit/s sub-port connection termination point
Physical path termination point Ethernet UNI
In all other GEM services, the relationship between the related service
termination point and this GEM interworking termination point is derived
from other managed entity relations; this attribute is set to a null pointer and
not used. (R, W, Set-by-create) (mandatory) (2 bytes)
PPTP counter: This value reports the number of PPTP managed entity instances associated
with this GEM interworking termination point. (R) (optional) (1 byte)
Operational state: This attribute indicates whether or not the managed entity is capable of
(optional) (1 byte)
GAL profile pointer: This attribute points to an instance of the GAL profile. The
relationship between the interworking option and the related GAL profile is:
Interworking option GAL profile type
0
Null pointer
1
3
GAL Ethernet profile for data service
4
GAL Ethernet profile for video return path
5
GAL Ethernet profile for IEEE 802.1p mapper
6
Null pointer
7
Null pointer
GAL loopback configuration: This attribute sets the loopback configuration when using
GEM mode:
0 No loopback
1 Loopback of downstream traffic after GAL
The default value of this attribute is 0. When the interworking option is 6
(downstream broadcast), this attribute is not used. (R, W) (mandatory)
(1 byte)
Actions
Notifications
Number
1..5
6
Description
N/A
Op state
7..8
N/A
9..16
Reserved
Rec. ITU-T G.988 (10/2012)
89
Alarm
Alarm
number
0
1..207
208..223
9.2.5
Alarm
Description
Deprecated
Reserved
Multicast GEM interworking termination point
An instance of this managed entity represents a point in a G-PON ONU where a multicast service
interworks with the GEM layer. At this point, a multicast bit stream is reconstructed from GEM
packets.
Multicast interworking GEM modes of operation
The default multicast operation of the PON is where all the multicast content streams are carried in
one PON layer connection (GEM port). This connection is then specified in the first entry of the
IPv4 or IPv6 multicast address table, as the case may be. This single entry also specifies an allinclusive IP multicast destination address range (e.g., 224.0.0.0 to 239.255.255.255 in the case of
IPv4). The ONU then filters the traffic based on either Ethernet MAC addresses or IP addresses.
The associated GEM port network CTP ME specifies the GEM port-ID that supports all multicast
connections.
In the default multicast operation, all multicast content streams are placed in one PON layer
connection (GEM port). The OLT sets up a completely conventional model, a pointer from the
multicast GEM interworking termination to a GEM port network CTP. The OLT configures the
GEM port-ID of the GEM port network CTP into the appropriate multicast address table
attribute(s), along with the other table fields that specify the range of IP multicast destination
addresses. The ONU accepts the entire multicast stream through the designated GEM port, then
filters the traffic based on either the Ethernet MAC address or IP destination address.
An optional multicast configuration supports separate multicast streams carried over separate PON
layer connections, i.e., on separate GEM ports. This permits the ONU to filter multicast streams at
the GEM level, which is efficient in hardware, while ignoring other multicast streams that may be
of interest to other ONUs on the PON.
After configuring the explicit model for the first multicast GEM port, the OLT supports multiple
multicast GEM ports by then configuring additional entries into the multicast address table(s),
entries with different GEM port-IDs. The OMCI model is defined such that these ports are
implicitly grouped together and served by the single explicit GEM port network CTP. No additional
GEM network CTPs need be created or linked for the additional GEM ports.
Several multicast GEM interworking termination points can exist, each linked to separate bridge
ports or mappers to serve different communities of interest in a complex ONU.
Discovery of multicast support
The OLT uses the multicast GEM IW TP entity as the means to discover the ONU's multicast
capability. This entity is mandatory if multicast is supported by the ONU. If the OLT attempts to
create this entity on an ONU that does not support multicast, the create command fails. The create
or set command also fails if the OLT attempts to exploit optional features that the ONU does not
support, for example in attempting to write a multicast address table with more than a single entry
or to create multiple multicast GEM interworking termination points.
90
Rec. ITU-T G.988 (10/2012)
This managed entity is defined by a similarity to the unicast GEM interworking termination point,
and a number of its attributes are not meaningful in a multicast context. These attributes are set to 0
and not used, as indicated below.
Relationships
An instance of this managed entity exists for each occurrence of transformation of GEM
packets into a multicast data stream.
Attributes
The value 0xFFFF is reserved. (R, Set-by-create) (mandatory) (2 bytes)
GEM port network CTP connectivity pointer: This attribute points to an instance of the
GEM port network CTP that is associated with this multicast GEM
interworking termination point. (R, W, Set-by-create) (mandatory) (2 bytes)
Interworking option: This attribute identifies the type of non-GEM function that is being
interworked. The option can be:
0 This value is a "no-op" or "don't care". It should be used when the
multicast GEM IW TP is associated with several functions of
different types. It can optionally be used in all cases, since the
necessary information is available elsewhere. The previous code
points are retained for backward compatibility:
1 MAC bridged LAN
3 Reserved
5 IEEE 802.1p mapper
Service profile pointer: This attribute is set to 0 and not used. For backward compatibility,
it may also be set to point to a MAC bridge service profile or IEEE 802.1p
mapper service profile. (R, W, Set-by-create) (mandatory) (2 bytes)
Not used 1:
This attribute is set to 0 and not used. (R, W, Set-by-create) (mandatory)

(2 bytes)
PPTP counter: This attribute represents the number of instances of PPTP managed entities
associated with this instance of the multicast GEM interworking termination
point. This attribute conveys no information that is not available elsewhere; it
may be set to 0xFF and not used. (R) (optional) (1 byte)
(optional) (1 byte)
GAL profile pointer: This attribute is set to 0 and not used. For backward compatibility, it
may also be set to point to a GAL Ethernet profile. (R, W, Set-by-create)
Not used 2:
This attribute is set to 0 and not used. (R, W, Set-by-create) (mandatory)

(1 byte)
Rec. ITU-T G.988 (10/2012)
91
IPv4 multicast address table: This attribute maps IP multicast addresses to PON layer
addresses. Each entry contains:
GEM port-ID
2 bytes
Secondary key
2 bytes
IP multicast destination address range start
4 bytes
IP multicast destination address range stop
4 bytes
The first four bytes of each entry are treated as a key into the list. The
secondary key allows the table to contain more than a single range for a given
GEM port.
A set action to a particular value overwrites any existing entry with the same
first four bytes. If the last eight bytes of a set command are all zero, that entry
is deleted from the list, as the IP address 0.0.0.0 is not valid.
(R, W) (mandatory) (12N bytes, where N is the number of entries in the list.)
IPv6 multicast address table: This attribute maps IPv6 multicast destination addresses to
PON layer addresses. Each entry contains:
GEM port-ID
2 bytes
Secondary key
2 bytes
Least significant bytes,
IP multicast destination address range start 4 bytes
Least significant bytes,
IP multicast destination address range stop 4 bytes
Most significant bytes, IP destination address 12 bytes
The first four bytes of each entry are treated as a key into the list. The
secondary key allows the table to contain more than a single range for a given
GEM port.
A set action to a particular value overwrites any existing entry with the same
first four bytes. If the last twenty bytes of a set command are all zero, that
entry is deleted from the list.
(R, W) (optional) (24N bytes, where N is the number of entries in the list.)
Actions
Create, delete, get, get next, set
Set table (optional)
Notifications
Number
1..5
6
7..9
10..16
92
Description
N/A
Op state
N/A
Reserved
Rec. ITU-T G.988 (10/2012)
Alarm
Alarm
number
0
1..207
208..223
Alarm
Description
Deprecated
Reserved
9.2.6
9.2.7
This managed entity organizes data that describe the GTC adaptation layer processing functions of
the ONU for Ethernet services. It is used with the GEM interworking termination point managed
entity.
Instances of this managed entity are created and deleted on request of the OLT.
Relationships
An instance of this managed entity may be associated with zero or more instances of the
GEM interworking termination point managed entity.
Attributes
Maximum GEM payload size: This attribute defines the maximum payload size generated
in the associated GEM interworking termination point managed entity.
Actions
Notifications
None.
9.2.8
GAL Ethernet performance monitoring history data
This managed entity collects performance monitoring data associated with a GEM interworking
termination point when the GEM layer supports an Ethernet service. Instances of this managed
entity are created and deleted by the OLT.
For a complete discussion of generic PM architecture, refer to clause I.4.
Relationships
An instance of this managed entity is associated with an instance of the GEM interworking
termination point managed entity.
Attributes
instance of the GEM interworking TP. (R, Set-by-create) (mandatory)
(2 bytes)
Interval end time: This attribute identifies the most recently finished 15-minute interval.
Rec. ITU-T G.988 (10/2012)
93
Threshold data 1/2 ID: This attribute points to an instance of the threshold data 1 managed
entity that contains PM threshold values. Since no threshold value attribute
number exceeds 7, a threshold data 2 ME is optional. (R, W, Set-by-create)
Discarded frames: This attribute counts the number of downstream GEM frames discarded
for any reason (erroneous FCS, too long length, buffer overflow, etc.). (R)
Actions
Get current data (optional)
Notifications
Threshold crossing alert
Alarm
number
0
Threshold value attribute # (Note)
Discarded frames
NOTE This number associates the TCA with the specified threshold value attribute of the
threshold data 1 managed entity.
9.2.9
FEC performance monitoring history data
This managed entity collects performance monitoring data associated with PON downstream FEC
counters. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an instance of the ANI-G managed
entity.
Attributes
instance of the ANI-G. (R, Set-by-create) (mandatory) (2 bytes)
Corrected bytes: This attribute counts the number of bytes that were corrected by the FEC
function. (R) (mandatory) (4 bytes)
Corrected code words: This attribute counts the code words that were corrected by the FEC
function. (R) (mandatory) (4 bytes)
Uncorrectable code words: This attribute counts errored code words that could not be
corrected by the FEC function. (R) (mandatory) (4 bytes)
Total code words: This attribute counts the total received code words. (R) (mandatory)
(4 bytes)
94
Rec. ITU-T G.988 (10/2012)
FEC seconds: This attribute counts seconds during which there was a forward error
correction anomaly. (R) (mandatory) (2 bytes)
Actions
Notifications
Alarm
number
Threshold value attribute #

(Note)
Corrected bytes
Corrected code words
Uncorrectable code words
FEC seconds
9.2.10 Priority queue

NOTE 1 In [ITU-T G.984.4], this is called a priority queue-G.
This managed entity specifies the priority queue used by a GEM port network CTP in the upstream
direction. The upstream priority queue ME is also related to a T-CONT ME. By default, this
relationship is fixed by the ONU hardware architecture, but some ONUs may also permit the
relationship to be configured through the OMCI, as indicated by the QoS configuration flexibility
attribute of the ONU2-G managed entity.
In the downstream direction, priority queues are associated with UNIs. Again, the association is
fixed by default, but some ONUs may permit the association to be configured through the OMCI.
If an ONU as a whole contains priority queues, it instantiates these queues autonomously. Priority
queues may also be localized to pluggable circuit packs, in which case the ONU creates and deletes
them in accordance with circuit pack pre-provisioning and the equipped configuration.
The OLT can find all the queues by reading the priority queue managed entity instances. If the OLT
tries to retrieve a non-existent priority queue, the ONU denies the get action with an error
indication.
Priority queues can exist in the ONU core and circuit packs serving both UNI and ANI functions.
Therefore, they can be indirectly created and destroyed through cardholder provisioning actions.
In the upstream direction, the weight attribute permits the configuring of an optional traffic
scheduler. Several attributes support back pressure operation, whereby a back-pressure signal is sent
backwards and causes the attached terminal to temporarily suspend sending data.
In the downstream direction, strict priority discipline among the queues serving a given UNI is the
default, with priorities established through the related port attribute. If two or more non-empty
queues have the same priority, capacity is allocated among them in proportion to their weights.
Note that the details of the downstream model differ from those of the upstream model.
The yellow packet drop thresholds specify the drop probability for a packet that has been marked
yellow (drop eligible) by a traffic descriptor or by external equipment such as a residential gateway.
If the current average queue occupancy is less than the minimum threshold, the yellow packet drop
Rec. ITU-T G.988 (10/2012)
95
probability is zero. If the current average queue occupancy is greater than or equal to the maximum
threshold, the yellow packet drop probability is one. The yellow drop probability increases linearly
between 0 and max_p as the current average queue occupancy increases from the minimum to the
maximum threshold.
The same model can be configured for green packets, those regarded as being within the traffic
contract.
Drop precedence colour marking indicates the method by which a packet is marked as drop eligible
(yellow). For DEI and PCP marking, a drop eligible indicator is equivalent to yellow colour;
otherwise, the colour is green. For DSCP AF marking, the lowest drop precedence is equivalent to
green; otherwise, the colour is yellow.
Relationships
One or more instances of this managed entity are associated with the ONU-G managed
entity to model upstream priority queues if the traffic management option attribute in the
ONU-G ME is 0 or 2.
One or more instances of this managed entity are associated with a physical path termination
point UNI managed entity as downstream priority queues. Downstream priority queues may
or may not be provided for a virtual Ethernet interface point.
Attributes
The most significant bit represents the direction (1: upstream,
0: downstream). The 15 least significant bits represent a queue ID. The queue
ID is numbered in ascending order by the ONU itself. It is strongly
encouraged that the queue ID be formulated to simplify finding related
queues. One way to do this is to number the queues such that the related port
attributes are in ascending order (for the downstream and upstream queues
separately). The range of downstream queue ids is 0 to 0x7FFF and the range
of upstream queue ids is 0x8000 to 0xFFFF. (R) (mandatory) (2 bytes)
Queue configuration option: This attribute identifies the buffer partitioning policy. The
value 1 means that several queues share one buffer of maximum queue size,
while the value 0 means that each queue has an individual buffer of
maximum queue size. (R) (mandatory) (1 byte)
Maximum queue size: This attribute specifies the maximum size of the queue, in bytes,
scaled by the priority queue scale factor attribute of the ONU2-G. (R)
NOTE 2 In this and the other similar attributes of the priority queue ME, some
legacy implementations may take the queue scale factor from the GEM block length
attribute of the ANI-G managed entity. This option is discouraged in new
implementations.
Allocated queue size: This attribute identifies the allocated size of this queue, in bytes,
scaled by the priority queue scale factor attribute of the ONU2-G. (R, W)
Discard-block counter reset interval: This attribute represents the interval in milliseconds
at which the counter resets itself. (R, W) (optional) (2 bytes)
96
Rec. ITU-T G.988 (10/2012)
Threshold value for discarded blocks due to buffer overflow: This attribute specifies the
threshold for the number of bytes (scaled by the priority queue scale factor
attribute of the ONU2-G) discarded on this queue due to buffer overflow. Its
value controls the declaration of the block loss alarm. (R, W) (optional)
(2 bytes)
Related port: This attribute represents the slot, port/T-CONT and priority information
associated with the instance of priority queue ME. This attribute comprises
four bytes.
In the upstream direction, the first two bytes are the ME ID of the associated
T-CONT, the first byte of which is a slot number, the second byte a T-CONT
number. In the downstream direction, the first byte is the slot number and the
second byte is the port number of the queue's destination port.
The last two bytes represent the priority of this queue. The range of priority is
0 to 0x0FFF. The value 0 indicates the highest priority and 0x0FFF indicates
the lowest priority. The priority field is meaningful if multiple priority queues
are associated with a T-CONT or traffic scheduler whose scheduling
discipline is strict priority.
NOTE 3 If flexible port configuration is supported, the related port attribute is
meaningful only if the traffic scheduler pointer attribute value is null. Otherwise, the
related port attribute is ignored.
NOTE 4 The related port attribute is read-only, unless otherwise specified by the
QoS configuration flexibility attribute of the ONU2-G managed entity. If port
flexibility is supported, the second byte, the port or T-CONT number, may be
changed. If priority flexibility is supported, the third and fourth bytes may be
changed. The OMCI set command must contain four bytes to match the attribute
size, but the ONU must ignore all bytes that are not specified to be flexible.
If flexible configuration is not supported, the ONU should reject an attempt to set
the related port with a parameter error result-reason code.
Traffic scheduler pointer: This attribute points to the traffic scheduler ME instance that is
associated with this priority queue. This pointer is used when this priority
queue is connected with a traffic scheduler. The default value is a null pointer
(0). (R, W) (mandatory) (2 bytes)
NOTE 5 When the QoS configuration flexibility attribute of the ONU2-G
managed entity allows flexible assignment of the traffic scheduler, the OLT may
configure the traffic scheduler pointer to refer to any traffic scheduler in the same
slot.
If traffic scheduler flexibility is not permitted by the QoS configuration flexibility
attribute, the OLT may use the traffic scheduler pointer attribute only by pointing to
another traffic scheduler ME that is associated with the same T-CONT as the
priority queue itself.
The ONU should reject an attempt to violate these conditions with a parameter error
result-reason code.
Weight:
This attribute represents weight for WRR scheduling. At a given priority

level, capacity is distributed to non-empty queues in proportion to their
weights. In the upstream direction, this weight is meaningful if several
priority queues are associated with a traffic scheduler or T-CONT whose
policy is WRR. In the downstream direction, this weight is used by a UNI in
a WRR fashion. Upon ME instantiation, the ONU sets this attribute to 1.
Rec. ITU-T G.988 (10/2012)
97
Back pressure operation: This attribute enables (0) or disables (1) back pressure operation.
Its default value is 0. (R, W) (mandatory) (2 bytes)
Back pressure time: This attribute specifies the duration in microseconds of the
back-pressure signal. It can be used as a pause time for an Ethernet UNI.
Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (mandatory)
(4 bytes)
Back pressure occur queue threshold: This attribute identifies the threshold queue
occupancy, in bytes, scaled by the priority queue scale factor attribute of the
ONU2-G, to start sending a back-pressure signal. (R, W) (mandatory)
(2 bytes)
Back pressure clear queue threshold: This attribute identifies the threshold queue
occupancy, in bytes, scaled by the priority queue scale factor attribute of the
ONU2-G, to stop sending a back-pressure signal. (R, W) (mandatory)
(2 bytes)
Packet drop queue thresholds: This attribute is a composite of four 2-byte values, a
minimum and a maximum threshold, measured in bytes, scaled by the
priority queue scale factor attribute of the ONU2-G, for green and yellow
packets. The first value is the minimum green threshold, the queue
occupancy below which all green packets are admitted to the queue. The
second value is the maximum green threshold, the queue occupancy at or
above which all green packets are discarded. The third value is the minimum
yellow threshold, the queue occupancy below which all yellow packets are
admitted to the queue. The fourth value is the maximum yellow threshold, the
queue occupancy at or above which all yellow packets are discarded. The
default is that all thresholds take the value of the maximum queue size.
Packet drop max_p: This attribute is a composite of two 1-byte values, the probability of
dropping a coloured packet when the queue occupancy lies just below the
maximum threshold for packets of that colour. The first value is the green
packet max_p, and the second value is the yellow packet max_p. The
probability, max_p, is determined by adding one to the unsigned value
(0..255) of this attribute and dividing the result by 256. The default for each
value is 255. (R, W) (optional) (2 bytes)
Queue drop w_q: This attribute determines the averaging coefficient, w_q, as described in
Floyd and Jacobson [b-Floyd]. The averaging coefficient, w_q, is equal to
2-Queue_drop_w_q. For example, when queue drop_w_q has the value 9, the
averaging coefficient, w_q, is 1/512 = 0.0019. The default value is 9. (R, W)
(optional) (1 byte)
Drop precedence colour marking: This attribute specifies how drop precedence is marked
on ingress packets to the priority queue. The default value is 0.
0 No marking (treat all packets as green)
1 Internal marking (from traffic descriptor ME)
2 DEI [IEEE 802.1ad]
3 PCP 8P0D [IEEE 802.1ad]
7 DSCP AF class [IETF RFC 2597]
98
Rec. ITU-T G.988 (10/2012)
Actions
Get, set
Notifications
Alarm
Alarm
number
Alarm
Block loss
1..207
Reserved
208..223
Description
Content loss in excess of threshold. The alarm is cleared
when the discard block counter reset interval next expires.
9.2.11 Traffic scheduler

NOTE 1 In [ITU-T G.984.4], this managed entity is called a traffic scheduler-G.
An instance of this managed entity represents a logical object that can control upstream GEM
packets. A traffic scheduler can accommodate GEM packets after a priority queue or other traffic
scheduler and transfer them towards the next traffic scheduler or T-CONT. Because T-CONTs and
traffic schedulers are created autonomously by the ONU, the ONU vendor predetermines the most
complex traffic handling model it is prepared to support; the OLT may use less than the ONU's full
capabilities, but cannot ask for more. See Appendix II for more details.
After the ONU creates instances of the T-CONT ME, it then autonomously creates instances of the
traffic scheduler ME.
Relationships
The traffic scheduler ME may be related to a T-CONT or other traffic schedulers through
pointer attributes.
Attributes
This two-byte number indicates the physical capability that realizes the traffic
scheduler. The first byte is the slot ID of the circuit pack with which this
traffic scheduler is associated. For a traffic scheduler that is not associated
with a circuit pack, the first byte is 0xFF. The second byte is the traffic
scheduler id, assigned by the ONU itself. Traffic schedulers are numbered in
ascending order with the range 0..0xFF in each circuit pack or in the ONU
core. (R) (mandatory) (2 bytes)
T-CONT pointer: This attribute points to the T-CONT ME instance associated with this
traffic scheduler. This pointer is used when this traffic scheduler is connected
to the T-CONT directly; It is null (0) otherwise. (R, W) (mandatory) (2 bytes)
NOTE 2 This attribute is read-only unless otherwise specified by the QoS
configuration is not supported, the ONU should reject an attempt to set the T-CONT
pointer attribute with a parameter error result-reason code.
Traffic scheduler pointer: This attribute points to another traffic scheduler ME instance
that may serve this traffic scheduler. This pointer is used when this traffic
scheduler is connected to another traffic scheduler; it is null (0) otherwise.
Rec. ITU-T G.988 (10/2012)
99
Policy:
This attribute represents scheduling policy. Valid values include:

0 Null
1 Strict priority
2 WRR (weighted round robin)
The traffic scheduler derives priority or weight values for its tributary traffic
schedulers or priority queues from the tributary MEs themselves.
NOTE 3 This attribute is read-only unless otherwise specified by the QoS
configuration is not supported, the ONU should reject an attempt to set the policy
attribute with a parameter error result-reason code.
Priority/weight: This attribute represents the priority for strict priority scheduling or the
weight for WRR scheduling. This value is used by the next upstream
managed entity, as indicated by the T-CONT pointer attribute or traffic
scheduler pointer attribute.
If the indicated pointer has policy = strict priority, this value is interpreted as
a priority (0 is the highest priority, 255 the lowest).
If the indicated pointer has policy = WRR, this value is interpreted as a
weight. Higher values receive more bandwidth.
(1 byte)
Actions
Get, set
Notifications
None.
9.2.12 Traffic descriptor
The traffic descriptor is a profile that allows for traffic management. A priority controlled ONU can
point from a MAC bridge port configuration data ME to a traffic descriptor in order to implement
traffic management (marking, policing). A rate controlled ONU can point to a traffic descriptor
from either a MAC bridge port configuration data ME or a GEM port network CTP to implement
traffic management (marking, shaping).
Packets are determined to be green, yellow or red as a function of the ingress packet rate and the
settings in this ME. The colour indicates drop precedence (eligibility), subsequently used by the
priority queue ME to drop packets conditionally during congestion conditions. Packet colour is also
used by the optional mode 1 DBA status reporting function described in [ITU-T G.984.3]. Red
packets are dropped immediately. Yellow packets are marked as drop eligible, and green packets
are marked as not drop eligible, according to the egress colour marking attribute.
The algorithm used to determine the colour marking is specified by the meter type attribute. If
[b-IETF RFC 4115] is used, then:
CIR4115 = CIR
EIR4115 = PIR CIR (EIR: excess information rate)
CBS4115 = CBS
EBS4115 = PBS CBS.
100
Rec. ITU-T G.988 (10/2012)
Relationships
This ME is associated with a GEM port network CTP or a MAC bridge port configuration
data managed entity.
Attributes
CIR:
This attribute specifies the committed information rate, in byte/s. The default
is 0. (R, W, Set-by-create) (optional) (4 bytes)
PIR:
This attribute specifies the peak information rate, in byte/s. The default value
0 accepts the ONU's factory policy. (R, W, Set-by-create) (optional) (4 bytes)
CBS:
This attribute specifies the committed burst size, in bytes. The default is 0.
(R, W, Set-by-create) (optional) (4 bytes)
PBS:
This attribute specifies the peak burst size, in bytes. The default value 0
accepts the ONU's factory policy. (R, W, Set-by-create) (optional) (4 bytes)
Colour mode: This attribute specifies whether the colour marking algorithm considers preexisting marking on ingress packets (colour-aware) or ignores it (colourblind). In colour-aware mode, packets can only be demoted (from green to
yellow or red, or from yellow to red). The default value is 0.
0 Colour-blind
1 Colour-aware
(R, W, Set-by-create) (optional) (1 byte)
Ingress colour marking: This attribute is meaningful in colour-aware mode. It identifies
how pre-existing drop precedence is marked on ingress packets. For DEI and
PCP marking, a drop eligible indicator is equivalent to yellow; otherwise, the
colour is green. For DSCP AF marking, the lowest drop precedence is
equivalent to green; otherwise, the colour is yellow. The default value is 0.
0 No marking (ignore ingress marking)
Egress colour marking: This attribute specifies how drop precedence is to be marked by
the ONU on egress packets. If set to internal marking only, the externally
visible packet contents are not modified, but the packet is identified in a
vendor-specific local way that indicates its colour to the priority queue ME. It
is possible for the egress marking to differ from the ingress marking; for
example, ingress PCP marking could be translated to DEI egress marking.
The default value is 0.
0 No marking
1 Internal marking only
Rec. ITU-T G.988 (10/2012)
101

Meter type:
This attribute specifies the algorithm used to determine the colour of the
packet. The default value is 0.
0 Not specified
1 [b-IETF RFC 4115]
2 [b-IETF RFC 2698]
(R, Set-by-create) (optional) (1 byte)
Actions
Notifications
None.
9.2.13 GEM port network CTP performance monitoring history data
This managed entity collects GEM frame performance monitoring data associated with a GEM port
network CTP. Instances of this managed entity are created and deleted by the OLT.
NOTE 1 One might expect to find some form of impaired or discarded frame count associated with a GEM
port. However, the only impairment that might be detected at the GEM frame level would be a corrupted
GEM frame header. In this case, no part of the header could be considered reliable including the port ID. For
this reason, there is no impaired or discarded frame count in this ME.
NOTE 2 This managed entity replaces the GEM port performance history data managed entity and is
preferred for new implementations.

Relationships
An instance of this managed entity is associated with an instance of the GEM port network
CTP managed entity.
Attributes
instance of the GEM port network CTP. (R, Set-by-create) (mandatory)
(2 bytes)
Transmitted GEM frames: This attribute counts GEM frames transmitted on the
monitored GEM port. (R) (mandatory) (4 bytes)
Received GEM frames: This attribute counts GEM frames received correctly on the
monitored GEM port. A correctly received GEM frame is one that does not
contain uncorrectable errors and has a valid HEC. (R) (mandatory) (4 bytes)
102
Rec. ITU-T G.988 (10/2012)
Received payload bytes: This attribute counts user payload bytes received on the monitored
GEM port. (R) (mandatory) (8 bytes)
Transmitted payload bytes: This attribute counts user payload bytes transmitted on the
monitored GEM port. (R) (mandatory) (8 bytes)
Encryption key errors: This attribute is defined in ITU-T G.987 systems only. It counts
GEM frames with erroneous encryption key indexes. If the GEM port is not
encrypted, this attribute counts any frame with a key index not equal to 0. If
the GEM port is encrypted, this attribute counts any frame whose key index
specifies a key that is not known to the ONU. (R) (optional) (4 bytes)
NOTE 3 GEM PM ignores idle GEM frames.
NOTE 4 GEM PM counts each non-idle GEM frame, whether it contains an entire user frame or only a
fragment of a user frame.
Actions
Notifications
Alarm
number
1
Encryption key errors
9.2.14 Energy consumption performance monitoring history data

This managed entity collects performance monitoring data associated with the ONU's energy
consumption. The time spent in various low power states is recorded as a measure of their utility.
Furthermore, the ONU may also include the equivalent of a Watt-hour meter, which can be sampled
from time to time to measure actual power consumed.
Relationships
An instance of this managed entity is associated with the ONU in its entirety.
Attributes
The ME ID must be 0. (R, Set-by-create) (mandatory) (2 bytes)
Threshold data 1/2 ID: No thresholds are defined for this managed entity. For uniformity
with other PM, the attribute is retained and shown as mandatory, but it should
be set to a null pointer. (R, W, Set-by-create) (mandatory) (2 bytes)
Doze time:
This attribute records the time during which the ONU was in doze energy
conservation mode, measured in microseconds. (R) (mandatory) (4 bytes)
Rec. ITU-T G.988 (10/2012)
103
Cyclic sleep time: This attribute records the time during which the ONU was in cyclic sleep
energy conservation mode, measured in microseconds. (R) (mandatory)
(4 bytes)
Energy consumed: This attribute records the energy consumed by the ONU, measured in
millijoules. (R) (optional) (4 bytes)
Actions
Notifications
None.
9.2.15 XG-PON TC performance monitoring history data
This managed entity collects performance monitoring data associated with the XG-PON
transmission convergence layer, as defined in [ITU-T G.987.3].
Relationships
An instance of this managed entity is associated with an ANI-G.
Attributes
PSBd HEC error count: This attribute counts HEC errors in any of the fields of the
downstream physical sync block. (R) (optional) (4 bytes)
XGTC HEC error count: This attribute counts HEC errors detected in the XGTC header.
Unknown profile count: This attribute counts the number of grants received whose
specified profile was not known to the ONU. (R) (optional) (4 bytes)
Transmitted XGEM frames: This attribute counts the number of non-idle XGEM frames
transmitted. If an SDU is fragmented, each fragment is an XGEM frame and
is counted as such. (R) (mandatory) (4 bytes)
Fragment XGEM frames: This attribute counts the number of XGEM frames that
represent fragmented SDUs, as indicated by the LF bit = 0. (R) (optional)
(4 bytes)
XGEM HEC lost words count: This attribute counts the number of four-byte words lost
because of an XGEM frame HEC error. In general, all XGTC payload
following the error is lost, until the next PSBd event. (R) (optional) (4 bytes)
104
Rec. ITU-T G.988 (10/2012)
XGEM key errors: This attribute counts the number of downstream XGEM frames
received with an invalid key specification. The key may be invalid for several
reasons, among which are:
a) GEM port provisioned for clear text and key index not equal to 00,
b) no multicast key of the specified key index has been provided via the
OMCI for a multicast GEM port,
c) no unicast key of the specified key index has been successfully negotiated
(see [ITU-T G.987.3] clause 15.5 for key negotiation state machine),
d) GEM port specified to be encrypted and key index = 00,
e) key index = 11, a reserved value.
XGEM HEC error count: This attribute counts the number of instances of an XGEM
frame HEC error. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
PSBd HEC error count
XGTC HEC error count
Unknown profile count
XGEM HEC loss count
XGEM key errors
XGEM HEC error count
9.2.16 XG-PON downstream management performance monitoring history data

transmission convergence layer, as defined in [ITU-T G.987.3]. It collects counters associated with
downstream PLOAM and OMCI messages.
Relationships
Attributes
Rec. ITU-T G.988 (10/2012)
105
PLOAM MIC error count: This attribute counts MIC errors detected in downstream
PLOAM messages, either directed to this ONU or broadcast to all ONUs. (R)
Downstream PLOAM messages count: This attribute counts PLOAM messages received,
either directed to this ONU or broadcast to all ONUs. (R) (optional) (4 bytes)
Profile messages received: This attribute counts the number of profile messages received,
either directed to this ONU or broadcast to all ONUs. (R) (optional) (4 bytes)
Ranging_time messages received: This attribute counts the number of ranging_time
messages received, either directed to this ONU or broadcast to all ONUs. (R)
Deactivate_ONU-ID messages received: This attribute counts the number of
deactivate_ONU-ID messages received, either directed to this ONU or
broadcast to all ONUs. Deactivate_ONU-ID messages do not reset this
counter. (R) (optional) (4 bytes)
Disable_serial_number messages received: This attribute counts the number of
disable_serial_number messages received, whose serial number specified this
ONU. (R) (optional) (4 bytes)
Request_registration messages received: This attribute counts the number of
request_registration messages received. (R) (optional) (4 bytes)
Assign_alloc-ID messages received: This attribute counts the number of assign_alloc-ID
messages received. (R) (optional) (4 bytes)
Key_control messages received: This attribute counts the number of key_control messages
received, either directed to this ONU or broadcast to all ONUs. (R) (optional)
(4 bytes)
Sleep_allow messages received: This attribute counts the number of sleep_allow messages
received, either directed to this ONU or broadcast to all ONUs. (R) (optional)
(4 bytes)
Baseline OMCI messages received count: This attribute counts the number of OMCI
messages received in the baseline message format. (R) (optional) (4 bytes)
Extended OMCI messages received count: This attribute counts the number of OMCI
messages received in the extended message format. (R) (optional) (4 bytes)
Assign_ONU-ID messages received: This attribute counts the number of assign_ONU-ID
messages received since the last re-boot. (R) (optional) (4 bytes)
OMCI MIC error count: This attribute counts MIC errors detected in OMCI messages
directed to this ONU. (R) (optional) (4 bytes)
Actions
106
Rec. ITU-T G.988 (10/2012)
Notifications
Alarm
number
PLOAM MIC error count
OMCI MIC error count
9.2.17 XG-PON upstream management performance monitoring history data

transmission convergence layer, as defined in [ITU-T G.987.3]. It counts upstream PLOAM
messages transmitted by the ONU.
Relationships
Attributes
Upstream PLOAM message count: This attribute counts PLOAM messages transmitted
upstream, excluding acknowledge messages. (R) (optional) (4 bytes)
Serial_number_ONU message count: This attribute counts Serial_number_ONU PLOAM
messages transmitted. (R) (optional) (4 bytes)
Registration message count: This attribute counts registration PLOAM messages
transmitted. (R) (optional) (4 bytes)
Key_report message count: This attribute counts key_report PLOAM messages
Acknowledge message count: This attribute counts acknowledge PLOAM messages
transmitted. It includes all forms of acknowledgement, including those
transmitted in response to a PLOAM grant when the ONU has nothing to
send. (R) (optional) (4 bytes)
Sleep_request message count: This attribute counts sleep_request PLOAM messages
Actions
Rec. ITU-T G.988 (10/2012)
107
Notifications
None.
9.3
As outlined in Figure 9.3-1, this clause describes managed entities that support layer 2 services,
independent of the exact nature of the UNI (Ethernet, MoCA, xDSL). Possible UNIs are described
in their own clauses.
108
Rec. ITU-T G.988 (10/2012)
9.3.1: MAC bridge

service profile
Pointed to by:
GEM interworking TP
Multicast GEM interworking TP
9.3.3: MAC bridge
PM history data
9.3.9: MAC bridge

port PM history
data
Pointed to by:
(Extended) VLAN tagging operation
config data
9.3.4: MAC bridge

port config data
9.3.2: MAC bridge

configuration
data
9.3.5: MAC bridge
port designation
data
9.3.6: MAC bridge
port filter table
data
9.3.7: MAC bridge
port filter
pre-assign table
Points to:
TP
Outbound TD
Inbound TD
9.3.8: MAC bridge

port bridge table
data
9.3.11: VLAN
tagging filter
data
Ethernet frame PM
history data
9.3.30: upstream
9.3.31: downstream
9.3.32: Ethernet
frame extended
PM
9.3.19: Dot1ag
maintenance
domain
9.3.12: VLAN
tagging
operation config
data
Common
TP
Interwork
TP 0..7
UNI, IW
TP or IPv4/v6
host
9.3.13: Extended
VLAN tagging
operation config
data
UNI, IW
TP or IPv4/v6
host
9.3.14: Dot1X port

extension
package
UNI
9.3.16: Dot1X PM
history data
UNI
9.3.33: MAC bridge

port ICMPv6
process pre-assign
table
9.3.17: Radius PM
history data
9.3.18: Dot1 rate

limiter
9.3.26: Dot1ag
chassis-mgt info
9.3.10: 802.1p
mapper service
profile
9.3.21: Dot1ag
default MD level
9.3.15: Dot1X
configuration
profile
Points to:
MAC bridge service profile or
802.1p mapper service profile
3x traffic descriptors
Linked to:
N
9.3.24: Dot1ag MEP
CCM database
9.3.20: Dot1ag
maintenance
association
9.3.25: Dot1ag CFM

stack
Linked to:
N
9.3.23: Dot1ag MEP
status
9.3.29: multicast
subscriber
monitor
Points to:
MAC bridge port config data
or
9.3.22: Dot1ag MEP
Linked to:
MAC bridge port config data or
Linked to:
MAC bridge port config data or
9.3.28: multicast
subscriber
config info
N 9.3.27: Multicast
operations
profile
G.988(12)_F9.3-1
Figure 9.3-1 Managed entities that support layer 2
Rec. ITU-T G.988 (10/2012)
109
9.3.1
This managed entity models a MAC bridge in its entirety; any number of ports may be associated
with the bridge through pointers to the MAC bridge service profile managed entity. Instances of this
managed entity are created and deleted by the OLT.
Relationships
Bridge ports are modelled by MAC bridge port configuration data managed entities, any
number of which can point to a MAC bridge service profile. The real-time status of the
bridge is available from an implicitly linked MAC bridge configuration data ME.
Attributes
The first byte is the slot ID. In an integrated ONU, this value is 0. The second
byte is the bridge group ID. (R, Set-by-create) (mandatory) (2 bytes)
Spanning tree ind: The Boolean value true specifies that a spanning tree algorithm is
enabled. The value false disables (rapid) spanning tree. (R, W, Set-by-create)
Learning ind: The Boolean value true specifies that bridge learning functions are enabled.
The value false disables bridge learning. (R, W, Set-by-create) (mandatory)
(1 byte)
Port bridging ind: The Boolean value true specifies that bridging between UNI ports is
enabled. The value false disables local bridging. (R, W, Set-by-create)
Priority:
This attribute specifies the bridge priority in the range 0..65535. The value of
this attribute is copied to the bridge priority attribute of the associated MAC
bridge configuration data managed entity. (R, W, Set-by-create) (mandatory)
(2 bytes)
Max age:
This attribute specifies the maximum age (in 256ths of a second) of received
protocol information before its entry in the spanning tree listing is discarded.
The range is 0x0600 to 0x2800 (6..40 seconds) in accordance with
[IEEE 802.1D]. (R, W, Set-by-create) (mandatory) (2 bytes)
Hello time:
This attribute specifies how often (in 256ths of a second) the bridge
advertises its presence via hello packets, while acting as a root or attempting
to become a root. The range is 0x0100 to 0x0A00 (1..10 seconds). (R, W,
Set-by-create) (mandatory) (2 bytes)
NOTE [IEEE 802.1D] specifies the compatibility range for hello time to be
1..2 seconds.
Forward delay: This attribute specifies the forwarding delay (in 256ths of a second) when
the bridge acts as the root. The range is 0x0400 to 0x1E00 (4..30 seconds) in
accordance with [IEEE 802.1D]. (R, W, Set-by-create) (mandatory) (2 bytes)
Unknown MAC address discard: The Boolean value true specifies that MAC frames with
unknown destination addresses be discarded. The value false specifies that
such frames be forwarded to all allowed ports. (R, W, Set-by-create)
MAC learning depth: This attribute specifies the maximum number of UNI MAC
addresses to be learned by the bridge. The default value 0 specifies that there
is no administratively-imposed limit. (R, W, Set-by-create) (optional)
(1 byte)
110
Rec. ITU-T G.988 (10/2012)
Dynamic filtering ageing time: This attribute specifies the age of dynamic filtering entries
in the bridge database, after which unrefreshed entries are discarded. In
accordance with [IEEE 802.1D] clause 7.9.2 and [IEEE 802.1Q] clause 8.8.3,
the range is 10..1 000 000 seconds, with a resolution of 1 second and a
default of 300 seconds. The value 0 specifies that the ONU use its internal
default. (R, W, Set-by-create) (optional) (4 bytes)
Actions
Notifications
None.
9.3.2
This managed entity organizes status data associated with a MAC bridge. The ONU automatically
creates or deletes an instance of this managed entity upon the creation or deletion of a MAC bridge
service profile.
Relationships
This managed entity is associated with one instance of a MAC bridge service profile.
Attributes
instance of the MAC bridge service profile. (R) (mandatory) (2 bytes)
Bridge MAC address: This attribute indicates the MAC address used by the bridge. The
ONU sets this attribute to a value based on criteria beyond the scope of this
Recommendation, for example, factory settings. (R) (mandatory) (6 bytes)
Bridge priority: This attribute reports the priority of the bridge. The ONU copies this
attribute from the priority attribute of the associated MAC bridge service
profile. The value of this attribute changes with updates to the MAC bridge
service profile priority attribute. (R) (mandatory) (2 bytes)
Designated root: This attribute identifies the bridge at the root of the spanning tree. It
comprises bridge priority (2 bytes) and MAC address (6 bytes). (R)
Root path cost: This attribute reports the cost of the best path to the root as seen from this
bridge. Upon ME instantiation, the ONU sets this attribute to 0. (R)
Bridge port count: This attribute records the number of ports linked to this bridge. (R)
Root port num: This attribute contains the port number that has the lowest cost from the
bridge to the root bridge. The value 0 means that this bridge is itself the root.
Upon ME instantiation, the ONU sets this attribute to 0. (R) (mandatory)
(2 bytes)
Hello time:
This attribute is the hello time received from the designated root, the interval
(in 256ths of a second) between HELLO packets. Its range is 0x0100 to
0x0A00 (1..10 seconds). (R) (optional) (2 bytes)
NOTE [IEEE 802.1D] specifies the compatibility range for hello time to be
1..2 seconds.
Rec. ITU-T G.988 (10/2012)
111
Forward delay: This attribute is the forwarding delay time received from the designated
root (in 256ths of a second). Its range is 0x0400 to 0x1E00 (4..30 seconds) in
accordance with [IEEE 802.1D]. (R) (optional) (2 bytes)
Actions
Get
Notifications
None.
9.3.3
MAC bridge performance monitoring history data
This managed entity collects performance monitoring data associated with a MAC bridge. Instances
Relationships
This managed entity is associated with an instance of a MAC bridge service profile.
Attributes
instance of the MAC bridge service profile. (R, Set-by-create) (mandatory)
(2 bytes)
number exceeds 7, a threshold data 2 ME is optional. Since no threshold
value attribute number exceeds 7, a threshold data 2 ME is optional. (R, W,
Bridge learning entry discard count: This attribute counts forwarding database entries that
have been or would have been learned but were discarded or replaced due to
a lack of space in the database table. When used with the MAC learning
depth attribute of the MAC bridge service profile, the bridge learning entry
discard count may be particularly useful in detecting MAC spoofing
attempts. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
0

Bridge learning entry discard

1
112
Rec. ITU-T G.988 (10/2012)
9.3.4
MAC bridge port configuration data
This managed entity models a port on a MAC bridge. Instances of this managed entity are created
and deleted by the OLT.
Relationships
An instance of this managed entity is linked to an instance of the MAC bridge service
profile. Additional bridge port control capabilities are provided by implicitly linked
instances of some or all of:
MAC bridge port filter pre-assign table
Dot1 rate limiter.
Real-time status of the bridge port is provided by implicitly linked instances of:
MAC bridge port designation data
MAC bridge port bridge table data
Multicast subscriber monitor.
Bridge port PM collection is provided by implicitly linked instances of:
MAC bridge port PM history data
Ethernet frame PM history data upstream and downstream
Ethernet frame extended PM (preferred).
Attributes
Bridge ID pointer: This attribute points to an instance of the MAC bridge service profile.
Port num:
This attribute is the bridge port number. It must be unique among all ports
associated with a particular MAC bridge service profile. (R, W,
Set-by-create) (mandatory) (1 byte)
TP type:
This attribute identifies the type of termination point associated with this
MAC bridge port. Valid values are:
1 Physical path termination point Ethernet UNI
2 Interworking VCC termination point
3 IEEE 802.1p mapper service profile
4 IP host config data or IPv6 host config data
5 GEM interworking termination point
6 Multicast GEM interworking termination point
7 Physical path termination point xDSL UNI part 1
8 Physical path termination point VDSL UNI
9 Ethernet flow termination point
10 Reserved
11 Virtual Ethernet interface point
12 Physical path termination point MoCA UNI
Rec. ITU-T G.988 (10/2012)
113
TP pointer:
This attribute points to the termination point associated with this MAC bridge
port. The TP type attribute indicates the type of the termination point; this
attribute contains its instance identifier (ME ID). (R, W, Set-by-create)
NOTE 1 When the TP type is VDSL or xDSL, the two most significant bits may
be used to indicate a bearer channel.
Port priority: This attribute denotes the priority of the port for use in (rapid) spanning tree
algorithms. The range is 0..255. (R, W, Set-by-create) (optional) (2 bytes)
Port path cost: This attribute specifies the contribution of the port to the path cost towards
the spanning tree root bridge. The range is 1..65535. (R, W, Set-by-create)
Port spanning tree ind: The Boolean value true enables (R)STP LAN topology change
detection at this port. The value false disables topology change detection.
Deprecated 1: This attribute is not used. If present, it should be ignored by both the ONU
and the OLT, except as necessary to comply with OMCI message definitions.
Deprecated 2: This attribute is not used. If present, it should be ignored by both the ONU
and the OLT, except as necessary to comply with OMCI message definitions.
(R, W, Set-by-create) (1 byte) (optional)
Port MAC address: If the termination point associated with this port has a MAC address,
this attribute specifies it. (R) (optional) (6 bytes)
Outbound TD pointer: This attribute points to a traffic descriptor that limits the traffic rate
leaving the MAC bridge. (R, W) (optional) (2 byte)
Inbound TD pointer: This attribute points to a traffic descriptor that limits the traffic rate
entering the MAC bridge. (R, W) (optional) (2 byte)
MAC learning depth: This attribute specifies the maximum number of MAC addresses to
be learned by this MAC bridge port. The default value 0 specifies that there
is no administratively-imposed limit. (R, W, Set-by-create) (optional)
(1 byte)
NOTE 2 If this attribute is not zero, its value overrides the value set in the MAC
learning depth attribute of the MAC bridge service profile.
Actions
Notifications
Alarm
Alarm
number
0
1..207
208..223
Alarm
Port blocking
Description
This port has been blocked due to loop detection in
accordance with [IEEE 802.1D] (Note).
Reserved
NOTE To determine the state of a MAC bridge port, the OLT can read the port state attribute of
the MAC bridge port designation data.
114
Rec. ITU-T G.988 (10/2012)
9.3.5
This managed entity records data associated with a bridge port. The ONU automatically creates or
deletes an instance of this managed entity upon the creation or deletion of a MAC bridge port
configuration data ME.
Relationships
An instance of this managed entity is associated with one MAC bridge port configuration
data ME.
Attributes
instance of the MAC bridge port configuration data. (R) (mandatory)
(2 bytes)
Designated bridge root cost port: This attribute contains the designated root, designated
cost, designated bridge and designated port, which are some of the outputs of
the read port parameters operation defined in clause 14.8.2.1 of
[IEEE 802.1D]:
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).

(24 bytes)
Port state:
This attribute provides status information on the port. Valid values include:
0 Disabled
1 Listening
2 Learning
3 Forwarding
4 Blocking
5 Linkdown
6 (R)Stp_off
in accordance with [IEEE 802.1D]. (R) (mandatory) (1 byte)
NOTE The value linkdown is introduced to denote the port status when the
Ethernet link state is down. This value distinguishes the case where Ethernet is
physically down from the case where Ethernet is administratively locked, the latter
being denoted by disabled. Be aware that this terminology violates the ITU-T
convention that disabled is an operational state, not administrative.
The value (R)stp_off is introduced to denote the port status where the (rapid)
spanning tree protocol has been disabled by setting the port spanning tree ind
attribute of the MAC bridge port configuration data to false, and the Ethernet link
state is up. This value distinguishes whether or not frame forwarding is under the
control of (R)STP.
Actions
Get
Rec. ITU-T G.988 (10/2012)
115
Notifications
None.
9.3.6
This managed entity organizes data associated with a bridge port. The ONU automatically creates
or deletes an instance of this managed entity upon the creation or deletion of a MAC bridge port
configuration data managed entity.
NOTE The OLT should disable the learning mode in the MAC bridge service profile before writing to the
MAC filter table.
Relationships
An instance of this managed entity is associated with an instance of a MAC bridge port
Attributes
instance of the MAC bridge port configuration data ME. (R) (mandatory)
(2 bytes)
MAC filter table: This attribute lists MAC addresses associated with the bridge port, each
with an allow/disallow forwarding indicator for traffic flowing out of the
bridge port. Additionally, the forwarding action may be based on a MAC
source or destination address. In this way, upstream traffic is filtered on ANIside bridge ports, and downstream traffic is filtered on UNI-side bridge ports.
The setting of an entry with a forward action implies that all other addresses
are filtered. Conversely, the setting of an entry with a filter action implies
that all other addresses are forwarded. The behaviour is unspecified if
forward and filter actions are mixed.
Each entry contains:
the entry number, an index into this attribute list (1 byte)
filter byte (1 byte)
MAC address (6 bytes).
The bits of the filter byte are assigned as follows:
Bit
Name
Setting
1 (LSB) Filter/forward
0: forward
1: filter
2
0: MAC destination addresses

1: MAC source addresses
3..6
Reserved
7..8
Add/remove
10: Clear entire table (set operation)

00: Remove this entry (set operation)
01: Add this entry
Upon ME instantiation, the ONU sets this attribute to an empty table.

(R, W) (Mandatory) (8N bytes, where N is the number of entries in the list)
116
Rec. ITU-T G.988 (10/2012)
Actions
Get, get next, set
Notifications
None.
9.3.7
This managed entity provides an alternate approach to destination address filtering from that
supported through the MAC bridge port filter table data ME. This alternate approach is useful when
all groups of addresses are stored beforehand in the ONU, and the MAC bridge port filter pre-assign
table managed entity designates which groups are valid or invalid for filtering. On a circuit pack in
which all groups of addresses are pre-assigned and stored locally, the ONU creates or deletes an
instance of this managed entity automatically upon creation or deletion of a MAC bridge port
Relationships
Attributes
(2 bytes)
The following ten attributes have similar definitions. Each permits the OLT to specify whether
MAC destination addresses or Ethertypes of the named type are forwarded (0) or filtered (1). In
each case, the initial value of the attribute is 0.
#
Protocol
MAC address
Ethertype
IPv4 multicast
01.00.5E.00.00.00
01.00.5E.7F.FF.FF
[b-IETF RFC 3232]
IPv6 multicast
(Note)
33.33.00.00.00.00
33.33.FF.FF.FF.FF
[IETF RFC 2464]
IPv4 broadcast
FF.FF.FF.FF.FF.FF
0x0800
[b-IETF RFC 3232]
RARP
FF.FF.FF.FF.FF.FF
0x8035
[b-IETF RFC 3232]
IPX
FF.FF.FF.FF.FF.FF
0x8137
[b-IETF RFC 3232]
09.00.1B.FF.FF.FF,
09.00.4E.00.00.02
NetBEUI
03.00.00.00.00.01
AppleTalk
FF.FF.FF.FF.FF.FF
0x809B,
0x80F3
09.00.07.00.00.00
09.00.07.00.00.FC,
09.00.07.FF.FF.FF
01.80.C2.00.00.00
Bridge
management
Standard
[b-IETF RFC 3232]
[IEEE 802.1D]
Rec. ITU-T G.988 (10/2012)
117
information
01.80.C2.00.00.FF
ARP
FF.FF.FF.FF.FF.FF
0x0806
[b-IETF RFC 3232]
10
PPPoE broadcast
FF.FF.FF.FF.FF.FF
0x8863
[b-IETF RFC 2516]
NOTE The specified MAC address range does not distinguish network control traffic
from user traffic. The dot1 rate limiter may be a preferable way to limit the flow of
IPv6 multicast traffic.
IPv4 multicast filtering:
IPv6 multicast filtering:
IPv4 broadcast filtering:
RARP filtering:
IPX filtering:
NetBEUI filtering:
AppleTalk filtering:
Bridge management information filtering:
Note that some destination MAC addresses should never be forwarded,

considering the following rules of [IEEE 802.1D]:
1 Addresses from 01.80.C2.00.00.00 to 01.80.C2.00.00.0F are reserved.
2 Addresses from 01.80.C2.00.00.20 to 01.80.C2.00.00.2F are used for
GARP applications.
ARP filtering:
PPPoE broadcast filtering:
Actions
Get, set
Notifications
None.
9.3.8
This managed entity reports status data associated with a bridge port. The ONU automatically
creates or deletes an instance of this managed entity upon the creation or deletion of a MAC bridge
port configuration data.
Relationships
Attributes
(2 bytes)
Bridge table: This attribute lists known MAC destination addresses, whether they are
learned or statically assigned, whether packets which have them as
destination addresses are filtered or forwarded, and their ages. Each entry
contains:
118
Rec. ITU-T G.988 (10/2012)
Information (2 bytes)
MAC address (6 bytes)
The information bits are assigned as described below:

Bit
Name
Setting
1 (LSB) Filter/forward
0: forward
1: filter
2
Reserved
0
3
Dynamic/static 0: this entry is statically assigned
1: this entry is dynamically learned
4
Reserved
0
16..5
Age
Age in seconds (1..4095)
Upon ME instantiation, this attribute is an empty list. (R) (mandatory)
(8 * M bytes, where M is the number of entries in the list.)
Actions
Get, get next
Notifications
None.
9.3.9
MAC bridge port performance monitoring history data
This managed entity collects performance monitoring data associated with a MAC bridge port.
Relationships
Attributes
instance of the MAC bridge port configuration data ME. (R, Set-by-create)
Forwarded frame counter: This attribute counts frames transmitted successfully on this
port. (R) (mandatory) (4 bytes)
Delay exceeded discard counter: This attribute counts frames discarded on this port
because transmission was delayed. (R) (mandatory) (4 bytes)
MTU exceeded discard counter: This attribute counts frames discarded on this port
because the MTU was exceeded. (R) (mandatory) (4 bytes)
Received frame counter: This attribute counts frames received on this port. (R)
Rec. ITU-T G.988 (10/2012)
119
Received and discarded counter: This attribute counts frames received on this port that
were discarded due to errors. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
Threshold crossing
alert
Delay exceeded discard
MTU exceeded discard
Received and discarded
9.3.10 IEEE 802.1p mapper service profile

This managed entity associates the priorities of IEEE 802.1p [IEEE 802.1D] priority tagged frames
with specific connections. This managed entity directs upstream traffic to the designated GEM
ports. Downstream traffic arriving on any of the IEEE 802.1p mapper's GEM ports is directed to the
mapper's root termination point. Other mechanisms exist to direct downstream traffic, specifically a
direct pointer to a downstream queue from the GEM port network CTP. If such an alternative is
used, it should be provisioned to be consistent with the flow model of the mapper.
Relationships
At its root, an instance of this ME may be associated with zero or one instance of a PPTP
UNI, MAC bridge port configuration data, or any type of interworking termination point
ME that carries IEEE 802 traffic. Each of its eight branches is associated with zero or one
GEM interworking termination point.
Attributes
TP pointer:
This attribute points to an instance of the associated termination point.

If the optional TP type attribute is not supported, the TP pointer indicates
bridging mapping with the value 0xFFFF; the TP pointer may also point to a
PPTP Ethernet UNI.
The TP type value 0 also indicates bridging mapping, and the TP pointer
should be set to 0xFFFF.
In all other cases, the termination point type is determined by the TP type
attribute.
120
Rec. ITU-T G.988 (10/2012)
Each of the following eight attributes points to the GEM interworking termination point associated
with the stated P-bit value. The null pointer 0xFFFF specifies that frames with the associated
priority are to be discarded.
Interwork TP pointer for P-bit priority 0: (R, W, Set-by-create) (mandatory) (2 bytes)
Unmarked frame option: This attribute specifies how the ONU should handle untagged
Ethernet frames received across the associated interface. Although it does not
alter the frame in any way, the ONU routes the frame as if it were tagged
with P bits (PCP field) according to the following code points:
0 Derive implied PCP field from DSCP bits of received frame
1 Set implied PCP field to a fixed value specified by the default P-bit
assumption attribute
Untagged downstream frames are passed through the mapper transparently.
DSCP to P-bit mapping: This attribute is valid when the unmarked frame option attribute is
set to 0. The DSCP to P-bit attribute can be considered a bit string sequence
of 64 three-bit groupings. The 64 sequence entries represent the possible
values of the six-bit DSCP field. Each three-bit grouping specifies the P-bit
value to which the associated DSCP value should be mapped. The unmarked
frame is then directed to the GEM interworking termination point indicated
by the interwork TP pointer mappings. (R, W) (mandatory) (24 bytes)
NOTE If certain bits in the DSCP field are to be ignored in the mapping process,
the attribute should be provisioned such that all possible values of those bits produce
the same P-bit mapping. This can be applied to the case where instead of full DSCP,
the operator wishes to adopt the priority mechanism based on IP precedence, which
needs only the three most significant bits of the DSCP field.
Default P-bit assumption: This attribute is valid when the unmarked frame option attribute
is set to 1. In its least significant bits, the default P-bit assumption attribute
contains the default PCP field to be assumed. The unmodified frame is then
directed to the GEM interworking termination point indicated by the
interwork TP pointer mappings. (R, W, Set-by-create) (mandatory) (1 byte)
TP type:
This attribute identifies the type of termination point associated with the
mapper.
0 Mapper used for bridging-mapping
1 Mapper directly associated with a PPTP Ethernet UNI
2 Mapper directly associated with an IP host config data or IPv6 host
config data ME
Rec. ITU-T G.988 (10/2012)
121
3 Mapper directly associated with an Ethernet flow termination point

4 Mapper directly associated with a PPTP xDSL UNI
5 Reserved
6 Mapper directly associated with a PPTP MoCA UNI
7 Mapper directly associated with a virtual Ethernet interface point
8 Mapper directly associated with an interworking VCC termination
point
Actions
Notifications
None.
9.3.11 VLAN tagging filter data
This managed entity organizes data associated with VLAN tagging. Instances of this managed
Relationships
configuration data managed entity. By definition, tag filtering occurs closer to the MAC
bridge than the tagging operation. Schematically, the ordering of the functions is:
ANI
Tag operation
Tag filtering
Bridging
Tag filtering
Tag operation
UNI
G.988(12)_F9.3.11-1
Figure 9.3.11-1
Attributes
instance of the MAC bridge port configuration data ME. (R, Set-by-create)
VLAN filter list: This attribute is a list of provisioned TCI values for the bridge port. A
TCI, comprising user priority, CFI and VID, is represented by 2 bytes. This
attribute supports up to 12 VLAN entries. The first N are valid, where N is
given by the number of entries attribute. (R, W, Set-by-create) (mandatory)
(24 bytes)
Forward operation: When a frame passes through the MAC bridge port, it is processed
according to the operation specified by this attribute, in accordance with
Table 9.3.11-1. Figure 9.3.11-3 illustrates the treatment of frames according
to the provisioned action possibilities. Tagged and untagged frames are
treated separately, but both in accordance with the figure. While all
forwarding operations are plausible, only actions 0x10 and 0x12 are
necessary to construct a VLAN mapper and an 802.1p mapper, respectively.
122
Rec. ITU-T G.988 (10/2012)
Table 9.3.11-1 Forward operation attribute values

Type of received frame
Forward
operation
Tagged
Untagged
0x00
Bridging (a) (no investigation)
Bridging (a)
0x01
Discarding (c)
Bridging (a)
0x02
Discarding (c)
0x03
Action (h) (VID investigation)
Bridging (a)
0x04
Discarding (c)
0x05
Action (g) (VID investigation)
Bridging (a)
0x06
Action (g) (VID investigation)
Discarding (c)
0x07
Action (h) (user priority investigation)
Bridging (a)
0x08
Discarding (c)
0x09
Action (g) (user priority investigation)
Bridging (a)
0x0A
Action (g) (user priority investigation)
Discarding (c)
0x0B
Action (h) (TCI investigation)
Bridging (a)
0x0C
Discarding (c)
0x0D
Action (g) (TCI investigation)
Bridging (a)
0x0E
Action (g) (TCI investigation)
Discarding (c)
0x0F
Bridging (a)
0x10
Discarding (c)
0x11
Bridging (a)
0x12
Discarding (c)
0x13
Bridging (a)
0x14
Discarding (c)
0x15
Discarding (c)
0x16
Action (j) (VID investigation)
Bridging (a)
0x17
Action (j) (VID investigation)
Discarding (c)
0x18
Action (j) (user priority investigation)
Bridging (a)
0x19
Action (j) (user priority investigation)
Discarding (c)
0x1A
Action (j) (TCI investigation)
Bridging (a)
0x1B
Action (j) (TCI investigation)
Discarding (c)
0x1C
Bridging (a)
0x1D
Discarding (c)
0x1E
Bridging (a)
0x1F
Discarding (c)
0x20
Bridging (a)
0x21
Discarding (c)
Table 9.3.11-1 contains duplicate entries due to simplification of the original

set of actions.
Table 9.3.11-1 and the actions listed are discussed in detail below.
Rec. ITU-T G.988 (10/2012)
123
Number of entries: This attribute specifies the number of valid entries in the VLAN filter
list. (R, W, Set-by-create) (mandatory) (1 byte)
Actions
Notifications
None.
Supplementary explanation
This section explains the actions specified in the forward operation attribute.
The format of an Ethernet frame for VLAN services is described in [IEEE 802.1Q] and
[IEEE 802.1ad]:
SA
Length/
type
TPID
TCI
DA
MAC SDU
User priority
802.1p
(3 bits)
CFI
(1 bit)
VID (802.1Q) VLAN ID (tag)

(12 bits)
TCI: Tag control information
G.988(12)_F9.3.11-2
Figure 9.3.11-2 Format of an Ethernet frame for VLAN services

a) Basic MAC bridge operation: All frames are accepted into the MAC bridging entity.
Egress frames are forwarded from this port if either a) the frame's MAC destination
address (DA) is listed in the MAC bridge port bridge table data for this port or b) the
frame's DA does not appear in the MAC bridge port bridge table data for any port
(flooding). The contents of the VLAN filter list attribute are not meaningful.
NOTE Action (a) on a given port may imply egress flooding of a frame from other ports of
the bridge. The possible VLAN tagging filter data MEs attached to the other ports override this
action however, so the frame is only transmitted from another port if it also satisfies the
forward operation attribute value established on that port.
124
Rec. ITU-T G.988 (10/2012)
All frames accepted

DA match or flooded frames only
Action a: accept
VLAN filter list
= dont care
Port P1
802.1 bridging entity
Modelled in OMCI as
All frames discarded, both ways
(based on tag presence/absence,
but not tag value)
Functionality of
(extended) VLAN
tagging operation
configuration data
MEs, if any
Action c: discard
VLAN filter list
= dont care

P2
Only frames whose TCI does not match

DA match or flood
Only frames whose TCI matches
Only frames whose TCI matches and
(DA match or flooding)
All frames accepted
Only frames whose TCI and DA match
No flooding
Action g:
P3
discard on TCI
Action h:
accept on TCI, P4
else discard
Action j:
accept on TCI, P5
else discard
G.988(12)_F9.3.11-3
Figure 9.3.11-3 Forwarding behaviour

Other possible actions are as follows:
c) Unconditional discarding: Frames in both directions are unconditionally discarded
without an investigation of TCI or a MAC address. This action can be used to discard
all tagged traffic or all untagged traffic at the port of attachment, depending on the
forward operation attribute value. The contents of the VLAN filter list attribute are not
meaningful.
g) Negative filtering by TCI: All frames are admitted into the bridging entity. If the
specified fields in the TCI of a candidate egress frame match any entry in the VLAN
filter list, the frame is not forwarded by this port. Otherwise, the frame is forwarded
based on the destination MAC address, according to action (a).
h) Bidirectional positive filtering by TCI: Both ingress and egress frames are filtered on
investigation of the TCI fields. If and only if the specified fields in the TCI of a
candidate ingress frame match an entry in the VLAN filter list, the frame is admitted
into the bridge. If, and only if the specified fields in the TCI of a candidate egress frame
match an entry in the VLAN filter list, the frame is forwarded based on the destination
MAC address, according to action (a).
j) Positive filtering by TCI and DA: All frames are admitted into the bridging entity. If
the specified fields in the TCI of a candidate egress frame match any entry in the
VLAN filter list, the frame is forwarded based on the destination MAC address. The
frame is never flooded to this or other ports. If the specified TCI fields and DA do not
both match, the frame is discarded.
Action codes b, d, e and f are not used.
9.3.12 VLAN tagging operation configuration data
This managed entity organizes data associated with VLAN tagging. Instances of this managed
NOTE 1 The extended VLAN tagging operation configuration data of clause 9.3.13 is preferred for new
implementations.
Rec. ITU-T G.988 (10/2012)
125
Relationships
Zero or one instance of this managed entity may exist for an instance of any managed entity
that can terminate or modify an Ethernet stream.
When this managed entity is associated with a UNI-side termination point, it performs its
upstream classification and tagging operations before offering the upstream frame to other
filtering, bridging or switching functions. In the downstream direction, the defined inverse
operation is the last operation performed on the frame before offering it to the UNI-side
termination.
When this managed entity is associated with an ANI-side termination point, it performs its
upstream classification and tagging operations as the last step before queueing for
transmission to the OLT, after having received the upstream frame from other filtering,
bridging or switching functions. In the downstream direction, the defined inverse operation
is the first operation performed on the frame before offering it to possible filter, bridge or
switch functions.
Attributes
When the optional association type attribute is 0 or undefined, this attribute's
value is the same as the ID of the managed entity with which this VLAN
tagging operation configuration data instance is associated, which may be
either a PPTP Ethernet UNI or an IP host config data or an IPv6 host config
data ME. Otherwise, the value of the ME ID is unconstrained except by the
need to be unique. (R, Set-by-create) (mandatory) (2 bytes)
Upstream VLAN tagging operation mode: This attribute controls upstream VLAN
tagging. Valid values are:
0 Upstream frame is sent as is, regardless of tag.
1 The upstream frame is tagged, whether or not the received frame was
tagged. A tagged frame's TCI is overwritten with the upstream VLAN tag
TCI value. An untagged frame is prepended with a tag whose values are
taken from the upstream VLAN tag TCI value attribute.
2 A tag is prepended to the upstream frame, whether or not the received
frame was tagged. If the received frame is tagged, a second tag (Q-inQ) is added to the frame. If the received frame is not tagged, a tag is
attached to the frame. The added tag is defined by the upstream
VLAN tag TCI value attribute.
Upstream VLAN tag TCI value: This attribute specifies the TCI for upstream VLAN
tagging. It is used when the upstream VLAN tagging operation mode is 1 or
2. (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream VLAN tagging operation mode: This attribute controls downstream VLAN
tagging. Valid values are:
0 Downstream frame is sent as is, regardless of tag.
1 If the received frame is tagged, the outer tag is stripped. An untagged
frame is forwarded unchanged.
Association type: This attribute specifies the type of ME that is associated with this VLAN
tagging operation configuration data ME. Values are assigned in accordance
with the following list:
126
Rec. ITU-T G.988 (10/2012)
1
2
3
4
5
6
7
8
9
10
11
12
(Default) Physical path termination point Ethernet UNI (for backward

compatibility, may also be an IP host config data ME; they must not
have the same ME ID). The associated ME instance is implicit; its
identifier is the same as that of this VLAN tagging operation
configuration data.
IP host config data or IPv6 host config data
IEEE 802.1p mapper service profile
Physical path termination point xDSL UNI
Physical path termination point MoCA UNI
Reserved
MPLS pseudowire termination point
The associated ME instance is identified by the associated ME pointer.

Associated ME pointer: When the association type attribute is non-zero, this attribute
points to the ME with which this VLAN tagging operation configuration data
ME is associated. Otherwise, this attribute is undefined, and the association is
implicit through the ME ID. (R, W, Set-by-create) (optional) (2 bytes)
NOTE 2 implicit association is retained for legacy compatibility. Explicit pointers
are preferred for new implementations.
NOTE 3 when the association type is xDSL, the two most significant bits may be
used to indicate a bearer channel.
Actions
Notifications
None.
9.3.13 Extended VLAN tagging operation configuration data
This managed entity organizes data associated with VLAN tagging. Regardless of its point of
attachment, the specified tagging operations refer to the upstream direction. Instances of this
Relationships
Zero or one instance of this managed entity may exist for an instance of any managed entity
that can terminate or modify an Ethernet stream.
When this managed entity is associated with a UNI-side termination point, it performs its
upstream classification and tagging operations before offering the upstream frame to other
filtering, bridging or switching functions. In the downstream direction, the defined inverse
operation is the last operation performed on the frame before offering it to the UNI-side
termination.
When this managed entity is associated with an ANI-side termination point, it performs its
upstream classification and tagging operations as the last step before transmission to the
OLT, after having received the upstream frame from other filtering, bridging or switching
Rec. ITU-T G.988 (10/2012)
127
functions. In the downstream direction, the defined inverse operation is the first operation
performed on the frame before offering it to possible filter, bridge or switch functions.
Attributes
Managed entity ID: This attribute provides a unique number for each instance of this
managed entity. (R, Set-by-create) (mandatory) (2 bytes)
Association type: This attribute identifies the type of the ME associated with this extended
VLAN tagging ME. Values are assigned as follows:
0 MAC bridge port configuration data
3 IP host config data or IPv6 host config data
4 Physical path termination point xDSL UNI
5 GEM interworking termination point
6 Multicast GEM interworking termination point
8 Reserved
11 MPLS pseudowire termination point
NOTE 1 If a MAC bridge is configured, code points 1, 5 and 6 are associated with
the ANI side of the MAC bridge. Code point 0 is associated with the ANI or UNI
side, depending on the location of the MAC bridge port. The other code points are
associated with the UNI side.
When the extended VLAN tagging ME is associated with the ANI side, it behaves
as an upstream egress rule, and as a downstream ingress rule when the downstream
mode attribute is equal to 0. When the extended VLAN tagging ME is associated
with the UNI side, the extended VLAN tagging ME behaves as an upstream ingress
rule, and as a downstream egress rule when the downstream mode attribute is equal
to 0.
Received frame VLAN tagging operation table max size: This attribute indicates the
maximum number of entries that can be set in the received frame VLAN
tagging operation table. (R) (mandatory) (2 bytes)
Input TPID: This attribute gives the special TPID value for operations on the input
(filtering) side of the table. Typical values include 0x88A8 and 0x9100.
Output TPID: This attribute gives the special TPID value for operations on the output
(tagging) side of the table. Typical values include 0x88A8 and 0x9100.
Downstream mode: Regardless of its association, the rules of the received frame VLAN
tagging operation table attribute pertain to upstream traffic. The downstream
mode attribute defines the tagging action to be applied to downstream frames.
In the downstream direction, the upstream default rules do not apply. For
one-to-one VLAN mappings, the inverse is trivially defined. Many-to-one
mappings are possible however, and these are treated as follows:
128
If an upstream many-to-one mapping results from multiple operation

rules producing the same ANI-side tag configuration, then the first
Rec. ITU-T G.988 (10/2012)
matching rule in the list defines the inverse operation. The meaning of
match depends on the value of the downstream mode attribute.
If the many-to-one mapping results from "don't care" fields in the

filter being replaced with provisioned fields in the ANI side tags, then
the inverse is defined to set the corresponding fields on the ANI side
to their lowest legal value.
If the upstream rule merely copies (i.e., no explicit value is specified in the
filter field) an inbound tag value to an outbound tag value, the comparison in
the downstream direction applies to all tag values. This applies separately to
the VID and P-bit fields. For example, with a downstream mode of 2 and an
upstream rule that translates the VID while carrying forward the P-bit value,
downstream frames that match the specified WAN-side VID will match any
P-bit value and will translate the VID.
0 The operation performed in the downstream direction is the inverse of
that performed in the upstream direction. Which treatment and filter
fields are used for downstream filtering and the handling of
unmatched frames are left to the implementation of the ONU.
1 Regardless of the filter rules, no operation is performed in the
downstream direction. All downstream frames are forwarded
unmodified.
2 Filter on VID and P-bit value. On a match, perform the inverse
operation on both the VID and P-bit value. If no match is found,
forward the frame unmodified.
3 Filter on VID only. On a match, perform the inverse VID operation
only; pass the P bits through. If no match is found, forward the frame
unmodified.
4 Filter on P-bit only. On a match, perform the inverse P-bit operation
only; pass the VID through. If no match is found, forward the frame
unmodified.
5 Filter on VID and P-bit value. On a match, perform the inverse
operation on both the VID and P-bit value. If no match is found,
discard the frame.
6 Filter on VID. On a match, perform the inverse operation on the VID
only; pass the P bits through. If no match is found, discard the frame.
7 Filter on P-bit only. On a match, perform the inverse P-bit operation
only; pass the VID through. If no match is found, discard the frame.
8 Regardless of the filter rules, discard all downstream traffic.
All other values are reserved. (R, W) (mandatory) (1 byte)
Received frame VLAN tagging operation table: This attribute is a table that filters and
tags upstream frames. Each entry represents a tagging rule, comprising a
filtering part (the first seven fields) and a treatment part (the last seven
fields). Each incoming upstream packet is matched against each rule in list
order. The first rule that matches the packet is selected as the active rule, and
the packet is then treated according to that rule.
There are three categories of rules: zero-tag, single-tag, and double-tag rules.
Logically, these categories are separate, and apply to their respective
incoming frame types. In other words, a single-tag rule should not apply to a
double-tagged frame, even though the single-tag rule might match the outer
tag of the double-tagged frame.
Rec. ITU-T G.988 (10/2012)
129
Single-tag rules have a filter outer priority field = 15 (indicating no external

tag), zero-tag rules have both filter priority fields = 15 (indicating no tags),
and double-tag rules have both filter priority fields set to a value that differs
from 15 (indicating two tags).
Each tagging rule is based on a remove or an add operation, where up to two
tags can be removed or added. A modify operation is applied by the
combination of remove and add.
By convention, when a single tag is added, the treatments use the inner tag
data fields. This is true even for treatments where a single tag is added to a
frame that already has a tag, i.e., added as a second tag. The outer tag data
fields are used only when two tags are added by the same rule.
The terms inner and outer only have meaning with respect to the tags that are
being filtered or added.
The first eight bytes of each entry are guaranteed to be unique, and are used
to identify table entries (list order, above, refers to a sort on the first
eight bytes). The OLT deletes a table entry by setting all of its last eight bytes
to 0xFF.
When the table is created, the ONU should autonomously predefine three
entries that list the default treatment (normal forwarding without filtering or
modification) for untagged, single tagged, and double tagged frames. As an
exception to the rule on ordered processing, these default rules are always
considered as a last resort for frames that do not match any other rule. Best
practice dictates that these entries not be deleted by the OLT; however, they
can be modified to produce the desired default behaviour.
It should be noted that downstream frame treatment is defined by the
downstream mode attribute and is not affected by the upstream default rules.
15, 4096, x, 15, 4096, x, 0, (0, 15, x, x, 15, x, x) no tags
15, 4096, x, 14, 4096, x, 0, (0, 15, x, x, 15, x, x) 1 tag
14, 4096, x, 14, 4096, x, 0, (0, 15, x, x, 15, x, x) 2 tags
NOTE 2 x is a "don't care" field and should be set to zero.
(R, W) (mandatory) (16N bytes, where N is the number of VLAN tagging

rules)
130
Rec. ITU-T G.988 (10/2012)
31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8
Word 1
Filter outer
priority
Filter outer VID
Filter
outer
TPID/DEI
Word 2
Filter inner
priority
Filter inner VID
Filter
inner
TPID/DEI
7 6
5 4
3 2
1 0
Pad (reserved)
12 bits
Filter
Ethertype
Pad (reserved)
8 bits
Treatment, tags to remove

Word 3
Word 4
Pad (reserved)
10 bits
Pad (reserved)
12 bits
Treatment
outer priority
Treatment
outer VID
Treatment
outer
TPID/DEI
Treatment
inner priority
Treatment
inner VID
Treatment
inner
TPID/DEI
G.988(12)_F9.3.13-1
Figure 9.3.13-1 Received frame VLAN tagging operation layout

Filter outer priority: (4 bits)
0..7 Filter received frames on this outer priority (P bit) value.
8
Do not filter on outer priority.
14
This is the default filter when no other two-tag rule applies.
15
This entry is not a double-tag rule; ignore all other outer tag filter
fields.
Other values: reserved.
Filter outer VID: (13 bits)
0..4094 Filter received frames on this outer VID value.
4096 Do not filter on the outer VID.
Filter outer TPID/DEI: (3 bits)
000 Do not filter on outer TPID field.
100 Outer TPID = 0x8100
101 Outer TPID = input TPID attribute value, don't care about DEI bit
110 Outer TPID = input TPID, DEI = 0
111 Outer TPID = input TPID, DEI = 1
Padding: (12 bits)
Filter inner priority: (4 bits)
0..7 Filter received frames on this inner priority value.
8
Do not filter on inner priority.
14
This is the default filter when no other one-tag rule applies.
15
This entry is a no-tag rule; ignore all other VLAN tag filter fields.
NOTE 3 The filter Ethertype field is a valid criterion.

Filter inner VID: (13 bits)
0..4094 Filter received frames on this inner VID value.
4096 Do not filter on the inner VID.
Rec. ITU-T G.988 (10/2012)
131
Filter inner TPID/DEI: (3 bits)

000 Do not filter on inner TPID field.
100 Inner TPID = 0x8100
101 Inner TPID = input TPID attribute value, don't care about DEI bit
110 Inner TPID = input TPID, DEI = 0
111 Inner TPID = input TPID, DEI = 1
Padding: (8 bits)
Filter Ethertype: (4 bits) the Ethertype value on which to filter received
frames, as listed below.
NOTE 4 This filter is recommended for use on untagged frames or
frames with priority tags only.
0
1
2
3
4
Do not filter on Ethertype.

Ethertype = 0x0800 (filter IPoE frames)
Ethertype = 0x8863 or 0x8864 (filter PPPoE frames)
Ethertype = 0x0806 (filter ARP frames)
Ethertype = 0x86DD (filter IPv6 IpoE frames)

Treatment tags to remove: (2 bits)
0..2 Remove 0, 1 or 2 tags, respectively. If one tag is specified, then the
outer tag is stripped from double-tagged frames.
3
Discard the frame. No symmetric downstream operation exists; i.e.,
this rule is ignored in the downstream direction.
Padding: (10 bits)
Treatment outer priority: (4 bits)
0..7 Add an outer tag, and insert this value as the priority in the outer
VLAN tag.
8
Add an outer tag, and copy the outer priority from the inner priority
of the received frame.
9
Add an outer tag, and copy the outer priority from the outer priority
10
Add an outer tag, and derive P bits from the DSCP field of the
incoming frame according to the DSCP to P-bit mapping attribute.
15
Do not add an outer tag.
Treatment outer VID: (13 bits)
0..4094 Use this value as the VID in the outer VLAN tag.
4096
Copy the outer VID from the inner VID of the received frame.
4097
Copy the outer VID from the outer VID of the received frame.
132
Rec. ITU-T G.988 (10/2012)
Treatment outer TPID/DEI: (3 bits)

000 Copy TPID (and DEI, if present) from the inner tag of the received
frame.
001 Copy TPID (and DEI, if present) from the outer tag of the received
frame.
010 Set TPID = output TPID attribute value, copy DEI bit from the
inner tag of the received frame
011 Set TPID = output TPID, copy DEI from the outer tag of the
received frame
100 Set TPID = 0x8100
101 Reserved
110 Set TPID = output TPID, DEI = 0
Padding: (12 bits)
Treatment inner priority: (4 bits)
0..7 Add an inner tag, and insert this value as the priority to insert in the
inner VLAN tag.
8
Add an inner tag, and copy the inner priority from the inner priority
9
Add an inner tag, and copy the inner priority from the outer priority
10
Add an inner tag, and derive P bits from the DSCP field of the
incoming frame according to the DSCP to P-bit mapping attribute.
15
Do not add an inner tag.
Treatment inner VID: (13 bits)
0..4094 Use this value as the VID in the inner VLAN tag.
4096
Copy the inner VID from the inner VID of the received frame.
4097
Copy the inner VID from the outer VID of the received frame.
Treatment inner TPID/DEI: (3 bits)
000 Copy TPID (and DEI, if present) from the inner tag of the received
frame.
001 Copy TPID (and DEI, if present) from the outer tag of the received
frame.
010 Set TPID = output TPID attribute value, copy the DEI bit from the
inner tag of the received frame.
011 Set TPID = output TPID, copy the DEI from the outer tag of the
received frame.
100 Set TPID = 0x8100
101 Reserved
Associated ME pointer: This attribute points to the ME with which this extended VLAN
tagging operation configuration data ME is associated. (R, W, Set-by-create)
NOTE 5 When the association type is xDSL, the two most significant bits may be
used to indicate a bearer channel.
Rec. ITU-T G.988 (10/2012)
133
DSCP to P-bit mapping: This attribute specifies mapping from DSCP to P bits. The
attribute can be considered a bit string sequence of 64 3-bit groups. The 64
sequence entries represent the possible values of the 6-bit DSCP field. Each
3-bit group specifies the P-bit value to which the associated DSCP value
should be mapped. (R, W) (optional) (24 bytes)
NOTE 6 If certain bits in the DSCP field are to be ignored in the mapping process,
the attribute should be provisioned such that all possible values of those bits produce
the same P-bit mapping. This can be applied to the case where instead of full DSCP,
the operator wishes to adopt the priority mechanism based on IP precedence, which
needs only the three MSBs of the DSCP field.
Actions
Notifications
None.
Table 9.3.13-1 illustrates the rule structure for many of the common VLAN tagging operations. For
brevity, the table omits columns for TPID/DEI, where the operator customizes the behaviour to a
specific service model.
Table 9.3.13-1 Common VLAN tagging operations
Filter
VID
EtherType
Tags to remove
Priority
VID
Priority
VID
Inner
Priority
Outer
VID
Inner
Priority
Outer
Treatment
Insert 1 full tag (X):

F X-F
15
4096
15
4096
15
N/A
Px
Default case, do nothing
15
4096
15
4096
15
N/A
15
N/A
Insert 2 tags (X,Y):

F Y-X-F
15
4096
15
4096
Py
Px

C-F X-C-F
15
4096
15
N/A
Px
Insert 1 tag (X), copy priority:

C-F X-C-F
15
4096
15
N/A

C-F Y-X-C-F
15
4096
Py
Px
Modify tag:
C-F X-F
15
4096
15
N/A
Px
Modify tag,
keep original priority:
C-F X-F
15
4096
15
N/A
Action type
Untagged frames
Single tagged frames
134
Rec. ITU-T G.988 (10/2012)
Table 9.3.13-1 Common VLAN tagging operations

Filter
VID
EtherType
Tags to remove
Priority
VID
Priority
VID
Inner
Priority
Outer
VID
Inner
Priority
Outer
Treatment
Modify and insert tag:

C-F Y-X-F
15
4096
Py
Px
Remove tag:
C-F F
15
4096
15
N/A
15
N/A
Insert two tags:

C-F Y-X-C-F
15
4096
Py
Px
15
4096
14
4096
15
N/A
15
N/A
Insert 1 tag (X):

S-C-F X-S-C-F
15
N/A
Px
Insert 1 tag (X),

copy external priority:
S-C-F X-S-C-F
15
N/A

S-C-F Y-X-S-C-F
Py
Px
Insert 2 tags (X,Y), copy

external and internal priority:
S-C-F Y-X-S-C-F
Modify external tag:

S-C-F X-C-F
15
N/A
Px
Modify external tag,

S-C-F X-C-F
15
N/A
Modify both tags:

S-C-F Y-X-F
Py
Px
Modify both tags,

keep original priorities:
S-C-F Y-X-F
Swap both tags:

S-C-F C-S-F
4096
4097
Remove outer tag:

S-C-F C-F
15
N/A
15
N/A
Remove both tags:

S-C-F F
15
N/A
15
N/A

S-C-F S-C-F
14
4096
14
4096
15
N/A
15
N/A
Action type
Double tagged frames
Rec. ITU-T G.988 (10/2012)
135
Table 9.3.13-2 illustrates the downstream behaviour for common deployment scenarios based on
the downstream mode code point and the upstream rule. For brevity, the table omits a column for Pbit only, but the downstream action can be inferred from the VID only column.
In cases when the inner packet tag information is not available (i.e., in cases with more than one
VID or VID+PBIT value in "VID-only" and "Both P and VID," such as "X and C" and "Px and Py
and X and Y"), only outer tag information is used in the downstream filtering rule.
136
Rec. ITU-T G.988 (10/2012)
Table 9.3.13-2 Downstream mode use case examples

Filter
Treatment
VID
Priority
4096
15
4096
15
N/A
Px
Single
tagged
Px and X
Default case, do
nothing
15
4096
15
4096
15
N/A
15
N/A
Untagged
Insert 2 tags (X,Y): F

Y-X-F
15
4096
15
4096
Py
Px
Double
tagged
X and Y
Px and Py
and X
and Y
Strip two tags

C-F X-C-F
15
4096
15
N/A
Px
Double
tagged
X and C
X and Px
and C
Strip outer tag
Insert 1 tag (X), copy

priority: C-F X-CF
15
4096
15
N/A
Double
tagged
X and C
X and C
Strip outer tag,

copy priority
onto remaining
tag

C-F Y-X-C-F
15
4096
Py
Px
Triple
tagged
X and Y
and C
Px and Py
and X
and Y
and C
Strip two outer

tags
VID
Priority
EtherType
Inner
15
VID
Priority
Outer

F X-F
VID
Priority
Upstream action
type
Inner
Tags to remove
Downstream action
Outer
Consider
only
VID only
Both P
and VID
Action
Untagged frames
Strip tag
Pass unmodified
Single tagged
frames
137
Rec. ITU-T G.988 (10/2012)
Notes

Filter
Treatment
VID
Priority
Px
15
N/A
Single
tagged
Px and X
Replace X with
C, retain Px
Py
Px
Double
tagged
X and C
X and Px
and C
Strip outer tag
15
N/A
15
N/A
Add tag, VID =

C, P = 0
Py
Px
Triple
tagged
X and Y
and C
Px and Py
and X
and Y
and C
Strip two outer

tags
4096
14
4096
15
N/A
15
N/A
Single
tagged
15
N/A
Px
Triple
tagged
X and S
and C
X and Px
and S and
C
Modify tag: C-F

X-F
15
4096
Modify tag, keep

original priority: C-F
X-F
15
4096
Modify and insert

tag: C-F Y-X-F
15
4096
Remove tag: C-F

F
15
4096
Insert two tags: C-F

Y-X-C-F
15
4096
Default case, do
nothing
15
VID
Priority
EtherType
Inner
N/A
VID
Priority
Outer
15
VID
Priority
Upstream action
type
Inner
Tags to remove
Downstream action
Outer
Consider
only
VID only
Both P
and VID
Single
tagged
Untagged
Action
Notes
Px and X
Replace X with
C, retain Px
Use treatment specified

in downstream mode
definition for the set {C}
if ambiguous
in downstream mode
definition for the set {C}
if ambiguous
Pass unmodified
Double tagged
frames
Insert 1 tag (X): S-CF X-S-C-F
138
Rec. ITU-T G.988 (10/2012)
Strip outer tag

Filter
Treatment
Downstream action
VID
EtherType
Tags to remove
Priority
VID
Priority
VID
Inner
Priority
Outer
VID
Inner
Priority
Outer
Consider
only
Insert 1 tag (X), copy

external priority: SC-F X-S-C-F
15
N/A
Triple
tagged
X and S
and C
X and S
and C
Strip outer tag,

copy priority
onto resulting
outer tag

S-C-F Y-X-S-C-F
Py
Px
Quad
tagged
X and Y
and S and
C
Px and Py
and X
and Y
and S and
C
Strip two outer

tags
Insert 2 tags (X,Y),

copy external and
internal priority: S-CF Y-X-S-C-F
Quad
tagged
X and Y
and S and
C
X and Y
and S and
C
Strip two outer

tags, copy Px,
Py onto
remaining tags
Modify external tag:

S-C-F X-C-F
15
N/A
Px
2 tags
X and C
Px and X
and C
Replace X with
S in outer tag
Modify external tag,

S-C-F X-C-F
15
N/A
2 tags
X and C
X and C
Modify outer
tag VID = S,
retain priority
Modify both tags: SC-F Y-X-F
Py
Px
2 tags
X and Y
Px and Py
and X
and Y
Upstream action
type
139
Rec. ITU-T G.988 (10/2012)
VID only
Both P
and VID
Action
Modify tags
with S, C, retain
priority
Notes

in downstream mode
definition for the sets
{S} {C} if ambiguous

Filter
Treatment
Downstream action
VID
EtherType
Tags to remove
Priority
VID
Priority
VID
Inner
Priority
Outer
VID
Inner
Priority
Outer
Consider
only
Modify both tags,

keep original
priorities: S-C-F
Y-X-F
2 tags
X and Y
X and Y
Modify tags
with Y, X,
retain priority
Swap both tags: S-CF C-S-F
4096
4097
2 tags
S and C
S and C
Swap tags
Remove outer tag: SC-F C-F
15
N/A
15
N/A
2 tags
S and C
S and C
Strip outer tag
Remove both tags: SC-F F
15
N/A
15
N/A
2 tags
S and C
S and C
Strip both tags
Default case, do
nothing S-C-F SC-F
14
4096
14
4096
15
N/A
15
N/A
2 tags
Upstream action
type
140
Rec. ITU-T G.988 (10/2012)
VID only
Both P
and VID
Action
Pass unmodified
Notes

in downstream mode
definition for the sets
{S} {C} if ambiguous
9.3.14 Dot1X port extension package

An instance of this managed entity represents a set of attributes that control a port's IEEE 802.1X
operation. It is created and deleted autonomously by the ONU upon the creation or deletion of a
PPTP that supports [IEEE 802.1X] authentication of CPE.
Relationships
An instance of this managed entity is associated with a physical path termination point that
performs IEEE 802.1X authentication of CPE (e.g., Ethernet or DSL).
Attributes
managed entity. Its value is the same as that of its associated physical path
termination point (i.e., slot and port number). (R) (mandatory) (2 bytes)
Dot1x enable: If true, this Boolean attribute forces the associated port to authenticate via
[IEEE 802.1X] as a precondition of normal service. The default value false
does not impose IEEE 802.1X authentication on the associated port. (R, W)
Action register: This attribute defines a set of actions that can be performed on the
associated port. The act of writing to the register causes the specified action.
1 Force re-authentication this opcode initiates an IEEE 802.1X
re-authentication conversation with the associated port. The port
remains in its current authorization state until the conversation
concludes.
2 Force unauthenticated this opcode initiates an IEEE 802.1X
authentication conversation whose outcome is predestined to fail,
thereby disabling normal Ethernet service on the port. The port's
provisioning is not changed, such that upon re-initialization, a new
IEEE 802.1X conversation may restore service without prejudice.
3 Force authenticated this opcode initiates an IEEE 802.1X
authentication conversation whose outcome is predestined to succeed,
thereby unconditionally enabling normal Ethernet service on the port.
The port's provisioning is not changed, such that upon reinitialization, a new IEEE 802.1X conversation is required.
(W) (mandatory) (1 byte)
Authenticator PAE state: This attribute returns the value of the port's PAE state. States are
further described in [IEEE 802.1X]. Values are coded as shown below:
0 Initialize
1 Disconnected
2 Connecting
3 Authenticating
4 Authenticated
5 Aborting
6 Held
7 Force auth
8 Force unauth
9 Restart
(R) (optional) (1 byte)
Rec. ITU-T G.988 (10/2012)
141
Backend authentication state: This attribute returns the value of the port's back-end
authentication state. States are further described in [IEEE 802.1X]. Values
are coded as shown below:
0 Request
1 Response
2 Success
3 Fail
4 Timeout
5 Idle
6 Initialize
7 Ignore
Admin controlled directions: This attribute controls the directionality of the port's
authentication requirement. The default value 0 indicates that control is
imposed in both directions. The value 1 indicates that control is imposed only
on traffic from the subscriber towards the network. (R, W) (optional) (1 byte)
Operational controlled directions: This attribute indicates the directionality of the port's
current authentication state. The value 0 indicates that control is imposed in
both directions. The value 1 indicates that control is imposed only on traffic
from the subscriber towards the network. (R) (optional) (1 byte)
Authenticator controlled port status: This attribute indicates whether the controlled port is
currently authorized (1) or unauthorized (2). (R) (optional) (1 byte)
Quiet period: This attribute specifies the interval between EAP request/identity invitations
sent to the peer. Other events such as carrier present or EAPOL start frames
from the peer may trigger an EAP request/identity frame from the ONU at
any time; this attribute controls the ONU's periodic behaviour in the absence
of these other inputs. It is expressed in seconds. (R, W) (optional) (2 bytes)
Server timeout period: This attribute specifies the time the ONU will wait for a response
from the radius server before timing out. Within this maximum interval, the
ONU may initiate several retransmissions with exponentially increasing
delay. Upon timeout, the ONU may try another radius server if there is one,
or invoke the fallback policy, if no alternate radius servers are available.
Server timeout is expressed in seconds, with a default value of 30 and a
maximum value of 65535. (R, W) (optional) (2 bytes)
Re-authentication period: This attribute records the re-authentication interval specified by
the radius authentication server. It is expressed in seconds. The attribute is
only meaningful after a port has been authenticated. (R) (optional) (2 bytes)
Re-authentication enabled: This Boolean attribute records whether the radius
authentication server has enabled re-authentication on this service (true) or
not (false). The attribute is only meaningful after a port has been
authenticated. (R) (optional) (1 byte)
Key transmission enabled: This Boolean attribute indicates whether key transmission is
enabled (true) or not (false). This feature is not required; the parameter is
listed here for completeness vis--vis [IEEE 802.1X]. (R, W) (optional)
(1 byte)
Actions
Get, set
142
Rec. ITU-T G.988 (10/2012)
Notifications
Alarm
Alarm
number
Alarm
Description
dot1x local
authentication allowed
No radius authentication server was accessible. In

accordance with local policy, the port was allowed access
without authentication.
dot1x local
authentication denied
No radius authentication server was accessible. In

accordance with local policy, the port was denied access.
2..207
208..223
Reserved
9.3.15 Dot1X configuration profile

An instance of this managed entity represents a set of attributes that control an ONU's 802.1X
operation with regard to IEEE 802 services. An instance of this managed entity is created by the
ONU if it is capable of supporting [IEEE 802.1X] authentication of CPE.
Relationships
One instance of this managed entity governs the ONU's 802.1X CPE authentication
behaviour.
Attributes
managed entity. There is at most one instance, number 0. (R) (mandatory)
(2 bytes)
Circuit ID prefix: This attribute is a pointer to a large string managed entity whose content
appears as the prefix of the NAS port ID in radius access-request messages.
The remainder of the NAS port ID field is local information (for example,
slot-port, appended by the ONU itself). The default value of this attribute is
the null pointer 0. (R, W) (mandatory) (2 bytes)
Fallback policy: When set to 1 (deny), this attribute causes IEEE 802.1X conversations to
fail when no external authentication server is accessible, such that no
Ethernet service is provided. The default value 0 causes IEEE 802.1X
conversations to succeed when no external authentication server is accessible.
Auth server 1: This attribute is a pointer to a large string managed entity that contains the
URI of the first choice radius authentication server. The value 0 indicates that
no radius authentication server is specified. (R, W) (mandatory) (2 bytes)
Shared secret auth1: This attribute is the shared secret for the first radius authentication
server. It is a null-terminated character string. (R, W) (mandatory) (25 bytes)
The following two pairs of attributes are defined in the same way:
Auth server 2:
Shared secret auth2: (R, W) (optional) (25 bytes)

Auth server 3:
Shared secret auth3: (R, W) (optional) (25 bytes)
Rec. ITU-T G.988 (10/2012)
143
OLT proxy address: This attribute indicates the IP address of a possible proxy at the OLT
for IEEE 802.1X radius messages. The default value 0.0.0.0 indicates that no
proxy is required. (R, W) (optional) (4 bytes)
Calling station ID format: Radius messages initiated by the ONU contain a calling-stationID field that is specified to be the supplicant's MAC address in upper-case
ASCII form, with bytes separated by a delimiter. This attribute permits
specification of the delimiter. (R, W) (optional) (2 bytes)
Value
Meaning
ONU's internal default
Hyphen (-) delimiter
Colon (:) delimiter
No delimiter
0x20 0x7E Use this value as the delimiter

0xF0 0xFE Vendor-specific use
Actions
Get, set
Notifications
None.
9.3.16 Dot1X performance monitoring history data
This managed entity collects performance statistics on an ONU's IEEE 802.1X CPE authentication
operation. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity may be associated with each UNI that can perform
IEEE 802.1X authentication of CPE.
Attributes
instance of a physical path termination point. (R, Set-by-create) (mandatory)
(2 bytes)
Threshold data 1/2 ID: This attribute points to an instance of the threshold data 1 and 2
managed entities that contains PM threshold values. (R, W, Set-by-create)
EAPOL frames received: This attribute counts received valid EAPOL frames of any type.
EAPOL frames transmitted: This attribute counts transmitted EAPOL frames of any type.
144
Rec. ITU-T G.988 (10/2012)
EAPOL start frames received: This attribute counts received EAPOL start frames. (R)
EAPOL logoff frames received: This attribute counts received EAPOL logoff frames. (R)
Invalid EAPOL frames received: This attribute counts received EAPOL frames in which
the frame type was not recognized. (R) (mandatory) (4 bytes)
EAP resp/id frames received: This attribute counts received EAP response frames
containing an identifier type field. (R) (mandatory) (4 bytes)
EAP response frames received: This attribute counts received EAP response frames, other
than resp/id frames. (R) (mandatory) (4 bytes)
EAP initial request frames transmitted: This attribute counts transmitted request frames
containing an identifier type field. In [IEEE 802.1X], this is also called
ReqId. (R) (mandatory) (4 bytes)
EAP request frames transmitted: This attribute counts transmitted request frames, other
than request/id frames. (R) (mandatory) (4 bytes)
EAP length error frames received: This attribute counts received EAPOL frames whose
packet body length field was invalid. (R) (mandatory) (4 bytes)
EAP success frames generated autonomously: This attribute counts EAPOL success
frames generated according to the local fallback policy because no radius
server was available. (R) (mandatory) (4 bytes)
EAP failure frames generated autonomously: This attribute counts EAPOL failure frames
generated according to the local fallback policy because no radius server was
available. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
Invalid EAPOL frames received
EAP length error frames received
10
threshold data 1/2 managed entities.
9.3.17 Radius performance monitoring history data

This managed entity collects performance statistics on an ONU's radius client, particularly as
related to its IEEE 802.1X operation.
Relationships
An instance of this managed entity is associated with an ONU.
Rec. ITU-T G.988 (10/2012)
145
Attributes
Through an identical ID (namely 0), this managed entity is implicitly linked
to an instance of a dot1X configuration profile. (R, Set-by-create)
Access-request packets transmitted: This attribute counts transmitted radius accessrequest messages, including retransmissions. (R) (mandatory) (4 bytes)
Access-request retransmission count: This attribute counts radius access-request
retransmissions. (R) (mandatory) (4 bytes)
Access-challenge packets received: This attribute counts received radius access-challenge
messages. (R) (mandatory) (4 bytes)
Access-accept packets received: This attribute counts received radius access-accept
Access-reject packets received: This attribute counts received radius access-reject
Invalid radius packets received: This attribute counts received invalid radius messages.
Actions
Notifications
Alarm
number
Retransmission count
Invalid radius packets received
9.3.18 Dot1 rate limiter

This managed entity allows rate limits to be defined for various types of upstream traffic that are
processed by IEEE 802.1 bridges or related structures.
Relationships
An instance of this managed entity may be linked to an instance of a MAC bridge service
profile or an IEEE 802.1p mapper.
146
Rec. ITU-T G.988 (10/2012)
Attributes
Parent ME pointer: This attribute points to an instance of a managed entity. The type of
managed entity is determined by the TP type attribute. (R, W, Set-by-create)
TP type:
This attribute identifies the type of termination point associated with this dot1
rate limiter. Valid values are:
1 MAC bridge service profile
Upstream unicast flood rate pointer: This attribute points to an instance of the traffic
descriptor that governs the rate of upstream unicast packets whose destination
address is unknown to the bridge. A null pointer specifies that no
administrative limit is to be imposed. (R, W, Set-by-create) (optional)
(2 bytes)
Upstream broadcast rate pointer: This attribute points to an instance of the traffic
descriptor that governs the rate of upstream broadcast packets. A null pointer
specifies that no administrative limit is to be imposed. (R, W, Set-by-create)
Upstream multicast payload rate pointer: This attribute points to an instance of the traffic
descriptor that governs the rate of upstream multicast payload packets. A null
pointer specifies that no administrative limit is to be imposed. (R, W,
Actions
Notifications
None.
9.3.19 Dot1ag maintenance domain
In [IEEE 802.1ag], a maintenance domain (MD) is a context within which CFM connectivity
verification can occur. Individual services (maintenance associations, MAs) exist within an MD. A
maintenance domain is created and deleted by the OLT. The MD managed entity is specified by
[IEEE 802.1ag ] in such a way that the same provisioning can be used for all associated systems in a
network; the OMCI definition accordingly avoids ONU-specific information such as pointers.
Relationships
Several MDs may be associated with a given bridge, at various MD levels, and a given MD
may be associated with any number of bridges.
Attributes
Managed entity ID: This attribute uniquely identifies an instance of this managed entity.
The values 0 and 0xFFFF are reserved. (R, Set-by-create) (mandatory)
(2 bytes)
MD level:
This attribute ranges from 0..7 and specifies the maintenance level of this
MD. Higher numbers have wider geographic scope. (R, W, Set-by-create)
Rec. ITU-T G.988 (10/2012)
147
MD name format: This attribute specifies one of several possible formats for the MD name
attribute. (R, W, Set-by-create) (mandatory) (1 byte)
Value
MD name format
MD name attribute
Defined in
None
No MD name present
[IEEE 802.1ag]
DNS-like name
Globally unique text string derived

from a DNS name
"
MAC addr and

UINT
MAC address, followed by a 2-octet

unsigned integer, total length 8 bytes
"
Character string
String of printable characters. This is

recommended to be the default value.
"
32
ICC-based
ITU carrier code followed by locally

assigned UMC code, 13 bytes with
trailing nulls as needed
Others
Reserved
[ITU-T Y.1731]
Annex A
MD name 1, MD name 2:These two attributes may be regarded as a 50-byte octet string
whose value is the left-justified maintenance domain name. The MD name
may or may not be a printable character string, so an octet string is the
appropriate representation. If the MD name format specifies a DNS-like
name or a character string, the string is null-terminated; otherwise, its length
is determined by the MD name format. If the MD has no name (MD name
format = 0), this attribute is undefined. Note that binary comparisons of the
MD name are made in other CFM state machines, so blanks, alphabetic case,
etc., are significant. Also, note that the maintenance domain name and the
maintenance association name must be packed (with additional bytes) into
48-byte CFM message headers. (R, W) (mandatory if MD name format is not
1) (25 bytes * 2 attributes)
MHF creation: This attribute determines whether an associated bridge creates an MHF for
this MD or not, under circumstances defined in clause 22.2.3 of [IEEE
802.1ag]. This attribute is an enumeration with the following values:
1 None
2 Default (IEEE 802.1ag term). The bridge can create MHFs on an
associated VID on any port through which the VID can pass, where:
i) there are no lower active MD levels or ii) there is an MEP at the
next lower active MD level on the port.
3 Explicit. The bridge can create MHFs on an associated VID on any
port through which the VID can pass, but only if an MEP exists at
some lower maintenance level.
Sender ID permission: This attribute determines the contents of the sender ID TLV
included in CFM messages transmitted by maintenance points controlled by
this MD. Chassis ID and management address information is available from
the dot1ag chassis-management info managed entity. The attribute is an
enumeration with the following values:
1 None: the sender ID TLV is not to be sent.
2 Chassis: the chassis ID length, chassis ID subtype, and chassis ID
fields of the sender ID TLV are to be sent, but not the management
address fields.
148
Rec. ITU-T G.988 (10/2012)
3 Manage: the management address fields of the sender ID TLV are to

be sent, but the chassis ID length is to be transmitted with the value 0,
and the chassis ID subtype, and chassis ID fields are not to be sent.
4 ChassisManage: all chassis ID and management address fields are to
be sent.
Actions
Notifications
None.
9.3.20 Dot1ag maintenance association
This managed entity models an [IEEE 802.1ag] service defined on a bridge port. A maintenance
association (MA) is a set of endpoints on opposite sides of a network, all existing at a defined
maintenance level. One of the endpoints resides on the local ONU; the others are understood to be
configured in a consistent way on external equipment. [ITU-T Y.1731] refers to the MA as a
maintenance entity group (MEG).
A maintenance association is created and deleted by the OLT.
Relationships
Any number of MAs may be associated with a given maintenance domain, or may stand on
their own without an MD. One or more MAs may be associated with a MAC bridge or an
IEEE 802.1p mapper. An MA exists at one of eight possible maintenance levels.
Attributes
(2 bytes)
MD pointer: This pointer specifies the dot1ag maintenance domain with which this MA is
associated. A null pointer specifies that the MA is not associated with an
MD. (R, W, Set-by-create) (mandatory) (2 bytes)
Short MA name format: This attribute specifies one of several possible formats for the
short MA name attribute. Value 1, the primary VLAN ID, is recommended to
be the default. (R, W, Set-by-create) (mandatory) (1 byte)
Value
Short MA name format
Short MA name attribute
Primary VID
2 octets, 12 LSBs specify primary VID, 0

if none
Character string
String of up to 45 printable characters
2-octet integer
2 octet unsigned integer
VPN ID
7 octets, as defined in [IETF RFC 2685]
Other
Reserved
Short MA name 1, Short MA name 2:

These two attributes may be regarded as an octet string whose value is the
left-justified maintenance association name. Because the MA name may or
may not be a printable character string, an octet string is the appropriate
Rec. ITU-T G.988 (10/2012)
149
representation. If the short MA name format specifies a character string, the

string is null-terminated; otherwise, its length is determined by the short MA
name format. Note that binary comparisons of the short MA name are made
in other CFM state machines, so blanks, alphabetic case, etc., are significant.
Also, note that the maintenance domain name and the maintenance
association short name must be packed (with additional bytes) into 48-byte
CFM message headers. (R, W) (mandatory) (25 bytes * 2 attributes)
CCM interval: If CCMs are enabled on an MEP, the CCM interval attribute specifies the
rate at which they are generated. The MEP also expects to receive CCMs
from each of the other MEPs in its CC database at this rate.
0: CCM transmission disabled
1: 3.33 ms
2: 10 ms
3: 100 ms
4: 1 s
5: 10 s
6: 1 min
7: 10 min
Short intervals should be used judiciously, as they can interfere with the
network's ability to handle subscriber traffic. The recommended value is 1
second. (R, W, Set-by-create) (mandatory) (1 byte)
Associated VLANs: This attribute is a list of up to 12 VLAN IDs with which this MA is
associated. Once a set of VLANs is defined, the ONU should deny operations
to other dot1ag maintenance associations or dot1ag default MD level entries
that conflict with the set membership. The all-zeros value indicates that this
MA is not associated with any VLANs. Assuming that the attribute is not 0,
the first entry is understood to be the primary VLAN. Except forwarded
LTMs, CFM messages emitted by maintenance points in this MA are tagged
with the primary VLAN ID. (R, W) (mandatory) (2 bytes/entry *
12 entries = 24 bytes)
MHF creation: This attribute determines whether the bridge creates an MHF or not, under
circumstances defined in clause 22.2.3 of [IEEE 802.1ag]. This attribute is an
enumeration with the following values:
1 None. No MHFs are created on this bridge for this MA.
2 Default (IEEE 802.1ag term). The bridge can create MHFs on this
VID on any port through which the VID can pass.
3 Explicit. The bridge can create MHFs on this VID on any port
through which the VID can pass, but only if an MEP exists at some
lower maintenance level.
4 Defer. This value causes the ONU to use the setting of the parent MD.
This is recommended to be the default value.
Sender ID permission: This attribute determines the contents of the sender ID TLV
included in CFM messages transmitted by maintenance points controlled by
this MA. This attribute is the same as that defined in the description of the
dot1ag maintenance domain managed entity, with the addition of code point
5.
1 None: the sender ID TLV is not to be sent.
150
Rec. ITU-T G.988 (10/2012)
Chassis: the chassis ID length, chassis ID subtype, and chassis ID

address fields.
be sent, but the chassis ID length is to be transmitted with a 0 value,
be sent.
5 Defer: the contents of the sender ID TLV are determined by the
corresponding maintenance domain attribute. This is recommended to
be the default value.

Actions
Notifications
None.
9.3.21 Dot1ag default MD level
The collection of the functionality called a maintenance half-function (MHF) is not explicitly
modelled as a managed entity by either [IEEE 802.1ag] or the OMCI. The ONU automatically
creates MHFs according to parameters specified in a dot1ag maintenance domain or a dot1ag
maintenance association ME; the dot1ag default MD level ME catches the corner cases not covered
by other MEs, specifically VLANs not included by any defined MA.
The dot1ag default MD level comprises a configurable table, each entry of which specifies default
MHF functionality for some set of VLANs. Once a set of VLANs is defined, operations to different
table entries or to dot1ag maintenance associations that conflict with the set membership should be
denied. In addition, catch-all attributes are defined to specify MHF functionality when there is no
match to either a table entry or an MA.
Relationships
An ONU that supports [IEEE 802.1ag] automatically creates one instance of this ME for
each MAC bridge or IEEE 802.1p mapper, depending on the ONU's provisioning model. It
should not create an instance for an IEEE 802.1p mapper that is associated with a MAC
bridge.
Attributes
instance of the MAC bridge service profile ME or an IEEE 802.1p mapper
ME. It is expected that an ONU will implement CFM on bridges or on
IEEE 802.1p mappers, but not both, depending on its provisioning model.
For precision, the reference is disambiguated by the value of the layer 2 type
pointer attribute. (R) (mandatory) (2 bytes)
Layer 2 type: This attribute specifies whether the dot1ag default MD level ME is associated
with a MAC bridge service profile (value 0) or an IEEE 802.1p mapper
(value 1). (R) (mandatory) (1 byte)
Catchall level: This attribute ranges from 0..7 and specifies the MD level of MHFs created
when no specific match is found. (R, W) (mandatory) (1 byte)
Rec. ITU-T G.988 (10/2012)
151
Catchall MHF creation: This attribute determines whether, when no more specific match is
found, the bridge creates an MHF or not. This attribute is an enumeration
with the following values:
1 None. The bridge does not create any MHFs. This is the default value.
2 Default. The bridge can create MHFs on this VID on any port through
which the VID can pass.
Catchall sender ID permission: This attribute determines the contents of the sender ID
TLV included in CFM messages transmitted by maintenance points when no
more specific match is found. This attribute is identical to that defined in the
description of the dot1ag maintenance domain managed entity (i.e., excluding
code point 5, defer). (R, W) (mandatory) (1 byte)
Default MD level table: Each entry is a vector of fields, indexed by primary VLAN ID.
Primary VLAN ID (2 bytes)
Table control: This field controls the meaning of a set operation. The 1-byte
size of this field is included in get/get-next operations, but its value is
undefined under get-next and should be ignored by the OLT. (1 byte)
1 Add record to table; overwrite existing record, if any.
2 Delete record from table.
3 Clear all entries from table. This action may affect service and should
be used judiciously.
Status: This Boolean field indicates whether this table entry is in effect (true)
or whether (false) it has been overridden by the existence of an MA for
the same VID and MD level as this table's entry, and on which an up
MEP is defined. This attribute is read-only. Space should be allocated for
it during set operations, but the value is not used. (1 byte)
Level: This field ranges from 0..7 and specifies the MD level of MHFs under
the control of this instance of the dot1ag default MD level. The additional
value 0xFF instructs the bridge to use the value in the catchall level
attribute. (1 byte)
MHF creation: This attribute determines whether the bridge creates an MHF
or not, under circumstances defined in clause 22.2.3 of [IEEE 802.1ag].
This attribute is an enumeration with the following values. (1 byte)
1 None. No MHFs are created on this bridge for this MA.
2 Default. The bridge can create MHFs on this VID on any port through
which the VID can pass.
4 Defer. This value causes the ONU to use the setting of the catchall
MHF creation attribute. This is recommended to be the default value.
Sender ID permission: This attribute determines the contents of the sender
ID TLV included in CFM messages transmitted by maintenance points
controlled by this MA. (1 byte)
152
Rec. ITU-T G.988 (10/2012)
1
2
None: the sender ID TLV is not to be sent, default.

Chassis: the chassis ID length, chassis ID subtype, and chassis ID
address fields.
be sent, but the chassis ID length is to be transmitted with a 0 value,
be sent.
5 Defer: the contents of the sender ID TLV is determined by the
catchall sender ID permission attribute.
Associated VLANs list: This field comprises a list of up to 11 additional

VLAN IDs associated with the primary VLAN, 2 bytes each. Unused
placeholders, possibly including the entire field, are set to 0. (22 bytes)
(R, W) (mandatory) (29 bytes * N entries)
Actions
Get, get next, set
Notifications
None.
9.3.22 Dot1ag MEP
This managed entity models a maintenance association end point (MEP) as defined primarily in
[IEEE 802.1ag] and secondarily in [ITU-T Y.1731]. It is created and deleted by the OLT. An MEP
exists at one of eight possible maintenance levels, and resides at the boundary of a maintenance
domain. It inherits a name, and optionally a set of associated VLANs, from its associated MA.
Relationships
One or more MEPs may be associated with a MAC bridge port or an IEEE 802.1p mapper in
the absence of a MAC bridge. An MEP is also associated with zero or more VLANs and a
maintenance association.
Attributes
Layer 2 entity pointer: Depending on the value of the layer 2 type attribute, this pointer
specifies the MAC bridge port configuration data ME or the IEEE 802.1p
mapper service profile ME with which this MEP is associated. (R, W,
Layer 2 type: This attribute specifies whether the MA is associated with a MAC bridge port
(value 0) or an IEEE 802.1p mapper (value 1). (R, W, Set-by-create)
MA pointer: This pointer specifies the maintenance association (MA) with which this
MEP is associated. (R, W, Set-by-create) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
153
MEP ID:
This attribute specifies the MEP's own identity in the MA. For a given MA,
the MEP ID must be unique throughout the network defined by the MD. The
MEP ID is defined in the range 1..8191. The value 0 indicates that no MEP
ID is (yet) configured. (R, W, Set-by-create) (mandatory) (2 bytes)
MEP control: This attribute specifies some of the overall behavioural aspects of the MEP.
It is interpreted as follows.
Bit
1 (LSB)
Interpretation when bit value = 1

Reserved
MEP generates continuity check messages, CCMs
Enable ITU-T Y.1731 server MEP function
Enable generation of Ethernet AIS
This is an up MEP, facing toward the core of the bridge. If more

than one MEP exists on a given maintenance association and on a
given bridge, all such MEPs must face the same direction.
6..8
Reserved

Primary VLAN: This attribute is a 12-bit VLAN ID. The value 0 indicates that the MEP
inherits its primary VLAN from its parent MA. CFM messages, except
forwarded LTMs, are tagged with the primary VLAN ID. If explicitly
specified, the value of this attribute must be one of the VLANs associated
with the parent MA. (R, W, Set-by-create) (mandatory) (2 bytes)
CCM and LTM priority: Ranging from 0..7, this attribute permits CCM and LTM frames
to be explicitly prioritized, which may be needed if flows are separated, e.g.,
by 802.1p priority. The priority specified in this attribute is also used in LTR
frames originated by this MEP. The value 0xFF selects the IEEE 802.1ag
default, whereby CCM and LTM frames are transmitted with the highest
Ethernet priority available. (R, W, Set-by-create) (mandatory) (1 byte)
Egress identifier: This attribute comprises 8 bytes to be included in LTMs. They allow
received LTRs to be directed to the correct originator. The attribute includes
the originator MAC address and a locally-defined identifier. If this field is 0,
the ONU uses the MEP's MAC address, with 0 as the locally-defined
identifier. (R, W, Set-by-create) (mandatory) (8 bytes)
Peer MEP IDs: This attribute lists the expected peer MEPs for CCMs, 2 bytes per MEP ID.
[IEEE 802.1ag] allows for multipoint networks, and therefore a list of peer
MEPs. This attribute allows for up to 12 peers for a given MEP, though
G-PON applications are expected to need only a single peer. Missing or
unexpected messages trigger alarm declaration after a soak interval. Unused
peer MEP slots should be set to 0. (R, W) (mandatory) (24 bytes)
154
Rec. ITU-T G.988 (10/2012)
ETH AIS control: This attribute controls the generation of Ethernet AIS frames when they
are enabled through the MEP control attribute. It is interpreted as follows:
Bit
1 (LSB)
Interpretation
Transmission period
0: once per second
1: once per minute
2..4
P-bit priority of transmitted ETH AIS frames
5..7
The maintenance level at which the client MEP exists
Reserved
(R, W, Set-by-create) (mandatory if ETH AIS is enabled) (1 byte)

Fault alarm threshold: This attribute specifies the lowest priority alarm that is allowed to
generate a fault alarm. The value 0 specifies that the ONU use its internal
default. It is defined as follows:
1 All defects generate alarms after suitable soaking, including AIS and
RDICCM.
2 Alarm generated only by one of: MACstatus, RemoteCCM,
ErrorCCM, XconCCM. This value is recommended as the default in
[IEEE 802.1ag].
3 Alarm generated only by one of: RemoteCCM, ErrorCCM,
XconCCM.
4 Alarm generated only by one of: ErrorCCM, XconCCM.
5 Alarm generated only by: XconCCM.
6 No alarms are to be reported. This setting may be useful during
configuration of services across the network when spurious alarms
could otherwise be generated.
Alarm declaration soak time: This attribute defines the defect soak time that must elapse
before the MEP declares an alarm. It is expressed in ten-millisecond units
with a range of 250 to 1000, i.e., 2.5 to 10 seconds. The default is
recommended to be 2.5 seconds. (R, W) (mandatory) (2 bytes)
Alarm clear soak time: This attribute defines the defect-free soak time that must elapse
before the MEP clears an alarm. It is expressed in ten-millisecond units with
a range of 250 to 1000, i.e., 2.5 to 10 seconds. The default is recommended to
be 10 seconds. (R, W) (mandatory) (2 bytes)
Actions
Test:
The test operation causes the MEP to originate one or more loopback
messages (LBMs) or a linktrace message (LTM) in accordance with the test
and test result message formats defined in clauses A.2 and A.3.
The linktrace test returns its results in a general purpose buffer ME, which
must have been created in advance by the OLT. (The general purpose buffer
is designated by a pointer in the test message itself.) Upon completion of the
linktrace operation, the general purpose buffer contains a sequence of LTR
entries in the order they were received:
Rec. ITU-T G.988 (10/2012)
155
Length field, 2 bytes
Length bytes
Length of LTR1
LTR: linktrace reply 1 (clause 21.9 of

[IEEE 802.1ag])
Length of LTR2
LTR: linktrace reply 2
etc.
[IEEE 802.1ag] defines the data structure for the linktrace database in detail,
but the definition is essentially the same as the LTR PDU itself. The OMCI
simply records the messages for parsing and analysis at the OLT or the EMS.
If the ONU cannot allocate enough memory for the entire list, it keeps the
most recent responses and discards the older LTRs as necessary (first
discarding LTR1, then LTR2, etc.).
Notifications
Alarm
Alarm
number
Alarm
Description
RDI CCM
RDI received in CCM from peer MEP
MAC status
Port or interface status failure at peer MEP
Remote CCM
Loss of continuity with peer MEP
Error CCM
Invalid CCMs received
Xcon CCM
CCMs received from other MAs or a lower MD level
Unexpected period
Unexpected period
AIS
Ethernet AIS received
7..207
208..223
Reserved
9.3.23 Dot1ag MEP status

This managed entity is the read-only twin of the dot1ag MEP. Its purpose is to return information
that may help in system- or network-level troubleshooting. It is automatically created and deleted
by the ONU at the time its MEP is created or deleted.
As the reporter of ephemeral information, the dot1ag MEP status ME does not retain its attribute
values across initializations and is not included in MIB uploads.
Relationships
A dot1ag MEP status ME is associated with a dot1ag MEP ME.
Attributes
instance of the dot1ag MEP ME. (R) (mandatory) (2 bytes)
MEP MAC address: This attribute records the MEP's MAC address. (R) (mandatory)
(6 bytes)
Fault notification generator state: This attribute records the current state of the MEP's
fault notification generator state machine. States are defined in clause 20.35
of [IEEE 802.1ag].
1 Reset
156
Rec. ITU-T G.988 (10/2012)
2
3
4
5
Defect
Report defect
Defect reported
Defect clearing

Highest priority defect observed: This attribute records the highest priority defect
observed since the fault notification state machine was last in reset state. In
increasing priority order, possible values are:
0 No defect observed
1 Received a CCM from a remote MEP in which the RDI bit was set
2 Received a CCM from a remote MEP in which the port status or
interface status TLV reported an error
3 No CCMs received for at least 3.5 * CCM interval from at least one
remote MEP in the MA
4 Received invalid CCMs for at least 3.5 * CCM interval
5 Received CCMs for at least 3.5 * CCM interval that could be from
another MA
Current defects: This attribute is a bit field that signals several events of interest in real
time.
Bit
Meaning when set
1 (LSB) Another MEP in the same MA is currently transmitting an
RDI.
2
A port status or interface status TLV received from another
MEP in the MA is currently indicating an error condition.
3
CCMs have not been received for at least 3.5 * CCM interval
from at least one of the expected remote MEPs.
4
Erroneous CCMs have been received for at least 3.5 * CCM
interval from at least one of the remote MEPs in this MA.
5
CCMs have been received for at least 3.5 * CCM interval
from an MEP that is not configured into the current MA.
6..8
Reserved
Last received errored CCM table: This attribute contains the most recently received CCM
that contributed to a defErrorCCM fault. If no such CCM has been received,
this attribute is null. The format of the CCM is defined in clause 21.6 of
[IEEE 802.1ag]. (R) (mandatory) (N bytes, not to exceed 128)
Last received xcon CCM table: This attribute contains the most recently received CCM
that contributed to a defXconCCM fault. If no such CCM has been received,
this attribute is null. (R) (mandatory) (N bytes, not to exceed 128)
Out of sequence CCMs count: This attribute records the number of out of sequence CCMs
received. When the counter is full, it rolls over to 0. (R) (optional) (4 bytes)
CCMs transmitted count: This attribute records the number of CCMs transmitted. It may
be used as the sequence number of transmitted CCMs. When the counter is
full, it rolls over to 0. (R) (mandatory) (4 bytes)
Unexpected LTRs count: This attribute records the number of unexpected LTRs received.
When the counter is full, it rolls over to 0. (R) (mandatory) (4 bytes)
Rec. ITU-T G.988 (10/2012)
157
LBRs transmitted count: This attribute records the number of LBRs transmitted. When the
counter is full, it rolls over to 0. (R) (mandatory) (4 bytes)
Next loopback transaction identifier: This attribute is the value of the transaction number
sent in the next LBM to be transmitted. At ONU initialization, it should be
initialized to a random value. It increments with each LBM sent, and rolls
over when full. (R) (mandatory) (4 bytes)
Next linktrace transaction identifier: This attribute is the value of the transaction number
sent in the next LTM to be transmitted. It increments with each LTM sent,
and rolls over when full. (R) (mandatory) (4 bytes)
Actions
Get, get next
Notifications
None. This managed entity does not generate AVCs because its attributes change frequently
in real time, but are generally only of interest after the corresponding MEP declares an
alarm.
9.3.24 Dot1ag MEP CCM database
This managed entity records the recent history of remote MEPs, as deduced by the local parent
MEP. Because records are of variable length, and are constantly updated, a separate attribute is
defined for each remote MEP. The dot1ag MEP CCM database is automatically created or deleted
by the ONU at the time an MEP is created or deleted.
As the reporter of ephemeral information, the dot1ag MEP CCM database ME does not retain its
attribute values across initializations and is not included in MIB uploads.
Relationships
A dot1ag MEP CCM database ME is associated with a dot1ag MEP ME.
Attributes
instance of the dot1ag MEP ME. (R) (mandatory) (2 bytes)
Each of the following RMEP database table attributes records information for one of the possible
remote MEPs. It is expected that there will be only one remote MEP per MA in G-PON
applications, but the ME is defined in a way that permits several RMEPs. The optional attributes are
instantiated by the ONU when additional remote MEPs are provisioned on the local MEP. Remote
MEP records appear in no particular order, and the order is not guaranteed to persist across ONU
initializations.
NOTE Although each attribute is shown with a single indeterminate length N, it is understood that the
length of each attribute varies in real time, and independently from the length of the other attributes.
RMEP 1 database table: (R) (mandatory) (N bytes)

RMEP 2 database table: (R) (optional) (N bytes)
158
Rec. ITU-T G.988 (10/2012)

Each attribute is a record that comprises the following fields:
RMep identifier: The MEP ID of the remote MEP. (2 bytes)
RMep state: An enumeration with the following meaning (1 byte):
1 Idle. Momentary state during reset.
2 Start. The timer has not expired since the state machine was
reset, but no valid CCM has yet been received.
3 Failed. The timer has expired since the state machine was
reset and since a valid CCM was received.
4 Ok. The timer has not expired since a valid CCM was
received.
Failed-ok time: A timestamp, the value of the local ONU's SysUpTime
at which the remote MEP state last entered either the failed or ok
state. SysUpTime is a count of 10ms intervals since ONU
initialization. The value is 0 if it has not been in either of these states
since ONU initialization. (4 bytes)
MAC address: The MAC address of the remote MEP. If no CCM has
been received from the remote MEP, this field has the value 0.
(6 bytes)
RDI: Boolean indicating whether the RDI bit in the most recently
received CCM was set. (1 byte)
Port status: The port status from the most recently received CCM, as
defined in clause 21.5.4 of [IEEE 802.1ag]. The absence of a received
port status TLV is indicated by the value 0. (1 byte)
Interface status: The interface status from the most recently received
CCM, as defined in clause 21.5.5 of [IEEE 802.1ag]. The absence of
a received interface status TLV is indicated by the value 0. (1 byte)
Sender ID TLV: This is the actual sender ID TLV from the most
recently received CCM, as defined in clause 21.5.3 of
[IEEE 802.1ag]. The absence of a received sender ID TLV is
indicated by a single byte of value 0. (M bytes)
Actions
Get, get next
Notifications
None. The MEP CCM database table attributes do not generate AVCs because they change
constantly in real time, usually in ways that are of no immediate interest.
9.3.25 Dot1ag CFM stack
This managed entity reports the maintenance status of a bridge port at any given time. An ONU that
supports [IEEE 802.1ag] functionality automatically creates an instance of the dot1ag CFM stack
ME for each MAC bridge or IEEE 802.1p mapper, depending on its provisioning model.
Rec. ITU-T G.988 (10/2012)
159
The dot1ag CFM stack also lists any VLANs and bridge ports against which configuration errors
are currently identified. The ONU should reject operations that create configuration errors.
However, these errors can arise because of operations on other MEs that are not necessarily possible
to detect during CFM configuration.
Relationships
An ONU that supports [IEEE 802.1ag] creates one instance of this ME for each MAC bridge
or IEEE 802.1p mapper, depending on its provisioning model. It should not create an
instance for an IEEE 802.1p mapper that is associated with a MAC bridge.
Attributes
instance of the MAC bridge service profile ME or an IEEE 802.1p mapper
ME. It is expected that an ONU will implement CFM on bridges or on
IEEE 802.1p mappers, but not both. For precision, the reference is
disambiguated by the value of the layer 2 type pointer attribute. (R)
Layer 2 type: This attribute specifies whether the dot1ag CFM stack is associated with a
MAC bridge service profile (value 0) or an IEEE 802.1p mapper (value 1).
MP status table: This attribute is a list of entries, each entry reporting one aspect of the
maintenance status of one port. If a port is associated with more than one
CFM maintenance entity, each is represented as a separate item in this table
attribute; a port that has no current maintenance functions is not represented
in the table (so the table may be empty). Each entry is defined as follows:
Port ID: The ME ID of the MAC bridge port config data whose information
is reported in this entry. If the layer 2 parent is an IEEE 802.1p mapper, a
null pointer. (2 bytes)
Level: The level at which the reported maintenance function exists, 0..7.
(1 byte)
Direction: The value 1 (down) or 2 (up). (1 byte)
VLAN ID: If this table entry reports a maintenance function associated with
a VLAN, this field contains the value of the primary VLAN ID. If no
VLAN is associated with this entry, this field contains the value 0.
(2 bytes)
MD: A pointer to the associated dot1ag maintenance domain ME. If no MD
is associated with this entry, a null pointer. (2 bytes)
MA: A pointer to the associated dot1ag maintenance association ME. If no
MA is associated with this entry, a null pointer. (2 bytes)
MEP ID: If this table entry reports an MEP, this field contains the value of
its MEP ID (range 1..8191). If this table entry reports an MHF, this field
contains the value 0. (2 bytes)
MAC address: The MAC address of the maintenance point. (6 bytes)
(R) (mandatory) (18N bytes)
160
Rec. ITU-T G.988 (10/2012)
Configuration error list table: This attribute is based on the [IEEE 802.1ag] configuration
error list. It is a list of entries, each entry reporting a VLAN and a bridge port
against which a configuration error has been detected. The table may be
empty at any given time. Entries are defined as follows:
VLAN ID: If this table entry reports a maintenance function associated with
a VLAN, this field contains the value of the VLAN ID in error. If no
VLAN is associated with this entry, this field contains the value 0.
(2 bytes)
Port ID: A pointer to the MAC bridge port config data whose information is
reported in this entry. If the layer 2 parent is an IEEE 802.1p mapper, a
null pointer. (2 bytes)
Detected configuration error: A bit mask with the following meanings. A
list entry exists if and only if at least one of these bits is set. Definitions
appear in clause 22.2.4 of [IEEE 802.1ag]: (1 byte)
0x01 CFM leak. MA x is associated with a specific VID list, one or
more of the VIDs in MA x can pass through the bridge port, no up
MEP is configured for MA x on the bridge port, no down MEP is
configured on any bridge port for MA x, and another MA y, at a
higher MD level than MA x, and associated with at least one of
the VID(s) also in MA x, does have an MEP configured on the
bridge port.
0x02 Conflicting VIDs. MA x is associated with a specific VID list, an
up MEP is configured on MA x on the bridge port, and another
MA y, associated with at least one of the VID(s) also in MA x,
and at the same MD level as MA x, also has an up MEP
configured on some bridge port.
0x04 Excessive levels. The number of different MD levels at which
MIPs are to be created on this port exceeds the bridge's
capabilities.
0x08 Overlapped levels. An MEP is created for one VID at one MD
level, but an MEP is also configured on another VID at that MD
level or higher, exceeding the bridge's capabilities.
Actions
Get, get next
Notifications
Number
1..2
3
4..16
Attribute value
change
Description
N/A
Config error list table
This AVC indicates that an entry in the configuration error

list table has been added or removed. It may be advisable for
the OLT to audit the configuration of related MEs.
Reserved
Rec. ITU-T G.988 (10/2012)
161
9.3.26 Dot1ag chassis-management info

This managed entity represents the system-level chassis ID and/or management address for
[IEEE 802.1ag] CFM messages, and potentially for other IEEE 802-based functions. Although
[IEEE 802.1AB] allows for several management addresses (synonyms in different formats, or with
granularity to the component level), [IEEE 802.1ag] does not provide for more than one. Nor is it
expected that an ONU would require more than one format. Accordingly, this managed entity
provides for only one.
According to sender ID permission attributes in several dot1ag managed entities, transmitted
IEEE 802.1ag CFM messages may include either or both of the chassis ID or management address
fields.[IEEE 802.1ag] requires that CCMs do not exceed 128 bytes, of which 74 are separately
allocated to other purposes; the sender ID TLV, if present, must accommodate this requirement.
The chassis info and management info must fit, with a minimum of 4 additional overhead bytes,
into the remaining 54 bytes. This limit is exploited in defining the maximum size of the managed
entity's attributes.
Relationships
If an ONU supports [IEEE 802.1ag] functionality, it automatically creates an instance of this
managed entity.
Attributes
Managed entity ID: This attribute uniquely identifies this managed entity. There is at most
one instance, whose value is 0. (R) (mandatory) (2 bytes)
Chassis ID length: The length of the chassis ID attribute (not including the chassis ID
subtype attribute), default value 0. (R, W) (mandatory) (1 byte)
Chassis ID subtype: The format of the chassis ID attribute, default value 7, as defined in
[IEEE 802.1AB]:
1
Chassis
component
A particular instance of the entPhysicalAlias object (defined in

[IETF RFC 4133]) for a chassis component.
Interface
alias
A particular instance of the ifAlias object (defined in

[IETF RFC 2863]) for an interface on the containing chassis.
Port
component
A particular instance of the entPhysicalAlias object (defined in

[IETF RFC 4133]) for a port or backplane component within
the containing chassis.
Mac address
A particular unicast source address (encoded in network byte

order and IEEE 802.3 canonical bit order), of a port on the
containing chassis as defined in [IEEE 802].
Network
address
A particular network address, encoded in network byte order,

associated with one or more ports on the containing chassis.
The first octet contains the IANA address family numbers
enumeration value for the specific address type, and octets 2 to
N contain the network address value in network byte order.
Interface
name
A particular instance of the ifName object (defined in

[IETF RFC 2863]) for an interface on the containing chassis.
Local
Locally assigned chassis ID

Chassis ID part 1, Chassis ID part 2: These two attributes may be regarded as an octet
string of up to 50 bytes whose length is given by the chassis ID length
162
Rec. ITU-T G.988 (10/2012)
attribute and whose value is the left-justified chassis ID. (R, W) (mandatory)
(25 bytes * 2 attributes)
Management address domain length: The length of the management address domain
attribute, default value 0. If this attribute has the value 0, all of the other
management address attributes are undefined. (R, W) (mandatory) (1 byte)
Management address domain 1, Management address domain 2: These two attributes
may be regarded as an octet string of up to 50 bytes whose length is given by
the management address domain length attribute and whose value is the leftjustified management address domain. The attribute is coded as an object
identifier (OID) as per [ITU-T X.690], referring to a TDomain as defined in
[IETF RFC 2579]. Typical domain values include snmpUDPDomain (from
SNMPv2-TM [IETF RFC 3417]) and snmpIeee802Domain (from SNMPIEEE 802-TM-MIB [IETF RFC 4789]). (R, W) (mandatory) (25 bytes * 2
attributes)
Management address length: The length of the management address attribute, default
value 0. (R, W) (mandatory) (1 byte)
Management address 1, Management address 2: These two attributes may be regarded as
an octet string of up to 50 bytes whose length is given by the management
address length attribute and whose value is the left-justified management
address. (R, W) (mandatory) (25 bytes * 2 attributes)
Actions
Get, set
Notifications
None.
9.3.27 Multicast operations profile
This managed entity expresses multicast policy. A multi-dwelling unit ONU may have several such
policies, which are linked to subscribers as required. Some of the attributes configure IGMP
snooping and proxy parameters, in case the defaults do not suffice, as described in
[IETF RFC 2236], [IETF RFC 3376], [IETF RFC 3810] and [IETF RFC 5519]. Instances of this
Relationships
multicast subscriber config info ME.
Attributes
(2 bytes)
IGMP version: This attribute specifies the version of IGMP to be supported. Support of a
given version implies compatible support of previous versions. If the ONU
cannot support the version requested, it should deny an attempt to set the
attribute. (R,W, Set-by-create) (mandatory) (1 byte)
1
IGMP version 1 (deprecated)
2
IGMP version 2
3
IGMP version 3
16
MLD version 1
Rec. ITU-T G.988 (10/2012)
163
17
MLD version 2
IGMP function: This attribute enables an IGMP function. The value 0 specifies transparent
IGMP snooping only. The value 1 specifies snooping with proxy reporting
(SPR); the value 2 specifies IGMP proxy. The function must be consistent
with the capabilities specified by the other IGMP configuration attributes.
(R,W, Set-by-create) (mandatory) (1 byte)
Immediate leave: This Boolean attribute controls the immediate leave function. The value
false disables immediate leave; true enables immediate leave. (R,W,
Upstream IGMP TCI: Under control of the upstream IGMP tag control attribute, the
upstream IGMP TCI attribute defines a VLAN ID and P-bits to add to
upstream IGMP messages. (R, W, Set-by-create) (optional) (2 bytes)
Upstream IGMP tag control: This attribute controls the upstream IGMP TCI attribute. If
this attribute is non-zero, a possible extended VLAN tagging operation ME is
ignored for upstream frames containing IGMP/MLD packets. (R, W,
Set-by-create) (optional) (1 byte)
Value Meaning
0
Pass upstream IGMP/MLD traffic transparently, neither
adding, stripping nor modifying tags that may be present.
1
Add a VLAN tag (including P bits) to upstream IGMP/MLD
traffic. The tag is specified by the upstream IGMP TCI
attribute.
2
Replace the entire TCI (VLAN ID plus P bits) on upstream
IGMP/MLD traffic. The new tag is specified by the upstream
IGMP/MLD TCI attribute. If the received IGMP/MLD traffic
is untagged, an add operation is performed.
3
Replace only the VLAN ID on upstream IGMP/MLD traffic,
retaining the original DEI and P bits. The new VLAN ID is
specified by the VLAN ID field of the upstream IGMP TCI
attribute. If the received IGMP/MLD traffic is untagged, an
add operation is performed, with DEI and P bits also taken
from the upstream IGMP TCI attribute.
Upstream IGMP rate: This attribute limits the maximum rate of upstream IGMP traffic.
Traffic in excess of this limit is silently discarded. The attribute value is
specified in messages/second. The recommended default value 0 imposes no
rate limit on this traffic. (R, W, Set-by-create) (optional) (4 bytes)
Dynamic access control list table: This attribute is a list that specifies one or more
multicast group address ranges. Each row in the list comprises up to 3 row
parts, where each row part is 24 bytes long. Each entry must include row part
0. The ONU may also support row parts 1-2, thus allowing the table to
contain logical rows that exceed the 24-byte definition of row part 0.
Table control (2 bytes)
16
15
Set ctrl
14
13
12
Row part ID
11
Test
10
Row key
The first two bytes of each row part is the table control field, which
comprises a key into the row, the row part identifier, and fields to define the
164
Rec. ITU-T G.988 (10/2012)
result of a set operation and to test whether the ONU supports the extended
table format.
It is the responsibility of the OLT to assign and track row keys and content.
The ONU should deny set operations that create range overlaps.
Set ctrl
The two MSBs of this field determine the meaning of a set operation. These
bits are returned as 00 during get next operations.
Bits 16..15
Meaning
00
Reserved
01
Write this entry into the table. Overwrite any existing

entry with the same row part ID and row key.
10
Delete this entry from the table, including all row

parts. The remaining fields are not meaningful.
11
Clear all entries from the table. The remaining fields

are not meaningful.
Row part ID
The row part ID field distinguishes the row part associated with the current
set or get operation.
Row part 0 is backward compatible with earlier versions of this ME
definition. Row parts 1-2 are optional on a row by row basis. They can be set
by using values 001-010 as the row part ID. Row parts 3-7 are reserved.
Bits 14..12
Meaning
000
The associated row part has format 0.
001
010
011..111
Reserved
Test
This bit allows the OLT to determine whether an ONU supports the extended
format access control list. If the ONU does not support the extended format,
it should be possible to set the test bit to 1 and read it back with a get and get
next operation. If the ONU does support the extended format, this bit should
always return the value 0 under a get next operation.
Row key
The row key distinguishes rows in the table.
Row part definition
Byte
Row part 0
Row part 1
Row part 2
Table control
(2 bytes)
Table control
(2 bytes)
Table control
(2 bytes)
GEM port ID
(2 bytes)
Leading bytes of
IPv6 source address
(12 bytes)
Leading bytes of
IPv6 destination
address
(12 bytes)
2
3
4
5
6
VLAN ID (ANI)
(2 bytes)
Rec. ITU-T G.988 (10/2012)
165
7
8
Source IP address
(4 bytes)
9
10
11
12
13
Destination IP address,
start of range
(4 bytes)
14
15
16
17
Destination IP address,
end of range
(4 bytes)
18
19
20
21
24
Reserved
(10 bytes)
Preview repeat time

(2 bytes)
Imputed group
bandwidth
(4 bytes)
Preview repeat count

(2 bytes)
Reserved
(2 bytes)
Reserved
(2 bytes)
22
23
Preview length
(2 bytes)
Preview reset
time (2 bytes)
Figure 9.3.27-1 ACL row part formats

Format of row part 0:
GEM port-ID (2 bytes)
VLAN ID (ANI). This field specifies the VLAN carrying the
multicast group downstream. The VLAN ID resides in the 12 least
significant bits; the remaining bits are set to 0 and not used. The value
0 designates an untagged downstream flow. (2 bytes)
Source IP address. The value 0.0.0.0 specifies that the source IP
address is to be ignored. By default, this is an IPv4 address; it may be
an IPv6 address if it is associated with a part 1 row. (4 bytes)
Destination IP address of the start of the multicast range. By default,
this is an IPv4 address; it may be an IPv6 address if it is associated
with a part 2 row. (4 bytes)
Destination IP address of the end of the multicast range. By default,
this is an IPv4 address; it may be an IPv6 address if it is associated
with a part 2 row. (4 bytes)
Imputed group bandwidth. Expressed in bytes per second, the
imputed group bandwidth is used to decide whether or not to honour a
join request in the presence of a max multicast bandwidth limit. The
recommended default value 0 effectively allows this table entry to
avoid max bandwidth limitations (4 bytes)
Reserved, set to 0. (2 bytes)
A single multicast group may be specified by setting start and end destination
IP addresses to the same value.
166
Rec. ITU-T G.988 (10/2012)
The leading bytes of the IPv6 source address (12 bytes). This field is
prepended to the four-byte source IP address field of the
corresponding part 0 row. The row part 0 address field is interpreted
as an IPv4 address if the first 10 bytes of this row part 1 field are 0
and the last two bytes are either 0 or 0xFFFF [b-IETF RFC 4291].
The latter syntax is preferred.
Preview length. The maximum duration of each preview in seconds.

The value 0 designates a group that is fully authorized by subscription
and is not subject to preview restrictions. The remaining preview
attributes in this row part are ignored. (2 bytes)
Preview repeat time. The minimum time in seconds between two

previews of a given multicast group. (2 bytes)
Preview repeat count. The maximum number of times a given

multicast group may be previewed. A value of zero allows an
unlimited number of previews. (2 bytes)
Preview reset time. The time at which the ONU resets the preview
repeat counter. The value assignments are as follows: (2 bytes)
0: Do not reset the preview repeat counter automatically. It is
cleared only upon explicit action by the OLT.
1..24: The integer clock time at which the ONU resets the preview
repeat counter. For example the value 2 resets the counter at
2:00 AM. If the ONU does not have a time of day clock, the
preview repeat counter is reset every 24 hours at an
indeterminate time selected by the ONU.
25240: Reserved by ITU
241..254: Reserved for vendor-specific use
255: Used by the OLT to explicitly reset the preview repeat counter.
A set action with this value clears the preview repeat count to
zero, but does not alter the pre-existing value of the field in the
table row part.
Reserved (2 bytes)

The leading bytes of the IPv6 destination addresses (12 bytes). This
field is prepended to the four-byte destination IP address field of the
corresponding part 0 row. The row part 0 address field is interpreted
as an IPv4 address if the first 10 bytes of this row part 2 field are 0
and the last two bytes are either 0 or 0xFFFF [b-IETF RFC 4291].
The latter syntax is preferred.
Reserved (10 bytes)
(R, W) (mandatory) (each row part: 24 bytes)
Discussion of table size: While theoretically, this table could contain 1024 entries, realworld applications are not expected to require large tables. It is instead
anticipated that the table will list a moderate number of contiguous ranges,
each of which shares a common GEM port, VLAN, IP source address,
imputed bandwidth, and preview characteristics. The ONU maintains
preview counters and interval timers on a per-multicast group basis, not
collectively for the entire range.
Rec. ITU-T G.988 (10/2012)
167
Static access control list table: This attribute is a list that specifies one or more multicast
group address ranges. Groups defined in this list are multicast on the
associated UNI(s) unconditionally, that is, without the need for an IGMP
join. The bandwidth of static multicast groups is not included in the current
multicast bandwidth measurement maintained by the multicast subscriber
monitor managed entity. If a join message is always expected, this table may
be empty. Table entries have the same format as those in the dynamic access
control list table. The preview fields are not meaningful. (R, W) (mandatory)
(each row part: 24 bytes)
Lost groups list table: This attribute is a list of groups from the dynamic access control list
table for which there is an active join, but no downstream flow is present,
possibly because of source failure, but also possibly because of
misconfiguration somewhere upstream. Be aware of possible ambiguity
between overlapping service providers and IPv4/IPv6 addresses. After a join,
the ONU should wait a reasonable time for upstream processing before
declaring a group to be lost. Each entry is a vector of the following
components:
VLAN ID, 0 if not used (2 bytes)
Source IP address, 0.0.0.0 if not used. In IPv6, this field captures only
the four least significant bytes. (4 bytes)
Multicast destination IP address. In IPv6, this field captures only the
four least significant bytes. (4 bytes)
(R) (optional) (10N bytes)
Robustness: This attribute allows tuning for possible packet loss in the network. The
recommended default value 0 causes the ONU to follow the IETF
recommendation [IETF RFC 3376] to copy the robustness value from query
messages originating further upstream. (R, W, Set-by-create) (optional)
(1 byte)
Querier IP address: This attribute specifies the IP address to be used by a proxy querier.
Although it is not a legitimate IP address, the recommended default value
0.0.0.0 is legal in this case (see [b-IETF RFC 4541]). (R, W, Set-by-create)
Query interval: This attribute specifies the interval between general queries in seconds. The
value 0 specifies that the ONU use its own default, which may or may not be
the same as the recommended default of 125 seconds. (R, W, Set-by-create)
Query max response time: This attribute is the max response time added by the proxy into
general query messages directed to UNIs. It is expressed in tenths of seconds.
The value 0 specifies that the ONU use its own default, which may or may
not be the same as the recommended default of 100 (10 seconds). (R, W,
Last member query interval: This attribute specifies the max response time inserted into
group-specific queries sent to UNIs in response to group leave messages. It is
also the repetition rate of [robustness] transmissions of the query. It is
specified in tenths of seconds, with a default of 10 (1 second). (R, W)
Unauthorized join request behaviour: This Boolean attribute specifies the ONU's
behaviour when it receives an IGMP join request for a group that is not
authorized in the dynamic address control list table, or an IGMPv3
168
Rec. ITU-T G.988 (10/2012)
membership report for groups, none of which are authorized in the dynamic
ACL. The default value false specifies that the ONU silently discard the
IGMP request; the value true specifies that the ONU forwards the request
upstream. The ONU does not attempt to honour the request for the
unauthorized group(s) in either case. (R, W) (optional) (1 byte)
Downstream IGMP and multicast TCI: This attribute controls the downstream tagging of
both the IGMP/MLD and multicast frames. If the first byte of this attribute is
non-zero, a possible extended VLAN tagging operation ME is ignored for
downstream IGMP/MLD and multicast frames. (R, W, Set-by-create)
The first byte defines the control type:
Value
Meaning
0
Pass the downstream IGMP/MLD and multicast traffic
transparently, neither stripping nor modifying tags that may be
present.
1
Strip the outer VLAN tag (including P bits) from the
downstream IGMP/MLD and multicast traffic.
2
Add a tag onto the downstream IGMP/MLD and multicast
traffic. The new tag is specified by the second and third bytes
of this attribute.
3
Replace the tag on the downstream IGMP/MLD and multicast
traffic. The new tag is specified by the second and third bytes
of this attribute.
4
Replace only the VLAN ID on the downstream IGMP/MLD
and multicast traffic, retaining the original DEI and P bits. The
new VLAN ID is specified by the VLAN ID field of the
second and third bytes of this attribute.
5
Add a tag onto the downstream IGMP/MLD and multicast
traffic. The new tag is specified by the VID (UNI) field of the
multicast service package table row of the multicast subscriber
config info ME that is associated with this profile. If the VID
(UNI) field is unspecified (0xFFFF) or specifies untagged
traffic, the new tag is specified by the second and third bytes
of this attribute.
6
Replace the tag on the downstream IGMP/MLD and multicast
traffic. The new tag is specified by the VID (UNI) field of the
(UNI) field specifies untagged traffic, the outer VLAN tag
(including P bits) is stripped from the downstream
IGMP/MLD and multicast traffic. If the value of the VID
(UNI) is unspecified (0xFFFF), the new tag is specified by the
7
Replace only the VID on the downstream IGMP/MLD and
multicast traffic, retaining the original DEI and P bits. The
new VLAN ID is specified by the VID (UNI) field of the
(UNI) field specifies untagged traffic, the outer VLAN tag
(including P bits) is stripped from the downstream
IGMP/MLD and multicast traffic. If the value of the VID
Rec. ITU-T G.988 (10/2012)
169
(UNI) is unspecified (0xFFFF), the new tag is specified by the

The second and third bytes define the TCI (VLAN ID and P bits) to be
applied on the downstream IGMP/MLD and multicast streams in case the
replace or add option is selected.
Actions
Notifications
Alarm
Alarm
number
0
1..207
208..223
Alarm
Lost multicast group
Description
Indicates that for one or more multicast groups, there is
an active join, but no downstream flow is present. This
alarm is equivalent to a non-zero number of entries in the
lost groups list table attribute. When the alarm is active,
the OLT may use the table to retrieve the details of the
lost group(s).
Reserved
9.3.28 Multicast subscriber config info

This managed entity organizes data associated with multicast management at subscriber ports of
IEEE 802.1 bridges, including IEEE 802.1p mappers when the provisioning model is mapper-based
rather than bridge-based. Instances of this managed entity are created and deleted by the OLT.
Because of backward compatibility considerations, a subscriber port without an associated multicast
subscriber config info ME would be expected to support unrestricted multicast access; this ME may
therefore be viewed as restrictive, rather than permissive.
Through separate attributes, this ME supports either a single multicast operations profile in its
backward compatible form, or a list of multicast operations profiles instead (the list may of course
contain a single entry). The OLT can determine whether the ONU supports the multiple profile
capability by performing a get operation on the optional multicast service package table attribute,
which exists only on ONUs that are prepared to support the feature.
Relationships
An instance of this managed entity is associated with one instance of the MAC bridge port
configuration data or the IEEE 802.1p mapper service profile.
Attributes
instance of the MAC bridge port configuration data or IEEE 802.1p mapper
ME. (R, Set-by-create) (mandatory) (2 bytes)
ME type:
170
This attribute indicates the type of the ME implicitly linked by the managed
entity ID attribute.
0 MAC bridge port config data
Rec. ITU-T G.988 (10/2012)

Multicast operations profile pointer: This attribute points to an instance of the multicast
operations profile. This attribute is ignored by the ONU if a non-empty
multicast service package table attribute is present. (R,W, Set-by-create)
Max simultaneous groups: This attribute specifies the maximum number of dynamic
multicast groups that may be replicated to the client port at any one time. The
recommended default value 0 specifies that no administrative limit is to be
imposed. (R, W, Set-by-create) (optional) (2 bytes)
Max multicast bandwidth: This attribute specifies the maximum imputed dynamic
bandwidth, in bytes per second, that may be delivered to the client port at any
one time. The recommended default value 0 specifies that no administrative
limit is to be imposed. (R, W, Set-by-create) (optional) (4 bytes)
Bandwidth enforcement: The recommended default value of this Boolean attribute is false,
and specifies that attempts to exceed the max multicast bandwidth be counted
but honoured. The value true specifies that such attempts be counted and
denied. The imputed bandwidth value is taken from the dynamic access
control list table, both for a new join request and for pre-existing groups.
Multicast service package table: This attribute is a list that specifies one or more multicast
service packages. When the ONU receives an IGMP/MLD join request, it
searches the multicast service package table in row key order, matching the
VID (UNI) field (several rows can share the same VID). For each VID (UNI)
match, the multicast operations profile pointer is used to access the ME that
contains the attributes associated with the service package. The search stops
when all requested multicast groups have been found and dealt with.
Each list entry is a vector of six components:
The first two bytes of each entry contain a key into the table. It is the
responsibility of the OLT to assign and track table keys and content.
Since row keys are created by the OLT, they may be densely or
sparsely packed.
The two MSBs of this field determine the meaning of a set operation.
These bits are returned as 00 during get next operations.
Bits 16..15
Meaning
00
Reserved
01

entry with the same row key.
10
Delete this entry from the table. The remaining fields

are not meaningful.
11

are not meaningful.
Bits 14..11 are reserved. Bits 10..1 are the row key itself.
Rec. ITU-T G.988 (10/2012)
171
VID (UNI). The value in this field is compared with the VID of
upstream IGMP/MLD messages, and is used to decide whether to
honour a join request. (2 bytes)
Values:
0..4095 Matched against the VID of the IGMP/MLD message. 0
indicates a priority-tagged message, whose P bits are ignored.
4096 Matches untagged IGMP/MLD messages only.
4097 Matches tagged messages only, but ignores the value of
the VID.
0xFFFF Unspecified.
The VID (UNI) comparison occurs prior to any action defined by the
upstream IGMP tag control attribute in an associated multicast
operations profile (or alternatively, before any modification by a
possible (extended) VLAN tagging operation configuration data ME).
Max simultaneous groups. This field specifies the maximum
number of dynamic multicast groups that may be replicated to the
client port at any one time, for the multicast service package that is
associated with this row. The value 0 specifies that no administrative
limit is to be imposed. (2 bytes)
Max multicast bandwidth. This field specifies the maximum
imputed dynamic bandwidth, in bytes per second, that may be
delivered to the client port at any one time, for the multicast service
package that is associated with this row. The value 0 specifies that no
administrative limit is to be imposed. (4 bytes)
NOTE The port is also constrained by the global max simultaneous groups
and max multicast bandwidth attributes of the multicast subscriber config
info ME.
Multicast operations profile pointer. This field contains the ME ID

of the multicast operations profile ME associated with this service
package. (2 bytes)
Reserved (8 bytes)
(R, W) (optional) (20N bytes, where N is the number of entries in the table)
Allowed preview groups table: This attribute is a list that specifies the preview groups that
are currently allowed for the UNI associated with this ME. It is intended to
support paid viewing of a multicast group that may or may not have been
previewed.
When an IGMP/MLD join request is received, the order of search precedence
is as follows:
1. Multicast operations profile(s), fully authorized groups
2. This attribute, the allowed preview groups table
3. Multicast operations profile(s), preview-only groups
If the first match is a group listed in this attribute, the ONU forwards the
group to the UNI until the group is removed from this list, or until the
subscriber leaves the group.
Each list entry begins with a table control field:
172
Rec. ITU-T G.988 (10/2012)
16
15
14
Set ctrl
13
12
Row part
11
10
Rsv
Row key
The first two bytes of each entry contain a key into the table, as well as table
management fields. It is the responsibility of the OLT to assign and track row
keys and content.
Set ctrl
The two MSBs of this field determine the meaning of a set operation. These
bits are returned as 00 during get next operations.
Bits 16..15
Meaning
00
Reserved
01

entry with the same row part and row key.
10
Delete this entry from the table, including all row

parts. The remaining fields are not meaningful.
11

are not meaningful.
Row part
The row part field allows the table to contain logical rows that exceed the
maximum length of a single row. Table entries with the same row key and
different row parts are understood to comprise a single extended row. In this
managed entity, an extended row always contains two row parts.
The meaning of extended rows is defined below.
Bits 14..12
Meaning
000
The associated row operation is for part 0.
001
The associated row operation is for part 1.
010..111
Reserved
Rsv
This bit is reserved.
Row key
The row key identifies rows in the table. Row keys may be either densely or
sparsely populated.
Rec. ITU-T G.988 (10/2012)
173
Row part format definition

Byte
Row part 0
Row part 1
Table control
(2 bytes)
Table control
(2 bytes)
Source IP address
(16 bytes)
Destination IP
address
(16 bytes)
VLAN ID (ANI)
(2 bytes)
Duration
(2 bytes)
VLAN ID (UNI)
(2 bytes)
Time left
(2 bytes)
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Figure 9.3.28-1 Allowed preview groups row part formats

Row part 0 format:
174
Source IP address. This field specifies the source IP address of the

allowed preview group. May be either an IPv4 address (first twelve
bytes 0) or an IPv6 address. (16 bytes)
VLAN ID (ANI). This field specifies the VLAN carrying the

multicast group downstream. The VLAN ID resides in the 12 least
significant bits; the remaining bits are set to 0 and not used. The value
0 designates an untagged downstream flow. (2 bytes)
VLAN ID (UNI). This field specifies the VLAN carrying

IGMP/MLD messages upstream across the UNI. The VLAN ID
resides in the 12 least significant bits; the remaining bits are set to 0
and not used. The value 0 designates an untagged upstream flow.
(2 bytes)
Rec. ITU-T G.988 (10/2012)
Row part 1 format:
Destination IP address. This field specifies the destination IP address

of the allowed preview group. May be either an IPv4 address (first
twelve bytes 0) or an IPv6 address. (16 bytes)
Duration This field indicates the static length of time in minutes for
which the group is authorized. The value 0 designates unlimited
authorization. (2 bytes)
Time left This field is controlled by the ONU (ignored during a set
operation from the OLT). It indicates how much time (measured in
minutes) remains in the authorization. The ONU counts down; when
this field reaches zero, the ONU deletes the entire entry from the table
and stops replicating the group to the UNI. If the duration field
specifies unlimited authorization, this field is ignored. The OLT may
extend (or even truncate) the authorization by writing a new value
into the duration field; the difference between new and old duration
values is added to the time left field. (2 bytes)
(R, W) (optional) (Each row part: 22 bytes)

Actions
Notifications
None.
9.3.29 Multicast subscriber monitor
This managed entity provides the current status of each port with respect to its multicast
subscriptions. It may be useful for status monitoring or debugging purposes. The status table
includes all dynamic groups currently subscribed by the port.
Relationships
Instances of this managed entity are created and deleted at the request of the OLT. One
instance may exist for each IEEE 802.1 UNI configured to support multicast subscription.
Attributes
instance of the MAC bridge port configuration data or IEEE 802.1p mapper
ME. (R, Set-by-create) (mandatory) (2 bytes)
ME type:
This attribute indicates the type of the ME implicitly linked by the managed
entity ID attribute.
0 MAC bridge port config data
Current multicast bandwidth: This attribute is the ONU's best effort estimate of the actual
bandwidth currently being delivered to this particular MAC bridge port over
all dynamic multicast groups. (R) (optional) (4 bytes)
Rec. ITU-T G.988 (10/2012)
175
Join messages counter: This attribute counts the number of times the corresponding
subscriber sent a join message that was accepted. When full, the counter rolls
over to 0. (R) (optional) (4 bytes)
Bandwidth exceeded counter: This attribute counts the number of join messages that did
exceed, or would have exceeded, the max multicast bandwidth, whether
accepted or denied. When full, the counter rolls over to 0. (R) (optional)
(4 bytes)
IPv4 active group list table: This attribute lists the groups from one of the related dynamic
access control list tables or the allowed preview groups table that are
currently being actively forwarded, along with the actual bandwidth of each.
If a join has been recognized from more than one IPv4 source address for a
given group on this UNI, there will be one table entry for each. Each table
entry has the form:
Source IP address, 0.0.0.0 if not used (4 bytes)
Multicast destination IP address (4 bytes)
Best efforts actual bandwidth estimate, bytes per second (4 bytes)
Client (set-top box) IP address, that is, the IP address of the device
currently joined (4 bytes)
Time since the most recent join of this client to the IP channel, in
seconds (4 bytes)
Reserved (2 bytes)
IPv6 active group list table: This attribute lists the groups from one of the related dynamic
access control list tables or the allowed preview groups table that are
currently being actively forwarded, along with the actual bandwidth of each.
If a join has been recognized from more than one IPv6 source address for a
given group on this UNI, there will be one table entry for each. In mixed
IPv4-IPv6 scenarios, it is possible that some fields might be IPv4, in which
case their twelve most significant bytes of the given field are set to zero.
Each table entry has the form:
Source IP address, 0 if not used (16 bytes)
Multicast destination IP address (16 bytes)
Best efforts actual bandwidth estimate, bytes per second (4 bytes)
Client (set-top box) IP address, that is, the IP address of the device
currently joined (16 bytes)
Time since the most recent join of this client to the IP channel, in
seconds (4 bytes)
Actions
Notifications
None.
176
Rec. ITU-T G.988 (10/2012)
9.3.30 Ethernet frame performance monitoring history data upstream

This managed entity collects performance monitoring data associated with upstream Ethernet frame
delivery. It is based on the Etherstats group of [IETF RFC 2819]. Instances of this managed entity
are created and deleted by the OLT.
NOTE 1 Implementers are encouraged to consider the Ethernet frame extended PM ME defined in
clause 9.3.32, which collects the same counters in a more generalized way.
Relationships
configuration data.
Attributes
instance of a MAC bridge port configuration data. (R, Set-by-create)
Drop events: The total number of events in which packets were dropped due to a lack of
resources. This is not necessarily the number of packets dropped; it is the
number of times this event was detected. (R) (mandatory) (4 bytes)
Octets:
The total number of upstream octets received, including those in bad packets,
excluding framing bits, but including FCS. (R) (mandatory) (4 bytes)
Packets:
The total number of upstream packets received, including bad packets,

broadcast packets and multicast packets. (R) (mandatory) (4 bytes)
Broadcast packets: The total number of upstream good packets received that were directed
to the broadcast address. This does not include multicast packets. (R)
Multicast packets: The total number of upstream good packets received that were directed
to a multicast address. This does not include broadcast packets. (R)
CRC errored packets: The total number of upstream packets received that had a length
(excluding framing bits, but including FCS octets) of between 64 and
1518 octets, inclusive, but had either a bad frame check sequence (FCS) with
an integral number of octets (FCS error) or a bad FCS with a non-integral
number of octets (alignment error). (R) (mandatory) (4 bytes)
Undersize packets: The total number of upstream packets received that were less than
64 octets long but were otherwise well formed (excluding framing bits, but
including FCS). (R) (mandatory) (4 bytes)
Oversize packets: The total number of upstream packets received that were longer than
1518 octets (excluding framing bits, but including FCS) and were otherwise
well formed. (R) (mandatory) (4 bytes)
Rec. ITU-T G.988 (10/2012)
177
NOTE 2 If 2000-byte Ethernet frames are supported, counts in this performance

parameter are not necessarily errors.
Packets 64 octets: The total number of upstream received packets (including bad packets)
that were 64 octets long, excluding framing bits but including FCS. (R)
Packets 65 to 127 octets: The total number of upstream received packets (including bad
packets) that were 65..127 octets long, excluding framing bits but including
FCS. (R) (mandatory) (4 bytes)
Packets 128 to 255 octets: The total number of upstream packets (including bad packets)
received that were 128..255 octets long, excluding framing bits but including
received that were 256..511 octets long, excluding framing bits but including
received that were 512..1023 octets long, excluding framing bits but
including FCS. (R) (mandatory) (4 bytes)
received that were 1024..1518 octets long, excluding framing bits but
including FCS. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
Threshold data counter # (Note)
Drop events
CRC errored packets
Undersize packets
Oversize packets
9.3.31 Ethernet frame performance monitoring history data downstream

This managed entity is identical to the Ethernet frame performance monitoring history data
upstream managed entity, with the exception that it monitors downstream traffic.
9.3.32 Ethernet frame extended PM
This managed entity collects some of the performance monitoring data at a point where an Ethernet
flow can be observed. It is based on the Etherstats group of [IETF RFC 2819]. Instances of this
managed entity are created and deleted by the OLT. References to received frames are to be
interpreted as the number of frames entering the monitoring point in the direction specified by the
control block.
178
Rec. ITU-T G.988 (10/2012)
Relationships
An instance of this managed entity may be associated with an instance of an ME at any
Ethernet interface within the ONU. The specific ME is identified in the control block
attribute.
Attributes
To facilitate discovery, it is encouraged to identify instances sequentially
starting with 1. (R, Set-by-create) (mandatory) (2 bytes)
Interval end time: This attribute identifies the most recently finished 15-minute interval. If
continuous accumulation is enabled in the control block, this attribute is not
used and has the fixed value 0. (R) (mandatory) (1 byte)
Control Block: This attribute contains fields defined as follows:
Threshold data 1/2 ID: (2 bytes) This attribute points to an instance of the
threshold data 1 managed entity that contains PM threshold values. Since no
threshold value attribute number exceeds 7, a threshold data 2 ME is
optional. When PM is collected on a continuously-running basis, rather than
in 15-minute intervals, counter thresholds should not be established. There is
no mechanism to clear a TCA, and any counter parameter may eventually be
expected to cross any given threshold value.
Parent ME class: (2 bytes) This field contains the enumerated value of the
ME class of the PM ME's parent. Together with the parent ME instance field,
this permits a given PM ME to be associated with any OMCI ME. The
supported ME classes are:
46
47
11
98
Physical path termination point xDSL UNI part 1
266
281
329
162
Parent ME instance: (2 bytes) This field identifies the specific parent ME
instance to which the PM ME is attached.
Accumulation disable: (2 bytes) This bit field allows PM accumulation to be
disabled; refer to Table 9.3.32-1. The default value 0 enables PM collection.
If bit 15 is set to 1, no PM is collected by this ME instance. If bit 15 = 0 and
any of bits 14..1 are set to 1, PM collection is inhibited for the attributes
indicated by the 1 bits. Inhibiting PM collection does not change the value of
a PM attribute, but if PM is accumulated in 15-minute intervals, the value is
lost at the next 15-minute interval boundary.
Bit 16 is an action bit that always reads back as 0. When written to 1, it resets
all PM attributes in the ME, and clears any TCAs that may be outstanding.
Rec. ITU-T G.988 (10/2012)
179
Table 9.3.32-1 Bit assignments in extended PM control block

Bit
16
15
14
13
1
(LSB)
Accumulation
disable
Global
clear
Global
disable
PM14
PM2
PM1
Global
disable
Th14
Th2
Th1
TCA disable
TCA disable: (2 bytes) Also clarified in Table 9.3.32-1, this field permits
TCAs to be inhibited, either individually or for the complete managed entity
instance. As with the accumulation disable field, the default value 0 enables
TCAs, and setting the global disable bit overrides the settings of the
individual thresholds. Unlike the accumulation disable field, the bits are
mapped to the thresholds defined in the associated threshold data 1 and 2 ME
instances. When the global or attribute-specific value changes from 0 to 1,
outstanding TCAs are cleared, either for the ME instance globally or for the
individual disabled threshold. These bits affect only notifications, not the
underlying parameter accumulation or storage.
If the threshold data 1/2 ID attribute does not contain a valid pointer, this
field is not meaningful.
Thresholds should be used with caution if PM attributes are accumulated
continuously.
Control fields: (2 bytes) This field is a bit map whose values govern the
behaviour of the PM ME. Bits are assigned as follows:
Bit 1 (LSB) The value 1 specifies continuous accumulation, regardless
of 15-minute intervals. There is no concept of current and
historical accumulators; get and get current data (if
supported) both return current values. The value 0
specifies 15-minute accumulators exactly like those of
classical PM.
Bit 2
This bit indicates directionality for the collection of data.
The value 0 indicates that data is to be collected for
upstream traffic. The value 1 indicates that data is to be
collected for downstream traffic.
Bits 3..14
Reserved, should be set to 0 by the OLT and ignored by
the ONU.
Bit 15
When this bit is 1, the P bits of the TCI field are used to
filter the PM data collected. The value 0 indicates that PM
is collected without regard to P bits.
Bit 16
When this bit is 1, the VID bits of the TCI field are used to
filter the PM data collected. The value 0 indicates that PM
is collected without regard to VID.
TCI: (2 bytes) This field contains the value optionally used as a filter for the
PM data collected, under the control of bits 15..16 of the control fields. This
value is matched to the outer tag of a frame. Untagged frames are not counted
when this field is used.
Reserved: (2 bytes) Not used; should be set to 0 by the OLT and ignored by
the ONU.
180
Rec. ITU-T G.988 (10/2012)

Drop events: The total number of events in which frames were dropped due to a lack of
resources. This is not necessarily the number of frames dropped; it is the
Octets:
The total number of octets received, including those in bad frames, excluding
framing bits, but including FCS. (R) (mandatory) (4 bytes)
Frames:
The total number of frames received, including bad frames, broadcast frames
and multicast frames. (R) (mandatory) (4 bytes)
Broadcast frames: The total number of received good frames directed to the broadcast
address. This does not include multicast frames. (R) (mandatory) (4 bytes)
Multicast frames: The total number of received good frames directed to a multicast
address. This does not include broadcast frames. (R) (mandatory) (4 bytes)
CRC errored frames: The total number of frames received that had a length (excluding
framing bits, but including FCS octets) of between 64 and 1518 octets,
inclusive, but had either a bad frame check sequence (FCS) with an integral
number of octets (FCS error) or a bad FCS with a non-integral number of
octets (alignment error). (R) (mandatory) (4 bytes)
Undersize frames: The total number of frames received that were less than 64 octets long
but were otherwise well formed (excluding framing bits, but including FCS
octets). (R) (mandatory) (4 bytes)
Oversize frames: The total number of frames received that were longer than 1518 octets
(excluding framing bits, but including FCS octets) and were otherwise well
formed. (R) (mandatory) (4 bytes)
Frames 64 octets: The total number of received frames (including bad frames) that were
64 octets long, excluding framing bits but including FCS. (R) (mandatory)
(4 bytes)
Frames 65 to 127 octets: The total number of received frames (including bad frames) that
were 65..127 octets long, excluding framing bits but including FCS. (R)
Frames 128 to 255 octets: The total number of frames (including bad frames) received that
Frames 256 to 511 octets: The total number of frames (including bad frames) received that
Frames 512 to 1023 octets: The total number of frames (including bad frames) received
that were 512..1023 octets long, excluding framing bits but including FCS.
Frames 1024 to 1518 octets: The total number of frames (including bad frames) received
Actions
Rec. ITU-T G.988 (10/2012)
181
Notifications
Alarm
number
Drop events
CRC errored frames
Undersize frames
Oversize frames
9.3.33 MAC bridge port ICMPv6 process pre-assign table

This managed entity provides an approach to ICMPv6 message processing configuration to those
ONUs that support IPv6 awareness. For every message, the MAC bridge port ICMPv6 process preassign table can designate a forward, discard or snoop operation. The ONU creates or deletes an
instance of this managed entity automatically upon creation or deletion of a MAC bridge port
The MAC bridge port ICMPv6 process pre-assign table ME filters layer 2 traffic between the UNI
and ANI. The operation of this ME is completely independent of the operation and traffic generated
or received by a possible IPv6 host config data ME.
Relationships
Attributes
(2 bytes)
The following nine attributes have similar definitions. Each permits the OLT to specify ICMPv6 as
the next header in the IPv6 header and various types in the ICMPv6 header, and whether traffic of
the specified type is forwarded, discarded or snooped, in upstream and downstream directions
separately. The bits of each attribute are assigned as follows:
Bit
182
Name
Setting
1..2 (LSB)
Process for
upstream
00: forward
01: discard
10: snoop
3..4
Process for
downstream
00: forward
01: discard
10: snoop
5..8
Reserved
Rec. ITU-T G.988 (10/2012)
The initial value of each attribute is given in the last column of the table.
#
Protocol
Next header
type
Standard
Initial value
ICMPv6 error
messages
58
1-4
[b-IETF RFC 2460]

[b-IETF RFC 2463]
ICMPv6 informational
messages
58
128,129
[b-IETF RFC 2460]

[b-IETF RFC 2463]
Neighbour discovery
router solicitation
58
133
[b-IETF RFC 2460]

[b-IETF RFC 4861]
Neighbour discovery
router advertisement
58
134
[b-IETF RFC 2460]

[b-IETF RFC 4861]
Neighbour discovery
neighbour solicitation
58
135
[b-IETF RFC 2460]

[b-IETF RFC 4861]
Neighbour discovery
neighbour
advertisement
58
136
[b-IETF RFC 2460]

[b-IETF RFC 4861]
Neighbour discovery
redirect
58
137
[b-IETF RFC 2460]

[b-IETF RFC 4861]
MLD Multicast
listener query
(MLDv1, MLDv2)
58
130
[b-IETF RFC 2710]

[IETF RFC 3810]
Unknown ICMPv6
58
ICMPv6 error messages processing:
ICMPv6 informational messages processing: (R, W) (mandatory) (1 byte)

Router solicitation processing:
Router advertisement processing:
Neighbour solicitation processing:
Neighbour advertisement processing:
Redirect processing:
Multicast listener query processing:
NOTE If the ONU participates in multicast services, MLD queries should be controlled through
the multicast operations profile ME. In such a case, it is strongly recommended not to provision the
downstream direction of the multicast listener query processing attribute to any value other than
forwarding.
Unknown ICMPv6 processing:
Actions
Get, set.
Rec. ITU-T G.988 (10/2012)
183
9.4
9.4.1
IP host config data
The IP host config data configures IPv4 based services offered on the ONU. The ONU
automatically creates instances of this managed entity if IP host services are available. A possible
IPv6 stack is supported through the IPv6 host config data managed entity. In this clause, references
to IP addresses are understood to mean IPv4.
Relationships
An instance of this managed entity is associated with the ONU managed entity. Any number
of TCP/UDP config data MEs can point to the IP host config data, to model any number of
ports and protocols. Performance may be monitored through an implicitly linked IP host PM
history data ME.
Attributes
The ONU creates as many instances as there are independent IPv4 stacks on
the ONU. To facilitate discovery, IP host config data MEs should be
numbered from 0 upwards. The ONU should create IP(v4) and IPv6 host
config data MEs with separate ME IDs, such that other MEs can use a single
TP type attribute to link with either. (R) (mandatory) (2 bytes)
IP options:
This attribute is a bit map that enables or disables IP-related options. The
value 1 enables the option while 0 disables it. The default value of this
attribute is 0.
0x01
Enable DHCP
0x02
Respond to pings
0x04
Respond to traceroute messages
0x08
Enable IP stack
0x10..0x80 Reserved
MAC address: This attribute indicates the MAC address used by the IP node. (R)
Onu identifier: A unique ONU identifier string. If set to a non-null value, this string is used
instead of the MAC address in retrieving DHCP parameters. If the string is
shorter than 25 characters, it must be null terminated. Its default value is 25
null bytes. (R, W) (mandatory) (25 bytes)
Several attributes of this managed entity may be paired together into two categories, manual
settings and current values.
Manual settings
Current values
IP address
Current address
Mask
Current mask
Gateway
Current gateway
Primary DNS
Current primary DNS
Secondary DNS
Current secondary DNS
While the IP stack is disabled, there is no IP connectivity to the external world from this managed
entity instance.
184
Rec. ITU-T G.988 (10/2012)
While DHCP is disabled, the current values are always the same as the manual settings. While
DHCP is enabled, the current values are those assigned by DHCP, or undefined (0) if DHCP has
never assigned values.
IP address:
The address used for IP host services; this attribute has the default value 0.
Mask:
The subnet mask for IP host services; this attribute has the default value 0.
Gateway:
The default gateway address used for IP host services; this attribute has the
default value 0. (R, W) (mandatory) (4 bytes)
Primary DNS: The address of the primary DNS server; this attribute has the default value 0.
Secondary DNS: The address of the secondary DNS server; this attribute has the default
value 0. (R, W) (mandatory) (4 bytes)
Current address: Current address of the IP host service. (R) (optional) (4 bytes)
Current mask: Current subnet mask for the IP host service. (R) (optional) (4 bytes)
Current gateway: Current default gateway address for the IP host service. (R) (optional)
(4 bytes)
Current primary DNS: Current primary DNS server address. (R) (optional) (4 bytes)
Current secondary DNS: Current secondary DNS server address. (R) (optional) (4 bytes)
Domain name: If DHCP indicates a domain name, it is presented here. If no domain name
is indicated, this attribute is set to a null string. If the string is shorter than
25 bytes, it must be null terminated. The default value is 25 null bytes. (R)
Host name:
If DHCP indicates a host name, it is presented here. If no host name is

indicated, this attribute is set to a null string. If the string is shorter than
25 bytes, it must be null terminated. The default value is 25 null bytes. (R)
Relay agent options: This attribute is a pointer to a large string managed entity whose
content specifies one or more DHCP relay agent options. (R, W) (optional)
(2 bytes)
The contents of the large string are parsed by the ONU and converted into
text strings. Variable substitution is based on defined three-character groups,
each of which begins with the '%' character. The string '%%' is an escape
mechanism whose output is a single '%' character. When the ONU cannot
perform variable substitution on a substring of the large string, it generates
the specified option as an exact quotation of the provisioned substring value.
Provisioning of the large string is separate from the operation of setting the
pointer in this attribute. It is the responsibility of the OLT to ensure that the
large string contents are correct and meaningful.
Three-character variable definitions are as follows. The first variable in the
large string must specify one of the option types. Both options for a given IP
version may be present if desired, each introduced by its option identifier.
Terminology is taken from [b-BBF TR-101] clause 3.9.3.
Rec. ITU-T G.988 (10/2012)
185
%01,
%02,
%SL
%SU
%PO
%AE
%SV
%CV
%18
Specifies that the following string is for option 82 sub-option 1,
agent circuit-ID (IPv4) or option 18, interface-ID (IPv6). The
equivalence permits the same large string to be used in both IP
environments.
%37
relay agent remote-ID (IPv4) or option 37, relay agent remoteID (IPv6). The equivalence permits the same large string to be
used in both IP environments.
In TR-101, this is called a slot. In an ONU, this variable refers
to a shelf. It would be meaningful if the ONU has multiple
shelves internally or is daisy-chained to multiple equipment
modules. The range of this variable is "0".. "99"
In TR-101, this is called a sub-slot. In fact, it represents a
cardholder. The range of this variable is "0".. "99"
UNI port number. The range of this variable is "0".. "999"
ATM or Ethernet. This variable can take on the values "atm" or
"eth".
S-VID for Ethernet UNI, or ATM VPI for ATM UNI, as it
exists on the DHCP request received upstream across the UNI.
Range "0".. "4096" for S-VID; range "0".. "255" for VPI. The
value "4096" indicates no S-VID tag.
C-VID (Q-VID) for Ethernet UNI, or ATM VCI for ATM UNI,
as it exists on the DHCP request received upstream across the
UNI. Range "0".. "4096" for C-VID; range "0".."65535" for
VCI. The value "4096" indicates no C-VID tag.
Spaces in the provisioned string are significant.

Example: if the large string were provisioned with the value
%01%SL/%SU/%PO:%AE/%SV.%CV<null>,
then the ONU would generate the following DHCP option 82 agent circuitID string for an Ethernet UNI that sent a DHCP request with no S tag and C
tag = 3210 on shelf 2, slot 3, port 4.
2/3/4:eth/4096.3210
With the same provisioning, the ONU would generate the following DHCP
option 82 agent circuit-ID string for an ATM UNI that sent a DHCP request
on VPI = 123 and VCI = 4567 on shelf 2, slot 3, port 4.
2/3/4:atm/123.4567
Actions
Get, set
Test:
186
Invoke an ICMP message from this IP host. The test message can be
configured to generate a ping or traceroute. Annex A defines the test, test
response and test result messages.
Rec. ITU-T G.988 (10/2012)
Notifications
Number
1..8
9.4.2
Description
N/A
Current address
The new value assigned via DHCP
10
Current mask
11
Current gateway
12
Current primary DNS
13
Current secondary DNS
14
Domain name
15
Host name
16
Reserved
IP host performance monitoring history data
This managed entity collects performance monitoring data related to an IP host. Instances of this
Relationships
An instance of this managed entity is associated with an instance of the IP host config data
or IPv6 host config data managed entity.
Attributes
instance of the IP host configuration data or IPv6 host configuration data ME.
ICMP errors: This attribute counts ICMP errors received. (R) (mandatory) (4 bytes)
DNS errors: This attribute counts DNS errors received. (R) (mandatory) (4 bytes)
DHCP timeouts: This attribute counts DHCP timeouts. (R) (optional) (2 bytes)
IP address conflict: This attribute is incremented whenever the ONU detects a conflicting
IP address on the network. A conflicting IP address is one that has the same
value as the one currently assigned to the ONU. (R) (optional) (2 bytes)
Out of memory: This attribute is incremented whenever the ONU encounters an out of
memory condition in the IP stack. (R) (optional) (2 bytes)
Internal error: This attribute is incremented whenever the ONU encounters an internal
error condition such as a driver interface failure in the IP stack. (R) (optional)
(2 bytes)
Rec. ITU-T G.988 (10/2012)
187
Actions
Notifications
Alarm
number
IPNPM ICMP error
IPNPM DNS error
DHCP timeout
IP address conflict
Out of memory
Internal error
9.4.3
TCP/UDP config data
The TCP/UDP config data managed entity configures TCP and UDP-based services that are offered
from an IP host. If a non-OMCI interface is used to manage an IP service, this ME is unnecessary;
the non-OMCI interface supplies the necessary data.
An instance of this managed entity is created and deleted on request of the OLT.
Relationships
One or more instances of this managed entity may be associated with an instance of an IP
host config data or IPv6 host config data managed entity.
Attributes
It is recommended that the managed entity ID be the same as the port
number. (R, Set-by-create) (mandatory) (2 bytes)
Port ID:
This attribute specifies the port number that offers the TCP/UDP service.
Protocol:
This attribute specifies the protocol type as defined by IANA (protocol

numbers at www.iana.org), for example UDP (0x11). (R, W, Set-by-create)
TOS/diffserv field: This attribute specifies the value of the TOS/diffserv field of the IPv4
header. The contents of this attribute may contain the type of service per
[IETF RFC 2474] or a differentiated services code point (DSCP). Valid
values for DSCP are as defined by IANA (differentiated services field code
points at www.iana.org). (R, W, Set-by-create) (mandatory) (1 byte)
IP host pointer: This attribute points to the IP host config data or IPv6 host config data ME
associated with this TCP/UDP data. Any number of ports and protocols may
be associated with an IP host. (R, W, Set-by-create) (mandatory) (2 bytes)
Actions
188
Rec. ITU-T G.988 (10/2012)
Notifications
None.
9.4.4
TCP/UDP performance monitoring history data
This managed entity collects performance monitoring data related to a TCP or UDP port. Instances
Relationships
An instance of this managed entity is associated with an instance of the TCP/UDP config
Attributes
instance of the TCP/UDP config data ME. (R, Set-by-create) (mandatory)
(2 bytes)
Socket failed: This attribute is incremented when an attempt to create a socket associated
with a port fails. (R) (mandatory) (2 bytes)
Listen failed: This attribute is incremented when an attempt by a service to listen for a
request on a port fails. (R) (mandatory) (2 bytes)
Bind failed:
This attribute is incremented when an attempt by a service to bind to a port

fails. (R) (mandatory) (2 bytes)
Accept failed: This attribute is incremented when an attempt to accept a connection on a

port fails. (R) (mandatory) (2 bytes)
Select failed: This attribute is incremented when an attempt to perform a select on a group
of ports fails. (R) (mandatory) (2 bytes)
Actions
Rec. ITU-T G.988 (10/2012)
189
Notifications
Alarm
number
N/A
Socket failed
Listen failed
Bind failed
Accept failed
Select failed
9.4.5
The IPv6 host config data configures IPv6 based services offered on the ONU. The ONU
automatically creates instances of this managed entity if IPv6 host services are available. If an IPv4
stack is present, it is independently supported through the IP host config data managed entity.
This ME may be statically provisioned or may derive its parameters from router advertisements
and/or DHCPv6.
Relationships
One or more instances of this managed entity are associated with the ONU managed entity.
Any number of TCP/UDP config data MEs can point to the IPv6 host config data, to model
any number of ports and protocols. Performance may be monitored through an implicitly
linked IP host PM history data ME.
Attributes
The ONU creates as many instances as there are independent IP stacks on the
ONU. To facilitate discovery, IP and IPv6 host config data MEs should be
numbered from 0 upwards. The ONU must create IP(v4) and IPv6 host
config data MEs with separate ME IDs, such that other MEs can use a single
TP type attribute to link with either. (R) (mandatory) (2 bytes)
IP options: This attribute is a bit map that enables or disables IPv6 related options. The
value 1 enables the option, while 0 disables it. The default value of this
attribute is 0. (R, W) (mandatory) (1 byte)
0x01
IPv6 stack administrative unlock.
0x02
Enable RS. The host generates router solicitation (RS)
messages, if necessary, and responds to router advertisements. If the
router advertisement (RA) message has the M flag set to 1, the ONU
is expected to request the address and other configuration information
via DHCPv6. If the RA message has the O flag set to 1 and M to 0,
the ONU is expected to only request additional configuration
information via DHCPv6, but not addresses.
0x04
Enable DHCPv6.
0x08
Respond to pings (ICMPv6 echo replies)
0x10..0x80
Reserved
The following IP stack initialization flow is expected:
190
Rec. ITU-T G.988 (10/2012)
1. If the IPv6 stack is administratively unlocked (0x01), establish a linklocal address (self-assign address, DAD to confirm that address is unique
within the local link). This process is defined in [b-IETF RFC 4862], and
is a part of SLAAC. However, no IP options are set to enable or disable
this function it always happens.
2. If RS and DHCPv6 are both disabled, do nothing. Manual settings are to
be used and are required for this IPv6 stack to be fully functional.
3. If RS is enabled (0x02) and DHCPv6 is disabled, send RS and listen for
an RA. If no RA is received, the ONU never attempts DHCPv6 and
cannot complete automated initialization of IPv6. If an RA is received:
a. The ONU builds its default router table per [b-IETF RFC 4861],
reported via the current default router table attribute.
b. If the received RA includes prefix information option(s) with "A"
prefix, then ONU assigns itself an address from all such A prefixes,
per [b-IETF RFC 4862] (also part of SLAAC) (reported via the
current address table attribute).
c. If the received RA includes DNS information [b-IETF RFC 6106],
the ONU accepts it (reported via the current DNS table attribute).
Support for RFC 6106 is strongly recommended.
d. If the received RA has M = 1, then the ONU requests IA_NA and
other options (which could include DNS) via DHCPv6. The access
network provider is responsible for ensuring that, if it sends DNS
information both in the RA and DHCPv6, it sends the same DNS
information; it must not rely on the ONU to figure out whether RA
DNS is preferred over DHCPv6 DNS, or vice versa. If different DNS
information is received via DHCPv6, it also goes into the current
DNS table attribute. If the ONU gets IA_NA via DHCPv6, this goes
into the current address table attribute.
e. If the received RA has M = 0 and O = 1, then the ONU requests
stateless options (which could include DNS) via DHCPv6.
4. If RS and DHCPv6 are both enabled, the ONU does RS (as described in
a-c above, if RA is received) and DHCPv6 (requesting IA_NA and other
options, as described in d above) simultaneously, effectively ignoring M
and O flags.
5. If RS is disabled and DHCPv6 is enabled, then the ONU does not send
RS and it does send DHCPv6 (requesting IA_NA and other options, as
described in d above). If an unsolicited RA is received, it is ignored.
MAC address: This attribute indicates the MAC address used by the IP node. (R)
Onu identifier: A unique ONU identifier string. If set to a non-null value, this string is used
instead of the MAC address in retrieving DHCPv6 parameters. If the string is
shorter than 25 characters, it must be null terminated. Its default value is 25
null bytes. (R, W) (mandatory) (25 bytes)
Several attributes of this managed entity may be paired together into two categories, manual
settings and current values.
Rec. ITU-T G.988 (10/2012)
191
Manual settings
Current values
IPv6 address
Current address table
Default router
Current default router table
Primary DNS
Current DNS table
Secondary DNS
On-link prefix
Current on-link prefix table
While this ME instance is administratively locked, it provides no IPv6 connectivity to the external
world. Especially if manual provisioning is to be used, it is important that the ME remain locked
until provisioning is complete.
While autoconfiguration is disabled, the current values are the same as the manual settings. While
autoconfiguration is enabled, the current values are those autoconfigured on the basis of router
advertisements, assigned by DHCPv6, or undefined (empty tables) if no values have (yet) been
assigned.
IPv6 link local address: The address used for on-link IP host services, such as router
solicitation and DHCPv6. [b-IETF RFC 4862] specifies how to automatically
establish a link-local address. (R) (mandatory) (16 bytes)
IPv6 address: The manually provisioned IPv6 address used for routed IPv6 host services.
The address remains valid until reprovisioned, that is, the preferred and valid
lifetimes of this address are infinite. The default value of this attribute is the
undefined address 0. (R, W) (mandatory) (16 bytes)
Default router: The manually provisioned IPv6 address of the default router. The default
value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Primary DNS: The manually provisioned IPv6 address of the primary DNS server. The
default value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Secondary DNS: The manually provisioned IPv6 address of the secondary DNS server. The
default value of this attribute is the undefined address 0. (R, W) (mandatory)
(16 bytes)
Current address table: This attribute is a list of the current IPv6 addresses of the IP host
service. The link-local address does not appear in this table. Each row of the
table is structured as follows:
IP address (16 bytes)
Preferred lifetime remaining, seconds (4 bytes)
Valid lifetime remaining, seconds (4 bytes)
If the manually provisioned IPv6 address attribute appears as the (only,
by necessity) entry of the table, its preferred and valid lifetimes are
infinite (0xFFFF FFFF).
Current default router table: This attribute lists the IPv6 addresses of the current default
routers. (R) (mandatory) (16N bytes)
Current DNS table: This attribute lists the IPv6 addresses of the current DNS servers. (R)
(mandatory) (16N bytes)
192
Rec. ITU-T G.988 (10/2012)
DUID:
This attribute is the DHCPv6 unique identifier. It is an octet string that must
be globally unique and must remain stable over the lifetime of the ONU. If
the string is shorter than 25 bytes, it must be null terminated. Its derivation is
beyond the scope of this Recommendation; see [b-IETF RFC 3315] for
further definition. (R) (mandatory) (25 bytes)
On-link prefix: This attribute is the manually provisioned on-link prefix used for
destination IPv6 addresses of IPv6 host services. The attribute is structured as
follows:
Prefix length, number of leading bits in the prefix that are valid (1 byte)
Prefix (16 bytes)
(R,W) (optional) (17 bytes)
Current on-link prefix table: In IPv6, an address is on a specific link if the address has
been assigned to an interface attached to that link. However, in order for a
node to know that a destination is on-link, it must obtain configuration
information to that effect. A host maintains a prefix list that identifies ranges
of addresses that are to be considered on-link ([b-IETF RFC 5942]). This
attribute is a list of current on-link prefixes used for destination IPv6
addresses of IPv6 host services. Entries in this table come from RA messages
received by the ONU from remote routers or manually provisioned to be onlink. Each row of the table is structured as follows:
Prefix length, number of leading bits in the prefix that are valid (1 byte)
Autonomous address-configuration flag byte. When set to 1, it indicates
that this prefix can be used for stateless address configuration as
specified in [b-IETF RFC 4862]; otherwise 0. (1 byte)
Prefix (16 bytes)
Preferred lifetime, seconds (4 bytes)
Valid lifetime, seconds (4 bytes)
If the manually provisioned on-link prefix attribute is present in the current
on-link prefix table, its preferred and valid lifetimes are infinite (0xFFFF
FFFF), and its autonomous address-configuration flag is 0.
(2 bytes)
The meaning and interpretation of the large string's contents are identical to
that described in the IP host config data definition in clause 9.4.1.
Actions
Get, get next, set
Test:
Invoke an ICMP message from this IP host. The test message can be
configured to generate a ping or traceroute. Annex A defines the test, test
response and test result messages.
Rec. ITU-T G.988 (10/2012)
193
Notifications
Number
1..8
Current address table
10
Current default router

table
11
Current DNS table
14
15..16
Description
N/A
12..13
9.5
AVC generated when a new address is added to the table,

or when an existing address becomes invalid and is
removed from the table. Countdown of the lifetime fields
does not generate AVCs.
N/A
Current on-link prefix
table
Reserved
Ethernet services
This clause defines the managed entities associated with physical and virtual Ethernet UNIs, as
shown in Figure 9.5-1.
Implicit links :
Extended VLAN tagging
operation config data
Pointed to by:
(Extended) VLAN tagging
operation config data
9.5.5: Virtual
Ethernet
interface point
Points to:
TCP/UDP config data
9.5.2: Ethernet PM
history data
9.5.1: PPTP
Ethernet UNI
9.5.3: Ethernet PM
history data 2
9.5.6: PoE control
9.5.4: Ethernet PM
history data 3
G.988(12)_F9.5-1
Figure 9.5-1 Managed entities associated with Ethernet UNIs

9.5.1
This managed entity represents the point at an Ethernet UNI where the physical path terminates and
Ethernet physical level functions are performed.
The ONU automatically creates an instance of this managed entity per port:
when the ONU has Ethernet ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the Ethernet type;
when a cardholder provisioned for plug-and-play is equipped with a circuit pack of the
Ethernet type. Note that the installation of a plug-and-play card may indicate the presence
of Ethernet ports via equipment ID as well as its type, and indeed may cause the ONU to
instantiate a port mapping package that specifies Ethernet ports.
The ONU automatically deletes instances of this managed entity when a cardholder is neither
provisioned to expect an Ethernet circuit pack, nor is it equipped with an Ethernet circuit pack.
194
Rec. ITU-T G.988 (10/2012)
Relationships
An instance of this managed entity is associated with each instance of a pre-provisioned or
real Ethernet port.
Attributes
This two-byte number indicates the physical position of the UNI. The first
byte is the slot ID (defined in clause 9.1.5). The second byte is the port ID,
with the range 1..255. (R) (mandatory) (2 bytes)
Expected type: This attribute supports pre-provisioning. It is coded as follows:
0
Autosense
1 to 254 One of the values from Table 9.1.5-1 that is compatible with an
Ethernet circuit pack
(1 byte)
Sensed type: When a circuit pack is present, this attribute represents its type as one of the
values from Table 9.1.5-1. If the value of the expected type is not 0, then the
value of the sensed type should be the same as the value of the expected type.
Upon ME instantiation, the ONU sets this attribute to 0. See also the note in
the Attribute value change table below.
(R) (mandatory if the ONU supports circuit packs with configurable interface
types, e.g., 10/100 BASE-T card) (1 byte)
Auto detection configuration: This attribute sets the Ethernet port configuration:
Code point
Rate
Duplex
0x00
Auto
Auto
0x01
10 Mbit/s only
Full duplex only
0x02
100 Mbit/s only
Full duplex only
0x03
1000 Mbit/s
only
Full duplex only
0x04
Auto
Full duplex only
0x05
10Gb/s only
Full duplex only
0x10
10 Mbit/s only
Auto
0x11
10 Mbit/s only
Half duplex only
0x12
100 Mbit/s only
Half duplex only
0x13
1000 Mbit/s
only
Half duplex only
0x14
Auto
Half duplex only
0x20
1000 Mbit/s
only
Auto
0x30
100 Mbit/s only
Auto
Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (mandatory

for interfaces with autodetection options) (1 byte)
Ethernet loopback configuration: This attribute sets the Ethernet loopback configuration:
0 No loopback
Rec. ITU-T G.988 (10/2012)
195
Loop 3, loopback of downstream traffic after PHY transceiver.

Loop 3 is depicted in Figure 9.5.1-1.
Note that normal bridge behaviour may defeat the loopback signal unless
broadcast MAC addresses are used. Although it does not reach the physical
interface, [IEEE 802.1ag] loopback is preferred.
(1 byte)
ONU
Ethernet UNI
PHY
transceiver
Loopback 3
PON
G.988(12)_F9.5.1-1
Figure 9.5.1-1 Ethernet loopback configuration

(optional) (1 byte)
Configuration ind: This attribute indicates the configuration status of the Ethernet UNI.
0x01 10BASE-T full duplex
0x02 100BASE-T full duplex
0x03 Gigabit Ethernet full duplex
0x04 10G Ethernet full duplex
0x11 10BASE-T half duplex
0x12 100BASE-T half duplex
0x13 Gigabit Ethernet half duplex
The value 0 indicates that the configuration status is unknown (e.g., Ethernet
link is not established or the circuit pack is not yet installed). Upon ME
instantiation, the ONU sets this attribute to 0. (R) (mandatory) (1 byte)
Max frame size: This attribute denotes the maximum frame size allowed across this
interface. Upon ME instantiation, the ONU sets the attribute to 1518. (R, W)
(mandatory for G-PON, optional for ITU-T G.986 systems) (2 bytes)
DTE or DCE ind: This attribute specifies the Ethernet interface wiring:
0 DCE or MDI-X (default).
1 DTE or MDI.
2 Automatic selection
Pause time:
196
This attribute allows the PPTP to ask the subscriber terminal to temporarily
suspend sending data. Units are in pause quanta (1 pause quantum is 512 bit
times of the particular implementation). Values: 0..0xFFFF. Upon ME
instantiation, the ONU sets this attribute to 0. (R, W) (optional) (2 bytes)
Rec. ITU-T G.988 (10/2012)
Bridged or IP ind: This attribute specifies whether the Ethernet interface is bridged or
derived from an IP router function.
0 Bridged
1 IP router
2 Depends on the parent circuit pack. 2 means that the circuit pack's
bridged or IP ind attribute is either 0 or 1.
Upon ME instantiation, the ONU sets this attribute to 2. (R, W) (optional)
(1 byte)
ARC:

PPPoE filter: This attribute controls filtering of PPPoE packets on this Ethernet port. The
value 0 allows packets of all types. The value 1 discards everything but
PPPoE packets. The default value is 0. (R, W) (optional) (1 byte)
Power control: This attribute controls whether power is provided to an external equipment
over the Ethernet PPTP. The value 1 enables power over the Ethernet port.
The default value 0 disables power feed. (R, W) (optional) (1 byte)
NOTE This attribute is the equivalent of the acPSEAdminControl variable defined
in [IEEE 802.3] clause 30.9.1.2.1. Other variables related to power over Ethernet
appear in the PoE control ME.
Actions
Get, set
Notifications
Number
N/A
Sensed type
3..5
6
Sensed type of Ethernet interface. Valid values are:

1 (10BASE-T),
2 (100BASE-T),
3 (Gigabit Ethernet) and
4 (10G Ethernet).
(Note)
N/A
Op state
7..11
N/A
12
ARC
13..15
N/A
16
Description
Operational state
Reserved
NOTE These values violate the rules of the AVC message, which require the changed value of the
sensed type (in this case) attribute to be reported. Because of existing implementations, pre-existing
documentation is retained; however, implementers should regard this attribute and its AVC with
caution.
Rec. ITU-T G.988 (10/2012)
197
Alarm
Alarm
number
0
LAN-LOS
1..207
Reserved
208..223
9.5.2
Alarm
Description
No carrier at the Ethernet UNI
Ethernet performance monitoring history data
This managed entity collects some of the performance monitoring data for a physical Ethernet
interface. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an instance of the physical path
termination point Ethernet UNI.
Attributes
instance of the physical path termination point Ethernet UNI. (R,
FCS errors: This attribute counts frames received on a particular interface that were an
integral number of octets in length but failed the frame check sequence (FCS)
check. The count 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
according to the error status presented to the LLC. (R) (mandatory) (4 bytes)
Excessive collision counter: This attribute counts frames whose transmission failed due to
excessive collisions. (R) (mandatory) (4 bytes)
Late collision counter: This attribute counts the number of times that a collision was
detected later than 512 bit times into the transmission of a packet. (R)
Frames too long: This attribute counts received frames that exceeded the maximum
permitted frame size. The count is incremented when the MAC service
returns the frameTooLong status to the LLC. (R) (mandatory) (4 bytes)
Buffer overflows on receive: This attribute counts the number of times that the receive
buffer overflowed. (R) (mandatory) (4 bytes)
Buffer overflows on transmit: This attribute counts the number of times that the transmit
buffer overflowed. (R) (mandatory) (4 bytes)
198
Rec. ITU-T G.988 (10/2012)
Single collision frame counter: This attribute counts successfully transmitted frames whose
transmission was delayed by exactly one collision. (R) (mandatory) (4 bytes)
Multiple collisions frame counter: This attribute counts successfully transmitted frames
whose transmission was delayed by more than one collision. (R) (mandatory)
(4 bytes)
SQE counter: This attribute counts the number of times that the SQE test error message
was generated by the PLS sublayer. (R) (mandatory) (4 bytes)
Deferred transmission counter: This attribute counts frames whose first transmission
attempt was delayed because the medium was busy. The count does not
include frames involved in collisions. (R) (mandatory) (4 bytes)
Internal MAC transmit error counter: This attribute counts frames whose transmission
failed due to an internal MAC sublayer transmit error. (R) (mandatory)
(4 bytes)
Carrier sense error counter: This attribute counts the number of times that carrier sense
was lost or never asserted when attempting to transmit a frame. (R)
Alignment error counter: This attribute counts received frames that were not an integral
number of octets in length and did not pass the FCS check. (R) (mandatory)
(4 bytes)
Internal MAC receive error counter: This attribute counts frames whose reception failed
due to an internal MAC sublayer receive error. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
FCS errors
Excessive collision counter
Late collision counter
Frames too long
Buffer overflows on receive
Buffer overflows on transmit
Single collision frame counter
Multiple collisions frame counter
SQE counter
Deferred transmission counter
10
10
Internal MAC transmit error counter
11
11
Carrier sense error counter
12
Rec. ITU-T G.988 (10/2012)
199
12
Alignment error counter
13
13
Internal MAC receive error counter
14
9.5.3
Ethernet performance monitoring history data 2
This managed entity collects additional performance monitoring data for a physical Ethernet
interface. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this Ethernet performance monitoring history data 2 managed entity is
associated with an instance of the physical path termination point Ethernet UNI.
Attributes
instance of the physical path termination point Ethernet UNI. (R,
PPPoE filtered frame counter: This attribute counts the number of frames discarded due to
PPPoE filtering. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
0

PPPoE filtered frame counter

1
9.5.4
This managed entity collects performance monitoring data associated with an Ethernet interface. It
includes parameters defined in the Ethernet statistics group of [IETF RFC 2819] that are not already
covered by previously defined Ethernet monitoring MEs. The received direction is from the CPE
towards the network (upstream).
NOTE 1 Several of the same counters are available from the Ethernet frame performance monitoring
history data managed entities, which are associated with MAC bridge ports. MAC bridge port association
200
Rec. ITU-T G.988 (10/2012)
allows those MEs to be used for any Ethernet flow, in both upstream and downstream directions, while the
Ethernet PM history data 3 ME can only be used on a physical IEEE 802.3 port.
NOTE 2 Implementers are encouraged to consider the Ethernet frame extended PM ME defined in
clause 9.3.32, which collects the same counters in a more generalized way.
Relationships
An instance of this managed entity is associated with an instance of the physical path
termination point Ethernet UNI.
Attributes
instance of the PPTP Ethernet UNI. (R, Set-by-create) (mandatory) (2 bytes)
Drop events: The total number of events in which packets were dropped due to a lack of
resources. This is not necessarily the number of packets dropped; it is the
Octets:
The total number of octets received from the CPE, including those in bad
packets, excluding framing bytes, but including FCS. (R) (mandatory)
(4 bytes)
Packets:
The total number of packets received, including bad packets, broadcast

packets and multicast packets. (R) (mandatory) (4 bytes)
Broadcast packets: The total number of received good packets directed to the broadcast
address. This does not include multicast packets. (R) (mandatory) (4 bytes)
Multicast packets: The total number of received good packets directed to a multicast
address. This does not include broadcast packets. (R) (mandatory) (4 bytes)
Undersize packets: The total number of packets received that were less than 64 octets long
but were otherwise well formed (excluding framing bits, but including FCS).
Fragments:
The total number of packets received that were less than 64 octets long,
excluding framing bits but including FCS octets, and had either a bad frame
check sequence (FCS) with an integral number of octets (FCS error) or a bad
FCS with a non-integral number of octets (alignment error). It is entirely
normal for this attribute to increment. This is because it counts both runts
(which are normal occurrences due to collisions) and noise hits. (R)
Jabbers:
The total number of packets received that were longer than 1518 octets,
excluding framing bits but including FCS octets, and had either a bad frame
check sequence (FCS) with an integral number of octets (FCS error) or a bad
Rec. ITU-T G.988 (10/2012)
201
FCS with a non-integral number of octets (alignment error). The range to

detect jabber is between 20 ms and 150 ms. (R) (mandatory) (4 bytes)
Packets 64 octets: The total number of received packets (including bad packets) that were
64 octets long, excluding framing bits but including FCS. (R) (mandatory)
(4 bytes)
Packets 65 to 127 octets: The total number of received packets (including bad packets) that
Packets 128 to 255 octets: The total number of packets (including bad packets) received
that were 128..255 octets long, excluding framing bits but including FCS. (R)
that were 256..511 octets long, excluding framing bits but including FCS. (R)
Actions
Notifications
Alarm
number
Drop events
Undersize packets
Fragments
Jabbers
9.5.5
This managed entity represents the data plane hand-off point in an ONU to a separate (non-OMCI)
management domain. The virtual Ethernet interface point is managed by the OMCI, and is
potentially known to the non-OMCI management domain. One or more Ethernet traffic flows are
present at this boundary.
Instances of this managed entity are automatically created and deleted by the ONU. This is
necessary because the required downstream priority queues are subject to physical implementation
constraints. The OLT may use one or more of the virtual Ethernet interface points created by the
ONU.
202
Rec. ITU-T G.988 (10/2012)
It is expected that the ONU would create one virtual Ethernet interface point for each non-OMCI
management domain. At the vendor's discretion, a virtual Ethernet interface point may be created
for each traffic class.
Relationships
An instance of this managed entity is associated with an instance of a virtual Ethernet
interface between OMCI and non-OMCI management domains.
Attributes
When used independently of a cardholder and circuit pack, the ONU should
assign IDs in the sequence 1, 2, .... When used in conjunction with a
cardholder and circuit pack, this two-byte number indicates the physical
position of the VEIP. The first byte is the slot ID (defined in clause 9.1.5).
The second byte is the port ID, with the range 1..255. The values 0 and
0xFFFF are reserved. (R) (mandatory) (2 bytes)
(optional) (1 byte)
Interdomain name: This attribute is a character string that provides an optional way to
identify the virtual Ethernet interface point to a non-OMCI management
domain. The interface may also be identified by its managed entity ID, IANA
assigned port and possibly other ways. If the vendor offers no information in
this attribute, it should be set to a sequence of null bytes. (R, W) (optional)
(25 bytes)
TCP/UDP pointer: This attribute points to an instance of the TCP/UDP config data
managed entity, which provides for OMCI management of the non-OMCI
management domain's IP connectivity. If no OMCI management of the nonOMCI domain's IP connectivity is required, this attribute may be omitted or
set to its default, a null pointer. (R, W) (optional) (2 bytes)
IANA assigned port: This attribute contains the TCP or UDP port value as assigned by
IANA for the management protocol associated with this virtual Ethernet
interface. This attribute is to be regarded as a hint, not as a requirement that
management communications use this port; the actual port and protocol are
specified in the associated TCP/UDP config data managed entity. If no port
has been assigned, or if the management protocol is free to be chosen at runtime, this attribute should be set to 0xFFFF. (R) (mandatory) (2 bytes)
Actions
Get, set
Notifications
Number
0..1
2
Description
N/A
Op state
Operational state
Rec. ITU-T G.988 (10/2012)
203
3
4..16
N/A
Reserved
Alarm
Alarm
number
Alarm
Description
Connecting function fail
Indicates a failure of the connecting function. May be used to

signal faults from the non-OMCI management domain into
the OMCI.
1..207
208..223
9.5.6
Reserved
Power over Ethernet (PoE) control
This managed entity represents the ability to monitor and control the power over Ethernet capability
of the ONU as power-sourcing equipment (PSE) as defined in [IEEE 802.3] clauses 30.9 and 33.
An ONU that supports the enhanced PoE control feature automatically creates or deletes an instance
of this managed entity whenever it creates or deletes the corresponding PPTP Ethernet UNI.
Administrative control of the PoE feature resides in the power control attribute of the PPTP
Ethernet UNI ME.
Relationships
An instance of this managed entity is associated with each instance of a PPTP Ethernet UNI.
Attributes
instance of the physical path Ethernet UNI managed entity. (R) (mandatory)
(2 bytes)
PoE capabilities: This attribute is a bit map that identifies the PoE capabilities of the port.
Bits are assigned as follows:
Bit
Meaning
1 (LSB) When this bit is 1, the PSE pinout alternative may be changed
through the power pair pinout control attribute. When the bit is
0, the PSE pinout alternative is fixed, and is described by the
power pair pinout control attribute.
2..16
Reserved
Power pair pinout control: If the PSE pinout is configurable, according to the PoE
capabilities attribute, this attribute is used to configure the pinout. If the PSE
pinout is fixed, this attribute is read-only. In either case, the value returned by
a get operation indicates the actual configuration. The value 0
configures/indicates pinout alternative A (signal pairs); the value 1
configures/indicates pinout alternative B (spare pairs). Other values are
reserved. This attribute corresponds to the aPSEPowerPairs variable defined
in [IEEE 802.3]. (R, W) (mandatory) (1 byte)
204
Rec. ITU-T G.988 (10/2012)
Operational state: This attribute indicates whether or not the PPTP is capable of
Power detection status: This attribute is an enumeration that returns the current status of
the port. It corresponds to the aPSEPowerDetectionStatus variable defined in
[IEEE 802.3]. Its values are defined as follows:
0 PSE disabled
1 PSE searching
2 PSE delivering power
3 PSE test mode
4 PSE fault detected
5 PSE implementation specific fault detected
Power classification status: This attribute is an enumeration that indicates the PD class of a
detected PD. It is only valid when the power detection status attribute
indicates PSE delivering power. The attribute corresponds to the
aPSEPowerClassification variable defined in [IEEE 802.3]. Its values are
defined as follows:
0 Undefined or feature not supported
1 Class 0 PD
2 Class 1 PD
3 Class 2 PD
4 Class 3 PD
5 Class 4 PD
Power priority: This attribute controls the priority of the port from the point of view of a
power management algorithm. The priority that is set by this attribute could
be used by a control mechanism that prevents overcurrent situations by first
disconnecting ports with lower power priority (higher numerical value). The
attribute corresponds to the pethPsePortPowerPriority variable defined in
[b-IETF RFC 3621]. Valid values are
1 critical
2 high
3 low
Invalid signature counter: This attribute increments when the [IEEE 802.3] Figure 33-6
PoE state machine enters the signature_invalid state, but not more than twice
per second. The counter is never explicitly reset, but its value is not required
to persist over ONU initialization. (R) (optional) (2 bytes)
Power denied counter: This attribute increments when the [IEEE 802.3] Figure 33-6 PoE
state machine enters the power_denied state, but not more than twice per
second. The counter is never explicitly reset, but its value is not required to
persist over ONU initialization. (R) (optional) (2 bytes)
Overload counter: This attribute increments when the [IEEE 802.3] Figure 33-6 PoE state
machine enters the error_delay_over state, but not more than twice per
Rec. ITU-T G.988 (10/2012)
205
Short counter: This attribute increments when the [IEEE 802.3] Figure 33-6 PoE state
machine enters the error_delay_short state, but not more than twice per
MPS absent counter: This attribute increments when the [IEEE 802.3] Figure 33-6 PoE
state machine goes from the state power_on to the idle state, but not more
than twice per second. The counter is never explicitly reset, but its value is
not required to persist over ONU initialization. (R) (optional) (2 bytes)
PsE class control: This attribute may be used to place specific limits on the class of power
supported by this port. Valid code points for this attribute are:
0 Power feed enabled at the default level for this port
1 Power feed enabled at the class 0 power level
Other values are reserved. (R, W) (optional) (1 byte)
Actions
Get, set
Notifications
Number
1..2
3
Description
N/A
Operational state
4..12
N/A
13..16
Reserved
9.6
9.7
xDSL services
This clause defines managed entities associated with physical xDSL UNIs, as shown in
Figure 9.7-1.
206
Rec. ITU-T G.988 (10/2012)
Pointed to by:
VP network CTP
(Extended) VLAN tagging operation config data
9.7.3: xDSL line config
profile part 1
9.7.4: Part 2
9.7.5: Part 3
9.7.6: VDSL2 line config
extensions
9.7.26: VDSL2 line config
extensions 2
9.7.10: xDSL PSD mask

profile
9.7.1: PPTP xDSL

UNI part 1
9.7.2: Part 2
9.7.12: xDSL line

inventory and
status data part 1
9.7.13: Part 2
9.7.14: Part 3
9.7.15: Part 4
9.7.16: VDSL2 line
inventory and
status data part 1
9.7.17: Part 2
9.7.18: Part 3
9.7.19: xDSL channel

downstream status
data
9.7.20: xDSL channel

upstream status
data
9.7.21: xDSL xTU-C
PM history data
9.7.22: xDSL xTU-R

PM history data
9.7.23: xDSL xTU-C

channel PM
history data
9.7.24: xDSL xTU-R

channel PM
history data
N
N 9.7.7: xDSL channel
config profile
9.7.11: xDSL
downstream RFI
bands profile
9.7.8: xDSL subcarrier

masking downstream
profile
N 9.7.9: xDSL subcarrier

masking upstream
profile
9.7.25: TC adaptor
PM history data
9.7.27: xDSL
impulse noise
PM history data
G.988(12)_F9.7-1
Figure 9.7-1 Managed entities associated with xDSL services

NOTE This clause is based on [ITU-T G.997.1]. In comparison to their [ITU-T G.997.1] equivalents,
ITU-T G.988 descriptions frequently appear in condensed or summarized form. To avoid rendering existing
implementations non-standard, the OMCI always defines new attributes added to existing managed entities
to be optional, even though [ITU-T G.997.1] may specify that the new attributes are mandatory. When the
OMCI defines a new managed entity, however, it follows [ITU-T G.997.1]. Furthermore, [ITU-T G.997.1]
sometimes calls out different requirements for different xDSL Recommendations, which may or may not be
completely captured in clause 9.7. Finally, [ITU-T G.997.1] is itself subject to revision as xDSL standards
evolve.
Users of this Recommendation are therefore encouraged to consult the current version of [ITU-T G.997.1]
for further details.
9.7.1
This managed entity represents the point where physical paths terminate on an xDSL CO modem
(xTU-C). The xDSL managed entity family is used for ADSL and VDSL2 services. A legacy
family of VDSL managed entities remains valid for [ITU-T G.993.1] VDSL, if needed. It is
documented in [ITU-T G.983.2].
when the ONU has xDSL ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the xDSL type;
xDSL type. Note that the installation of a plug-and-play card may indicate the presence of
xDSL ports via equipment ID as well as its type, and indeed may cause the ONU to
instantiate a port mapping package that specifies xDSL ports.
Rec. ITU-T G.988 (10/2012)
207
provisioned to expect an xDSL circuit pack, nor is it equipped with an xDSL circuit pack.
Relationships
An instance of this managed entity is associated with each instance of a real or preprovisioned xDSL port.
Attributes
This two-byte number indicates the physical position of the UNI. The six
least significant bits of the first byte are the slot ID, defined in clause 9.1.5.
The two most significant bits indicate the channel number in some of the
implicitly linked MEs, and must be 0 in the PPTP itself. This reduces the
possible number of physical slots to 64. The second byte is the port ID, with
the range 1..255. (R) (mandatory) (2 bytes)
Loopback configuration: This attribute represents the loopback configuration of this
physical interface.
0 No loopback
1 Loopback2 a loopback at the ONU towards the OLT. The OLT can
execute a physical level loopback test after loopback2 is set.
(1 byte)
(optional) (1 byte)
xDSL line configuration profile: This attribute points to an instance of the xDSL line
configuration profiles (part 1, 2 and 3) managed entities, and if necessary,
also to VDSL2 line configuration extensions (1 and 2) MEs. Upon ME
instantiation, the ONU sets this attribute to 0, a null pointer. (R, W)
xDSL subcarrier masking downstream profile: This attribute points to an instance of the
xDSL subcarrier masking downstream profile managed entity. Upon ME
xDSL subcarrier masking upstream profile: This attribute points to an instance of the
xDSL subcarrier masking upstream profile managed entity. Upon ME
xDSL downstream PSD mask profile: This attribute points to an instance of the xDSL
PSD mask profile managed entity that defines downstream parameters. Upon
ME instantiation, the ONU sets this attribute to 0, a null pointer. (R, W)
xDSL downstream RFI bands profile: This attribute points to an instance of the xDSL
downstream RFI bands profile managed entity. Upon ME instantiation, the
ONU sets this attribute to 0, a null pointer. (R, W) (mandatory) (2 bytes)
208
Rec. ITU-T G.988 (10/2012)
ARC:

Modem type: This attribute specifies the modem type. If the hardware cannot support the
requested modem type, the ONU should deny the provisioning command. For
backward compatibility, the attribute is optional, with a default of ATM.
0 undefined
1 ATM (default)
2 PTM (Ethernet)
NOTE Many newer VDSL2 chip sets support only PTM. The ATM default is
retained for backward compatibility, but implementers should be aware that the
default may need to be overridden by provisioning before the xDSL UNI can be
brought into service.
Upstream PSD mask profile: This attribute points to an instance of the xDSL PSD mask
profile that defines upstream parameters. Upon ME instantiation, the ONU
sets this attribute to 0, a null pointer. (R, W) (optional) (2 bytes)
Network specific extensions pointer: This attribute points to a network address managed
entity that contains the path and name of a file containing network specific
parameters for the associated UNI. Upon ME instantiation, the ONU sets this
attribute to 0xFFFF, a null pointer. (R, W) (optional) (2 bytes)
Actions
Get, set
Notifications
Number
1..2
3
Description
N/A
Op state
4..8
N/A
ARC
10..12
N/A
13..16
Reserved
Operational state
Alarm
Alarm
number
Alarm
Description
NE LOF
Near-end loss of frame
NE LOS
Near-end loss of signal
NE LOL
Near-end loss of link
NE LPR
Near-end loss of power
Card alm
Card in alarm
FE LOF
Far-end loss of frame
FE LOS
Far-end loss of signal
FE LOL
Far-end loss of link

Rec. ITU-T G.988 (10/2012)
209
FE LPR
Far-end loss of power
DRT up
Data rate threshold upshift (Note 1)
10
DRT down
Data rate threshold downshift (Note 1)
11
LINIT
Line initialization failure
12
LCD
Loss of cell delineation, near end (Note 2)
13
NCD
No cell delineation, near end (Note 2)
14
LCD-FE
Loss of cell delineation, far end (Note 2)
15
NCD-FE
No cell delineation, far end (Note 2)
16
File not found
The PPTP xDSL UNI attempted to access a network

specific extensions file that is not available.
17.207
Reserved
NOTE 1 The data rate upshift and downshift alarms are deprecated. They are not defined in
[ITU-T G.997.1].
NOTE 2 These alarms are meaningful only for ATM transport. The alarms may be declared
against the UNI itself, or against one of the bearer channels. In the latter case, the two MSBs of the
instance identifier in the alarm message specify the bearer channel.
9.7.2
This managed entity represents the point in the ONU where physical paths terminate on an xDSL
CO modem (xTU-C). Standards and chip sets support several forms of DSL, including VDSL2, and
the xDSL managed entity family is used for all of them, with specific extensions for technology
variations.
The ONU creates or deletes an instance of this managed entity at the same time it creates or deletes
the corresponding PPTP xDSL UNI part 1.
Relationships
An instance of this managed entity is associated with each instance of a physical path
termination point xDSL UNI part 1.
Attributes
instance of the physical path termination point xDSL UNI part 1. (R)
Each of the following eight attributes is a pointer to an xDSL channel configuration profile
managed entity. In each case, the default value 0, set when the ME is auto-created, is a null pointer.
xDSL channel configuration profile for bearer channel 0 downstream:
xDSL channel configuration profile for bearer channel 0 upstream:
210
Rec. ITU-T G.988 (10/2012)

Actions
Get, set
Notifications
None.
9.7.3
xDSL line configuration profile part 1
The overall xDSL line configuration profile is modelled in several parts, all of which are associated
together through a common managed entity ID (the client physical path termination point xDSL
UNI part 1 has a single pointer, which refers to the entire set of line configuration profile parts).
It is worth noting that attributes in the line configuration profile family affect the real-time service
delivery of an xDSL UNI, for example, by triggering diagnostics. Despite the fact that they are
called profiles, it may be advisable to instantiate a complete set of these MEs for each PPTP xDSL
UNI.
Relationships
An instance of this managed entity may be associated with zero or more instances of an
xDSL UNI.
Attributes
The value 0 is reserved. All xDSL and VDSL2 line configuration profiles and
extensions that pertain to a given physical path termination point xDSL UNI
must share a common managed entity ID. (R, Set-by-create) (mandatory)
xTU transmission system enabling (xTSE): This configuration attribute specifies the
transmission system coding types to be allowed by the near-end xTU. It is a
bit map as defined in Table 9.7.12-1. (R, W, Set-by-create) (mandatory)
(7 bytes)
NOTE 1 This attribute is only 7 bytes long. An eighth byte enabling VDSL2
capabilities is defined in the VDSL2 transmission system enabling attribute of the
xDSL line configuration profile part 2 managed entity.
Power management state forced: This configuration parameter forces the line state of the
near-end xTU. It is coded as an integer value with the following definition:
0 Force the line 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 enter into or exit from the L2 low power
state if the 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, an initialization failure occurs.
Whenever the line is in the L3 state, it attempts to transition to the L0
state until it is forced into another state through this configuration
parameter.
Rec. ITU-T G.988 (10/2012)
211
Force the line from the L0 full-on to the L2 low power state. This is
an out-of-service test value for triggering the L2 mode.
3 Force the line 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 remains there until it is forced into
another state through this configuration parameter.
Power management state enabling: The PMMode attribute specifies the line states into
which the xTU-C or xTU-R may autonomously go. It is a bit map (0 if not
allowed, 1 if allowed) with the following definition:
Bit 1 (LSB): L3 idle state
Bit 2:
L1/L2 low power state
Downstream target noise margin: This attribute specifies the noise margin the xTU-R
receiver must achieve, relative to the BER requirement for each of the
downstream bearer channels, to successfully complete initialization. Its value
ranges from 0 (0.0 dB) to 310 (31.0 dB). (R, W, Set-by-create) (mandatory)
(2 bytes)
Upstream target noise margin: This attribute specifies the noise margin the xTU-C
receiver must achieve, relative to the BER requirement for each of the
upstream bearer channels, to successfully complete initialization. Its value
ranges from 0 (0.0 dB) to 310 (31.0 dB). (R, W, Set-by-create) (mandatory)
(2 bytes)
Downstream maximum noise margin: The MAXSNRMds attribute specifies the
maximum noise margin the xTU-R receiver tries to sustain. If the noise
margin is above this level, the xTU-R requests the xTU-C to reduce its
transmit power, if this functionality is supported by the pertinent xDSL
Recommendation. Its value ranges from 0 (0.0 dB) to 310 (31.0 dB). The
special value 0xFFFF indicates that the maximum noise margin limit is
unbounded. (R, W, Set-by-create) (mandatory) (2 bytes)
Upstream maximum noise margin: The MAXSNRMus attribute specifies the maximum
noise margin the xTU-C receiver tries to sustain. If the noise margin is above
this level, the xTU-C requests the xTU-R to reduce its transmit power, if this
functionality is supported by the pertinent xDSL Recommendation. Its value
ranges from 0 (0.0 dB) to 310 (31.0 dB). The special value 0xFFFF indicates
that the maximum noise margin limit is unbounded. (R, W, Set-by-create)
Downstream minimum noise margin: This attribute specifies the minimum noise margin
the xTU-R receiver must tolerate. If the noise margin falls below this level,
the xTU-R requests the xTU-C to increase its transmit power. If an increase
in xTU-C transmit power is not possible, a loss-of-margin (LOM) defect
occurs, the xTU-R fails and attempts to re-initialize, and the PPTP declares a
line initialization failure (LINIT) alarm. Its value ranges from 0 (0.0 dB) to
310 (31.0 dB). (R, W, Set-by-create) (mandatory) (2 bytes)
Upstream minimum noise margin: This attribute specifies the minimum noise margin the
xTU-C receiver must tolerate. If the noise margin falls below this level, the
xTU-C requests the xTU-R to increase its transmit power. If an increase in
xTU-R transmit power is not possible, a loss-of-margin (LOM) defect occurs,
212
Rec. ITU-T G.988 (10/2012)
the xTU-C fails and attempts to re-initialize, and the PPTP declares a line
initialization failure (LINIT) alarm. Its value ranges from 0 (0.0 dB) to 310
(31.0 dB). (R, W, Set-by-create) (mandatory) (2 bytes)
Downstream rate adaptation mode: The RA-MODEds attribute specifies the mode of
operation of a rate-adaptive xTU-C in the transmit direction. The parameter
can take four values.
1 Mode 1: MANUAL Rate changed manually.
At start-up:
The minimum data rate attribute of the associated xDSL channel
configuration profile specifies the minimum required data rate for
each downstream bearer channel, with a noise margin that is at least
as large as the specified downstream target noise margin, relative to
the required BER for each of the downstream bearer channels. If the
xTU-C fails to achieve the minimum data rate for any of the
downstream bearer channels, the xTU-C fails to initialize and the
PPTP declares a line initialization failure (LINIT) alarm. Although
the xTU-C and the line might be able to support a higher data rate, the
xTU-C does not transmit a higher data rate than is requested.
At showtime:
The xTU-C transmitter maintains the specified minimum data rate for
each of the bearer channels.
2 Mode 2: AT_INIT Rate automatically selected at start-up only; rate
does not change after that.
At start-up:
The minimum data rate attribute of the associated xDSL channel
configuration profile specifies the minimum required data rate for
each downstream bearer channel, with a noise margin that is at least
as large as the specified downstream target noise margin, relative to
the required BER for each of the downstream bearer channels. If the
xTU-C fails to achieve the minimum data rate for any of the
downstream bearer channels, the xTU-C fails to initialize and the
PPTP declares a line initialization failure (LINIT) alarm. If the
xTU-C transmitter is able to support a higher downstream data rate at
initialization, the excess data rate is distributed among the
downstream bearer channels according to the weight specified by the
rate adaptation ratio attribute of each bearer channel. When the
maximum data rate is achieved in one of the downstream bearer
channels, the remaining excess rate is assigned to the other bearer
channels, still according to their relative rate adaptation ratios. As
long as the downstream data rate is below the downstream maximum
data rate for one of the bearer channels, data rate increase takes
priority over transmit power reduction.
At showtime:
During showtime, no downstream data rate adaptation is allowed. The
downstream data rate, determined during initialization for each bearer
channel, is maintained.
Rec. ITU-T G.988 (10/2012)
213
3 Mode 3: DYNAMIC Data rate is automatically selected at

initialization and is continuously adapted during showtime. The dynamic rate
adaptation mode is optional. All related configuration parameters are also
optional.
At start-up:
The xTU-C starts up as in mode 2.
At showtime:
During showtime, rate adaptation is allowed according to the rate
adaptation ratios for distributing the excess data rate amongst the
bearer channels, as described in mode 2. 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:
An upshift action is allowed when the downstream
noise margin is above the downstream upshift noise
margin during the downstream minimum time interval
for upshift rate adaptation (i.e., upon RAU anomaly).
A downshift action is allowed when the downstream
noise margin is below the downstream downshift noise
margin during the downstream minimum time interval
for downshift rate adaptation (i.e., upon RAD
anomaly).
As long as the downstream data rate is below the maximum data rate
for one of the downstream bearer channels, data rate increase takes
priority over transmit power reduction.
In ITU-T G.993.2 start-up, if it is detected that SRA is supported in
the downstream direction by neither xTU, the xTUs fall back to mode
2.
4 Mode 4: DYNAMIC with SOS Data rate is automatically selected at
initialization and is continuously adapted during showtime by SOS and SRA.
Rate adaptation mode 4 is optional, but if it is selected, enabling of SOS and
SRA is mandatory. This mode is defined only in [ITU-T G.993.2].
At start-up:
The xTU-C starts up as in mode 2.
At showtime:
SRA behaviour is the same as described for mode 3, unless the actual
net data rate is below the minimum net data rate as a result of an SOS
procedure.
Additionally, SOS may be performed when the conditions specified
by the SOS trigger parameters are satisfied. The detailed specification
of the SOS OLR procedure appears in [ITU-T G.993.2].
214
Rec. ITU-T G.988 (10/2012)
If at start-up, it is detected that SOS is supported in the downstream

direction by neither xTU, but SRA is supported by both xTUs, the
xTUs fall back to mode 3.
If at start-up, it is detected that neither SOS nor SRA are supported in
the downstream direction by both xTUs, the xTUs fall back to
mode 2.
Upstream rate adaptation mode: The RA-MODEus attribute specifies the mode of
operation of a rate-adaptive xTU-R in the transmit direction. The parameter is
used only if rate-adaptive functionality is supported. It can take four values:
1 MANUAL
2 AT_INIT
3 DYNAMIC
4 DYNAMIC with SOS
The definition of each of the values is identical to its definition in the
downstream rate adaptation mode, replacing xTU-C with xTU-R and
downstream with upstream. (R, W, Set-by-create) (mandatory) (1 byte)
Downstream upshift noise margin: If the downstream noise margin is above the
downstream upshift noise margin and remains there for more than the time
specified by the downstream minimum time interval for upshift rate
adaptation, the xTU-R attempts to increase the downstream net data rate.
This attribute ranges from 0 (0.0 dB) to 310 (31.0 dB). (R, W, Set-by-create)
Upstream upshift noise margin: If the upstream noise margin is above the upstream
upshift noise margin and remains there for more than the time specified by
the upstream minimum time interval for upshift rate adaptation, the xTU-C
attempts to increase the upstream net data rate. This attribute ranges from 0
(0.0 dB) to 310 (31.0 dB). (R, W, Set-by-create) (optional) (2 bytes)
Upstream PSD mask selection: This attribute enables one of several upstream PSD masks.
It is used only for Annexes J and M of [ITU-T G.992.3] and
[ITU-T G.992.5]. The same mask selection applies to all relevant modes
enabled in the xTSE line configuration parameter (Table 9.7.12-1). This
attribute selects the mask with the following definition:
Annex J of ITU-T G.992.3, .5
Annex M of ITU-T G.992.3, .5
ADLU-32
EU-32
ADLU-36
EU-36
ADLU-40
EU-40
ADLU-44
EU-44
ADLU-48
EU-48
ADLU-52
EU-52
ADLU-56
EU-56
ADLU-60
EU-60
ADLU-64
EU-64
Rec. ITU-T G.988 (10/2012)
215
Minimum overhead rate upstream: This attribute specifies the minimum rate of the
message based overhead to be maintained by the xTU in the upstream
direction. MSGMINus ranges from 4000 to 248 000 bit/s. The value 0
specifies that the ONU use its internal default. This attribute is only valid for
[ITU T G.992.3], [ITU T G.992.4], [ITU T G.992.5] and [ITU-T G.993.2].
NOTE 2 For compatibility with previous versions of the OMCI, values between
4000 and 65535 are interpreted as bits per second. To align with [ITU-T G.997.1],
values between 4 and 248 are interpreted as kilobits per second. For maximum
flexibility, the ONU should support both conventions.
Minimum overhead rate downstream: This attribute specifies the minimum rate of the
message based overhead to be maintained by the xTU in the downstream
direction. MSGMINds ranges from 4000 to 248 000 bit/s. The value 0
specifies that the ONU use its internal default. This attribute is only valid for
[ITU-T G.992.3], [ITU T G.992.4], [ITU T G.992.5] and [ITU-T G.993.2].
NOTE 3 For compatibility with previous versions of the OMCI, values between
4000 and 65535 are interpreted as bits per second. To align with [ITU-T G.997.1],
values between 4 and 248 are interpreted as kilobits per second. For maximum
flexibility, the ONU should support both conventions.
Actions
Notifications
None.
9.7.4
Relationships
xDSL UNI.
Attributes
All xDSL and VDSL2 line configuration profiles and extensions that pertain
to a given physical path termination point xDSL UNI must share a common
managed entity ID. (R, Set-by-create) (mandatory) (2 bytes)
Downstream minimum time interval for upshift rate adaptation: This parameter defines
the interval during which the downstream noise margin must remain above
the downstream upshift noise margin before the xTU-R attempts to increase
the downstream net data rate. Its value ranges from 0 to 16383 seconds.
Upstream minimum time interval for upshift rate adaptation: This parameter defines the
interval during which the upstream noise margin must remain above the
upstream upshift noise margin before the xTU-C attempts to increase the
upstream net data rate. Its value ranges from 0 to 16383 seconds. (R, W,
216
Rec. ITU-T G.988 (10/2012)
Downstream downshift noise margin: If the downstream noise margin is below the
downstream downshift noise margin and remains there for more than the
downstream minimum time interval for downshift rate adaptation, the xTU-R
attempts to decrease the downstream net data rate. This attribute's value
ranges from 0 (0.0 dB) to 310 (31.0 dB). (R, W, Set-by-create) (optional)
(2 bytes)
Upstream downshift noise margin: If the upstream noise margin is below the upstream
downshift noise margin and remains there for more than the upstream
minimum time interval for downshift rate adaptation, the xTU-C attempts to
decrease the upstream net data rate. This attribute's value ranges from 0 (0.0
dB) to 310 (31.0 dB). (R, W, Set-by-create) (optional) (2 bytes)
Downstream minimum time interval for downshift rate adaptation: This parameter
defines the interval during which the downstream noise margin must remain
below the downstream downshift noise margin before the xTU-R attempts to
decrease the downstream net data rate. Its value ranges from 0 to 16383
seconds. (R, W, Set-by-create) (optional) (2 bytes)
Upstream minimum time interval for downshift rate adaptation: This parameter defines
the interval during which the upstream noise margin must remain below the
upstream downshift noise margin before the xTU-C attempts to decrease the
upstream net data rate. Its value ranges from 0 to 16383 seconds. (R, W,
xTU impedance state forced: This parameter forces the impedance state of the xTU-C. It
applies only to the T/S interface, and is deprecated in the OMCI, which
stands proxy for the Q interface. It is only valid for Annex A of [ITU-T
G.992.3], Annex A of [ITU-T G.992.4] and Annex A of [ITU-T G.992.5]. It
is defined as follows:
1 Force the xTU-C to the disabled state.
2 Force the xTU-C to the inactive state.
3 Force the xTU-C to the active state.
L0-time:
This parameter specifies the minimum time between an exit from the L2 state
and the next entry into the L2 state. It is only valid for [ITU-T G.992.3],
[ITU-T G.992.4] and [ITU-T G.992.5]. It ranges from 0 to 255 seconds.
L2-time:
This parameter specifies the minimum time between an entry into the L2
state and the first power trim in the L2 state, or between two consecutive
power trims in the L2 state. It is only valid for [ITU-T G.992.3],
[ITU-T G.992.4] and [ITU-T G.992.5]. It ranges from 0 to 255 seconds. (R,
W, Set-by-create) (mandatory) (1 byte)
Downstream maximum nominal power spectral density: This attribute specifies the
maximum nominal transmit PSD in the downstream direction during
initialization and showtime. A single MAXNOMPSDds attribute is defined
per mode enabled in the xTSE line configuration attribute. It is only valid for
[ITU-T G.992.3], [ITU-T G.992.4] and [ITU-T G.992.5]. Its value ranges
from 0 (60.0 dBm/Hz) to 300 (30 dBm/Hz). (R, W, Set-by-create)
Rec. ITU-T G.988 (10/2012)
217
Upstream maximum nominal power spectral density: This attribute specifies the
maximum nominal transmit PSD in the upstream direction during
initialization and showtime. A single MAXNOMPSDus attribute is defined
per mode enabled in the xTSE line configuration attribute. It is only valid for
from 0 (60.0 dBm/Hz) to 300 (30 dBm/Hz). (R, W, Set-by-create)
Downstream maximum nominal aggregate transmit power: This attribute specifies the
maximum nominal aggregate transmit power in the downstream direction
during initialization and showtime. It is only valid for [ITU-T G.992.3],
from 0 (0.0 dBm) to 255 (25.5 dBm). (R, W, Set-by-create) (mandatory)
(1 byte)
Upstream maximum nominal aggregate transmit power: This parameter specifies the
maximum nominal aggregate transmit power in the upstream direction during
initialization and showtime. It is only valid for [ITU-T G.992.3],
[ITU-T G.992.4] and [ITU-T G.992.5]. Its value ranges from 0 (0.0 dBm) to
255 (25.5 dBm). (R, W, Set-by-create) (mandatory) (1 byte)
Upstream maximum aggregate receive power: This parameter specifies the maximum
upstream aggregate receive power over a set of subcarriers, as defined in the
relevant Recommendation. The xTU-C requests 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 G.992.3], [ITU-T G.992.4] and [ITU-T G.992.5]. This attribute
ranges from 0 (25.5 dBm) to 510 (+25.5 dBm). The special value 0xFFFF
indicates that no upstream maximum aggregate receive power limit is to be
applied. (R, W Set-by-create) (mandatory) (2 bytes)
VDSL2 transmission system enabling: This configuration attribute extends the
transmission system coding types to be allowed by the xTU-C. It is a bit map,
defined as octet 8 (bits 57..64) in Table 9.7.12-1. (R, W, Set-by-create)
(optional) (1 byte)
Actions
Notifications
None.
9.7.5
Relationships
xDSL UNI.
218
Rec. ITU-T G.988 (10/2012)
Attributes
Loop diagnostics mode forced (LDSF): This configuration parameter forces the line into
loop diagnostic mode via the xTU-C. It is only valid for [ITU-T G.992.3],
[ITU-T G.992.4] and [ITU-T G.992.5]. It is defined as follows:
0 Inhibits the xTU-C from performing loop diagnostic mode procedures
on the line. Loop diagnostic mode procedures may still be initiated by
the xTU-R.
1 Forces the xTU-C to perform the loop diagnostics procedures.
Only while the line power management state is L3 can the line be forced into
loop diagnostic mode. When loop diagnostic procedures complete
successfully, the ONU resets this attribute to 0. The line remains in the L3
idle state. The loop diagnostics data are available at least until the line is
forced to the L0 state. As long as loop diagnostic procedures have not
completed successfully, attempts are made to do so, until the loop diagnostic
mode is no longer forced on the line through this configuration parameter. If
loop diagnostic procedures cannot be completed successfully after a
vendor-discretionary number of retries and/or within a vendor-discretionary
timeout, then an initialization failure occurs. (R, W, Set-by-create)
Automode cold start forced: This attribute is defined to improve testing of the performance
of xTUs supporting automode. Valid values are 0 and 1. A change in value of
this attribute indicates a change in loop conditions applied to the devices
under test. The xTUs reset any historical information used for automode, for
shortening an ITU-T G.994.1 handshake, or for shortening the initialization
procedure.
Automode is defined as the case where multiple operation modes are enabled
in xTSE (Table 9.7.12-1) and where the selection of the operation mode to be
used for transmission depends, not only on the common capabilities of both
xTUs (as exchanged in [ITU-T G.994.1]), but also on achievable data rates
under given loop conditions. (R, W, Set-by-create) (mandatory if automode is
supported) (1 byte)
L2-ATPR:
This parameter specifies the maximum aggregate transmit power reduction

that can be performed in the L2 request (i.e., at the transition of L0 to L2
state) or through a single power trim in the L2 state. It is only valid for
[ITU-T G.992.3], [ITU-T G.992.4] and [ITU-T G.992.5]. This attribute
ranges from 0 (0 dB) dB to 31 (31 dB). (R, W, Set-by-create) (mandatory) (1
byte)
L2-ATPRT: This parameter specifies 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 requests (i.e., at transitions from L0 to L2 state) and power
trims. This attribute ranges from 0 (0 dB) dB to 31 (31 dB). (R, W,
Force INP downstream: When set to 1, the FORCEINPds attribute forces the framer
settings of all downstream bearer channels to be selected such that the
impulse noise protection computed according to the formula specified in the
Rec. ITU-T G.988 (10/2012)
219
relevant Recommendation is greater than or equal to the minimal impulse

noise protection requirement. The default value 0 disables this function. (R,
W) (mandatory for [ITU-T G.993.2], optional for other Recommendations
that support it) (1 byte)
Force INP upstream: When set to 1, the FORCEINPus attribute forces the framer settings
of all upstream bearer channels to be selected such that the impulse noise
protection computed according to the formula specified in the relevant
Recommendation is greater than or equal to the minimal impulse noise
protection requirement. The default value 0 disables this function. (R, W)
(mandatory for [ITU-T G.993.2], optional for other Recommendations that
support it) (1 byte)
Update request flag for near-end test parameters: The UPDATE-TEST-NE attribute
forces an update of all near-end test parameters that can be updated during
showtime in [ITU-T G.993.2]. Update is triggered by setting this attribute to
1, whereupon the near-end test parameters are expected to be updated within
10 seconds, and the ONU should reset the attribute value to 0. The update
request flag is independent of any autonomous update process in the system.
The update request attribute must be prepared to accept another set after a
period not to exceed 3 minutes, a period that starts when the flag is set via the
OMCI or by an autonomous process in the system. (R, W) (optional) (1 byte)
Update request flag for far-end test parameters: The UPDATE-TEST-FE attribute forces
an update of all far-end test parameters that can be updated during showtime
in [ITU-T G.993.2]. Update is triggered by setting this attribute to 1,
whereupon the far-end test parameters are expected to be updated within
10 seconds, and the ONU should reset the attribute value to 0. The update
request flag is independent of any autonomous update process in the system.
The update request attribute must be prepared to accept another set after a
period not to exceed 3 minutes, a period that starts when the flag is set via the
OMCI or by an autonomous process in the system. (R, W) (optional) (1 byte)
The following eight attributes configure the impulse noise monitoring (INM) function, whose
results are available via the xDSL impulse noise monitor performance monitoring history data
managed entity. The downstream attributes are applicable to [ITU-T G.993.2], [ITU-T G.992.3] and
[ITU-T G.992.5]. Only [ITU-T G.993.2] supports the upstream attributes.
INM inter-arrival time offset upstream: INMIATOus is the inter-arrival time (IAT) offset
that the xTU-C receiver uses to determine in which bin of the inter-arrival
time histogram the IAT is reported. Valid values for INMIATO range from 3
to 511 DMT symbols in steps of 1 DMT symbol. (R, W) (optional) (2 bytes)
INM inter-arrival time step upstream: INMIATSus is the inter-arrival time step that the
xTU-C receiver uses to determine in which bin of the inter-arrival time
histogram the IAT is reported. Valid values for INMIATS range from 0 to 7
in steps of 1. (R, W) (optional) (1 byte)
INM cluster continuation value upstream: INMCCus is the cluster continuation value that
the xTU-C receiver uses in the cluster indication process described in the
pertinent Recommendation. Valid values for INMCC range from 0 to 64
DMT symbols in steps of 1 DMT symbol. (R, W) (optional) (1 byte)
INM equivalent INP mode upstream: INM_INPEQ_MODEus is the INM equivalent INP
mode that the xTU-C receiver uses in the computation of the equivalent INP,
as defined in the pertinent Recommendation. Valid values for
INM_INPEQ_MODE are 0..4. (R, W) (optional) (1 byte)
220
Rec. ITU-T G.988 (10/2012)
INM inter-arrival time offset downstream: INMIATOds is the inter-arrival time offset
that the xTU-R receiver uses to determine in which bin of the inter-arrival
time histogram the IAT is reported. Valid values for INMIATO range from 3
to 511 DMT symbols in steps of 1 DMT symbol. (R, W) (optional) (2 bytes)
INM inter-arrival time step downstream: INMIATSds is the inter-arrival time step that
the xTU-R receiver uses to determine in which bin of the inter-arrival time
histogram the IAT is reported. Valid values for INMIATS range from 0 to 7
in steps of 1. (R, W) (optional) (1 byte)
INM cluster continuation value downstream: INMCCds is the cluster continuation value
that the xTU-R receiver uses in the cluster indication process described in the
pertinent Recommendation. Valid values for INMCC range from 0 to 64
DMT symbols in steps of 1 DMT symbol. (R, W) (optional) (1 byte)
INM equivalent INP mode downstream: INM_INPEQ_MODEds is the INM equivalent
INP mode that the xTU-R receiver uses in the computation of the equivalent
INP, as defined in the pertinent Recommendation. Valid values for
INM_INPEQ_MODE are 0..4. (R, W) (optional) (1 byte)
Actions
Notifications
Number
1..6
Description
N/A
Update request NE
Need only be reported on the 1 0 transition to signal

to the OLT that test parameters have been updated.
Update request FE
Need only be reported on the 1 0 transition to signal

to the OLT that test parameters have been updated.
9..16
9.7.6
N/A
VDSL2 line configuration extensions
This managed entity extends the xDSL line configuration MEs with attributes that were originally
unique to [ITU-T G.993.2] VDSL2. Due to continuing standards development, some attributes
and therefore this managed entity have also become applicable to other Recommendations,
specifically [ITU-T G.992.3] and [ITU-T G.992.5]. The attributes of this ME are further defined in
[ITU-T G.997.1]. An instance of this managed entity is created and deleted by the OLT.
Relationships
xDSL UNI.
The overall xDSL line configuration profile is modelled in several parts, all of which are
associated together through a common managed entity ID (the client physical path
termination point xDSL UNI part 1 has a single pointer, which refers to the entire set of line
configuration parts).
Rec. ITU-T G.988 (10/2012)
221
Attributes
VDSL2 profiles enabling: The PROFILES attribute contains the ITU-T G.993.2 profiles to
be allowed by the xTU-C. It is coded in a bit map representation (0 if not
allowed, 1 if allowed) with the following definition:
Bit
Meaning
1 (LSB) ITU-T G.993.2 profile 8a
2
ITU-T G.993.2 profile 8b
3
ITU-T G.993.2 profile 8c
4
ITU-T G.993.2 profile 8d
5
ITU-T G.993.2 profile 12a
6
7
8
(R, W, Set-by-create) (mandatory for ITU-T G.993.2) (1 byte)
VDSL2 PSD mask class selection (CLASSMASK): To reduce the number of
configuration possibilities, the limit PSD masks are grouped in the following
PSD mask classes:
Class 998 Annex A of [ITU-T G.993.2]: D-32, D-48, D-64, D-128
Class 997-M1c Annex B of [ITU-T G.993.2]: 997-M1c-A-7
Class 997-M1x Annex B of [ITU-T G.993.2]: 997-M1x-M-8,
997-M1x-M
Class 997-M2x Annex B of [ITU-T G.993.2]: 997-M2x-M-8, 997M2x-A, 997-M2x-M, 997E17-M2x-NUS0, 997E30-M2x-NUS0
Class 998-M1x Annex B of [ITU-T G.993.2]: 998-M1x-A,
998-M1x-B, 998-M1x-NUS0
Class 998-M2x Annex B of [ITU-T G.993.2]: 998-M2x-A,
998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998E17-M2x-NUS0,
998E17-M2x-NUS0-M, 998E30-M2x-NUS0, 998E30-M2x-NUS0-M
Class 998ADE-M2x Annex B of [ITU-T G.993.2]: 998-M2x-A,
998-M2x-M, 998-M2x-B, 998-M2x-NUS0, 998ADE17-M2x-A,
998ADE17-M2x-B,
998ADE17-M2x-NUS0-M,
998ADE30-M2x-NUS0-A, 998ADE30-M2x-NUS0-M
Class 998-B Annex C: POTS-138b, POTS-276b (clause C.2.1.1 of
[ITU-T G.993.2]), TCM-ISDN (clause C.2.1.2 of [ITU-T G.993.2])
Class 998-CO Annex C of [ITU-T G.993.2]: POTS-138co,
POTS-276co (clause C.2.1.1 of G.993.2)
Class HPE-M1 Annex B of [ITU-T G.993.2]: HPE17-M1-NUS0,
HPE30-M1-NUS0
Each class is designed such that the PSD levels of each limit PSD mask of a
specific class are equal in their respective passbands above 552 kHz.
222
Rec. ITU-T G.988 (10/2012)
The CLASSMASK attribute is defined per ITU-T G.993.2 annex enabled in

the xTSE table (see Table 9.7.12-1). It selects a single PSD mask class per
ITU-T G.993.2 annex to be activated at the VTU-O. The coding is as follows:
Attribute value G.993.2 Annex A G.993.2 Annex B G.993.2 Annex C
1
998
997-M1c
998-B
2
997-M1x
998-CO
3
997-M2x
4
998-M1x
5
998-M2x
6
998ADE-M2x
7
HPE
NOTE 1 A single PSD mask class may be selected per ITU-T G.993.2 annex.
NOTE 2 It is expected that only a single annex will be enabled at any given time,
such that the CLASSMASK attribute, as well as the LIMITMASK and
US0DISABLE attributes below, need not be vectors of values.

VDSL2 limit PSD masks: The LIMITMASK attribute contains the ITU-T G.993.2 limit
PSD masks of the selected PSD mask class, enabled by the near-end xTU for
each class of profiles. One LIMITMASK parameter is defined per annex
enabled in the xTSE (see Table 9.7.12-1).
The profiles are grouped in the following profile classes:
Class 8: Profiles 8a, 8b, 8c, 8d
Class 12: Profiles 12a, 12b
Class 17: Profile 17a
Class 30: Profile 30a
For each profile class, several limit PSD masks of the selected PSD mask
class (CLASSMASK) may be enabled. The enabling attribute is coded in a
bit map representation (0 if the associated mask is not allowed, 1 if it is
allowed). The bit mask is defined in Table 9.7.6-1. (R, W, Set-by-create)
VDSL2 US0 disabling: The US0DISABLE attribute specifies whether channel US0 is
disabled for each limit PSD mask enabled in the LIMITMASK attribute.
For each limit PSD mask enabled in the LIMITMASK attribute, one bit
indicates if US0 is disabled. The disabling attribute is a bit map where the
value 1 specifies that US0 is disabled for the associated limit mask. The bit
map has the same structure as the LIMITMASK attribute. (R, W,
VDSL2 US0 PSD masks: The US0MASK attribute contains the US0 PSD masks to be
allowed by the xTU-C. This attribute is only defined for Annex A of
[ITU-T G.993.2]. It is represented as a bit map (0 if not allowed, 1 if
allowed) with the definitions of Table 9.7.6-2. (R, W, Set-by-create)
VDSL2-CARMASK table: This attribute specifies restrictions, additional to the band plan,
that determine the set of subcarriers allowed for transmission in both
upstream and downstream directions.
Rec. ITU-T G.988 (10/2012)
223
The VDSL2-CARMASK attribute describes the not-masked subcarriers in

terms of one or more frequency bands. Each band is represented by start and
stop subcarrier indices with a subcarrier spacing of 4.3125 kHz. The valid
range of subcarrier indices is from 0 to at least the index of the highest
allowed subcarrier in both transmission directions among all profiles enabled
by the VDSL2 profiles enabling (PROFILES) attribute. Up to 32 bands may
be specified. Other subcarriers are masked.
For profiles using 8.625 kHz tone spacing, the odd subcarrier indices i4.3125 in
VDSL2-CARMASK can be transformed into actual subcarrier indices i8.625
using the following rule:
for the start frequency of each band: i8.625 = (i4.3125 + 1)/2
for the stop frequency of each band: i8.625 = (i4.3125 1)/2.
The VDSL2-CARMASK attribute is a table where each entry comprises:
an entry number field (1 byte, first entry numbered 1)
band start subcarrier index (2 bytes)
band stop subcarrier index (2 bytes).
By default, the table is empty. Entries are added or modified using the set
action. Setting a table entry with non-zero subcarrier references implies
insertion into the table. Setting an entry's subcarrier references to zero
implies deletion from the table, if present.
The maximum number of bands is 32, so the maximum size of the table is
160 bytes. (R, W) (mandatory) (5 * N bytes, where N is the number of bands)
CARMASK valid: This attribute controls and reports the status of the VDSL2-CARMASK
table. If CARMASK valid = 1, then the VDSL2-CARMASK has been
effectuated on the xDSL equipment. If CARMASK valid = 0 (default), then
the VDSL2-CARMASK table is under construction and has not been
effectuated on the xDSL equipment.
This attribute behaves as follows:
If the OLT changes any of the VDSL2-CARMASK table entries
or sets CARMASK valid = 0, then CARMASK valid = 0.
If CARMASK valid = 0 and the OLT sets CARMASK valid = 1,
then the ONU updates the xDSL equipment with the contents of
the table.
UPBOSHAPED: Upstream power back-off (UPBO) is specified in [ITU-T G.993.2] to
provide spectral compatibility between loops of different lengths deployed in
the same cable binder. The upstream transmit PSD mask, UPBOMASKus is
defined in clause 7.2.1.3.2 of [ITU-T G.993.2].
The ITU-T G.993.2 UPBO configuration attributes a and b are set by the
OLT via this attribute. The reference length kl0_REF is set by the companion
attribute UPBO klREF-pb, defined below. Further details appear in
[ITU-T G.997.1].
This attribute includes two parameters for each band. The parameters are a
and b, in that order. Parameter a lies in the range 4000 (40.00 dBm/Hz) to
8095 (80.95 dBm/Hz). Parameter b lies in the range 0 (0.00 dBm/Hz) to 4095
(40.95 dBm/Hz). The special values a = b = 0 disable UPBO in the respective
upstream band.
224
Rec. ITU-T G.988 (10/2012)
The upstream electrical length parameter UPBOKL defines the electrical

length expressed in dB at 1 MHz, kl0, which may also be configured by the
OLT. Its value ranges from 0 (0.0 dB) to 1280 (128.0 dB).
If the force electrical length parameter UPBOKLF is 1, the VTU-R is forced
to use the electrical length from this attribute (UPBOKL) to compute UPBO.
Otherwise, the VTUs determine the electrical length themselves.
Upstream band 1
Upstream band 2
Upstream band 3
Upstream band 4
Upstream band 5
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
UPBOKL
2 bytes
UPBOKLF
1 byte

Cyclic extension: The CEFLAG attribute enables (1) the optional cyclic extension values. If
set to 0, the cyclic extension is forced to the mandatory length 5N/32. (R, W)
Downstream SNR mode: The SNRMODEds attribute controls transmitter referred virtual
noise in the downstream direction. If set to 1, virtual noise is disabled. If set
to 2, virtual noise is enabled. (R, W) (mandatory) (1 byte)
Upstream SNR mode: The SNRMODEus attribute controls transmitter referred virtual
noise in the upstream direction. If set to 1, virtual noise is disabled. If set to 2,
virtual noise is enabled. (R, W) (mandatory) (1 byte)
Transmitter referred virtual noise downstream table: The TXREFVNds table defines the
downstream transmitter referred virtual noise. TXREFVNds is specified
through a set of breakpoints. Each breakpoint comprises a subcarrier index t,
with a subcarrier spacing of 4.3125 kHz, and a noise PSD level at that
subcarrier. The set of breakpoints can then be represented as [(t1, PSD1), (t2,
PSD2), , (tN, PSDN)]. The subcarrier index t is an unsigned two-byte
integer. The noise level is one byte whose value ranges from 0 (40 dBm/Hz)
to 200 (140 dBm/Hz), in steps of 0.5 dB. Values between 201 and 254
indicate a noise PSD level of 0 W/Hz. The maximum number of breakpoints
is 32; no more than 15 breakpoints may be configured below the upper edge
of the passband of every mode enabled for [ITU-T G.992.3] and
[ITU-T G.992.5].
Table entries for this attribute have the default value 254 for the noise PSD
level. Entries are added or modified using the set action. Setting an entry to a
noise PSD level less than or equal to 254 implies insertion into the table.
Setting an entry's noise PSD level to 255 implies deletion from the table, if
present.
Rec. ITU-T G.988 (10/2012)
225
(R, W) (optional) (3N bytes, where N is the number of breakpoints)

Transmitter referred virtual noise upstream table: The TXREFVNus attribute defines
the upstream transmitter referred virtual noise. TXREFVNus is specified
through a set of breakpoints. Each breakpoint comprises a subcarrier index t,
with a subcarrier spacing of 4.3125 kHz, and a noise PSD level at that
subcarrier. The set of breakpoints can then be represented as [(t1, PSD1), (t2,
PSD2), , (tN, PSDN)]. The subcarrier index t is an unsigned two-byte
integer. The noise level is one byte whose value ranges from 0 (40 dBm/Hz)
to 200 (140 dBm/Hz), in steps of 0.5 dB. Values between 201 and 254
indicate a noise PSD level of 0 W/Hz. The maximum number of breakpoints
is 16; no more than 3 breakpoints may be configured below the upper edge of
the passband of every mode enabled for [ITU-T G.992.3] and
[ITU-T G.992.5].
Table entries for this attribute have the default value 254 for the noise PSD
level. Entries are added or modified using the set action. Setting an entry to a
noise PSD level less than or equal to 254 implies insertion into the table.
Setting an entry's noise PSD level to 255 implies deletion from the table, if
present.
(R, W) (optional) (3N bytes, where N is the number of breakpoints)
DPBOSHAPED: Downstream power back-off shaped is described in [ITU-T G.997.1] as
a vector of parameters that modifies the downstream PSD mask.
DPBOEPSD Assumed exchange PSD mask. This component points to a
downsteam xDSL PSD mask profile managed entity. The PSD mask profile
should contain no more than 16 break points. (2 bytes)
DPBOESEL E-side electrical length. This component is the assumed loss
at some reference frequency of the electrical cable from the xDSL equipment
to a possible flexibility point. It ranges from 0 (0.0 dB) to 511 (255.5 dB) in
steps of 0.5 dB. The value 0 has the special meaning that it disables the
DPBOSHAPED feature. (2 bytes)
The following three parameters describe the cable model. Further details
appear in [ITU-T G.997.1]. Each is a scalar that represents the range 1
(coded as 0) to +1.5 (coded as 640) in steps of 1/256.
DPBOESCMA (2 bytes)
DPBOESCMB (2 bytes)
DPBOESCMC (2 bytes)
DPBOMUS Assumed minimum usable receive PSD mask. This
component ranges from 0 (0.0 dBm/Hz) to 255 (127.5 dBm/Hz) in steps of
0.5 dB. (1 byte)
DPBOFMIN The lower frequency bound above which DPBO is applied.
This component ranges from 0 (0.00 kHz) to 2048 (8832.00 kHz) in steps of
4.3125 kHz. (2 bytes)
DPBOFMAX The upper frequency bound below which DPBO is applied.
This component ranges from 32 (138.00 kHz) to 6956 (29997.75 kHz) in
steps of 4.3125 kHz. (2 bytes)
226
Rec. ITU-T G.988 (10/2012)
UPBOKLREF-pb: This attribute represents the reference loop length, the electrical length
used to compute upstream power back-off for each upstream band except
US0, for the optional equalized FEXT UPBO method. The value for each
upstream band ranges from 1.8 to 63.5 dB in steps of 0.1 dB, i.e., with values
18..635. The special value 0 is also allowed, with semantics as defined in
clause 7.2.1.3.2 of [ITU-T G.993.2]. (R, W) (optional) (2 bytes * 5 upstream
bands)
Actions
Notifications
None.
Table 9.7.6-1 Limit mask definitions for each class mask
PSD mask classes
Annex A
Bit
998
Annex A
Annex B
998-M1x
Annex B
998-M2x
Annex B
998ADEM2x
Annex B
997-M1x
Annex B
Annex C
997-M1c
Annex B
997-M2x
Annex B
M1c-A-7
HPE-M1
Annex B
998-B
Annex C
998-CO
Annex C
M2x-A
POTS138b
POTS138co
POTS276co
Octet 1, profile class 8

1
D-32
M1x-A
M2x-A
M2x-A
D-48
M1x-B
M2x-B
M2x-B
M1x-M-8
M2x-M-8
TCMISDN
M2x-M
M2x-M
M1x-M
M2x-M
POTS276b
M1xNUS0
M2xNUS0
M2xNUS0
M2x-A
POTS138b
POTS138co
TCMISDN
POTS276co
3
4
5
6
7
8
1
D-64
D-128
3
4
5
6
7
8
1
D-32
M1x-A
M2x-A
M2x-A
D-48
M1x-B
M2x-B
M2x-B
M2x-M
M2x-M
M2xNUS0
M2xNUS0
3
4
M1xNUS0
M1x-M
M2x-M
POTS276b
Rec. ITU-T G.988 (10/2012)
227

PSD mask classes
Annex A
Bit
998
Annex A
Annex B
998-M1x
Annex B
998-M2x
Annex B
998ADEM2x
Annex B
997-M1x
Annex B
Annex C
997-M1c
Annex B
997-M2x
Annex B
HPE-M1
Annex B
998-B
Annex C
E17M2xNUS0
17-M1NUS0
POTS138b
6
7
8
1
D-64
D-128
3
4
5
6
7
8
1
D-32
E17M2xNUS0
ADE17M2x-A
D-48
E17M2xNUS0-M
ADE17M2x-B
TCMISDN
ADE17M2xNUS0-M
POTS276b
4
5
6
7
8
1
D-64
D-128
3
4
5
6
7
8
1
D-32
E30M2xNUS0
ADE30M2xNUS0-A
D-48
E30M2xNUS0-M
ADE30M2xNUS0-M
30-M1NUS0
POTS138b
TCMISDN
POTS276b
4
5
6
228
E30M2xNUS0
Rec. ITU-T G.988 (10/2012)
998-CO
Annex C

PSD mask classes
Annex A
Bit
998
Annex A
Annex B
998-M1x
Annex B
998-M2x
Annex B
998ADEM2x
Annex B
997-M1x
Annex B
Annex C
997-M1c
Annex B
997-M2x
Annex B
HPE-M1
Annex B
998-B
Annex C
998-CO
Annex C
7
8
1
D-64
D-128
3
4
5
6
7
8
NOTE All unassigned bits are reserved.
Table 9.7.6-2 VDSL2 US0 PSD masks definition

Bit
ITU-T G.993.2 Annex A US0MASK
Octet 1
1
EU-32
EU-36
EU-40
EU-44
EU-48
EU-52
EU-56
EU-60
EU-64
EU-128
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
ADLU-32
ADLU-36
Octet 2
Octet 3
Rec. ITU-T G.988 (10/2012)
229
Table 9.7.6-2 VDSL2 US0 PSD masks definition

Bit
ITU-T G.993.2 Annex A US0MASK
ADLU-40
ADLU-44
ADLU-48
ADLU-52
ADLU-56
ADLU-60
ADLU-64
10
ADLU-128
11
Reserved
12
Reserved
13
Reserved
14
Reserved
15
Reserved
16
Reserved
Octet 4
NOTE 1 Valid combinations of US0MASK and LIMITMASK are described in

[ITU-T G.993.2].
NOTE 2 More than one mask may be enabled simultaneously. If no US0 PSD
masks are enabled, the line is configured without US0 support.
9.7.7
xDSL channel configuration profile
This managed entity contains the channel configuration profile for an xDSL UNI. An instance of
this managed entity is created and deleted by the OLT.
NOTE If [ITU-T G.997.1] compatibility is required, bit rates should only be set to integer multiples of
1000 bits/s. The ONU may reject attempts to set other values for bit rate attributes.
Relationships
physical path termination point xDSL UNI part 1.
Attributes
The value 0 is reserved. (R, Set-by-create) (mandatory) (2 bytes)
Minimum data rate: This parameter specifies the minimum desired net data rate for the
bearer channel. It is coded in bit/s. (R, W, Set-by-create) (mandatory)
(4 bytes)
Maximum data rate: This parameter specifies the maximum desired net data rate for the
bearer channel. It is coded in bit/s. (R, W, Set-by-create) (mandatory)
(4 bytes)
Rate adaptation ratio: This attribute specifies the weight that should be taken into account
when performing rate adaptation in the direction of the bearer channel. The
attribute is defined as a percentage in the 0 to 100 range. The value 20, for
example, means that 20% of the available data rate (in excess of the
230
Rec. ITU-T G.988 (10/2012)
minimum data rate summed over all bearer channels) is assigned to this
bearer channel and 80% to the other bearer channels. The OLT must assure
that the sum of rate adaptation ratios over all bearers in one direction is
100%. (R, W, Set-by-create) (optional) (1 byte)
Maximum interleaving delay: This attribute 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 xDSL Recommendations as cap(S*D) /4 ms, where S is
the S factor, D is the interleaving depth, and cap() denotes rounding to the
next higher integer. xTUs choose S and D values such that the actual oneway interleaving delay does not exceed the configured maximum interleaving
delay.
The delay is coded in ms, varying from 2 to 63, with special meaning
assigned to values 0, 1 and 255. The value 0 indicates that no delay bound is
imposed. The value 1 indicates the fast latency path is to be used in the
ITU-T G.992.1 operating mode and S and D are to be selected such that S 1
and D = 1 in ITU-T G.992.2, ITU-T G.992.3, ITU-T G.992.4, ITU-T G.992.5
and ITU-T G.993.2 operating modes. The value 255 indicates a delay bound
of 1 ms in ITU-T G.993.2 operation. (R, W, Set-by-create) (mandatory)
(1 byte)
Data rate threshold upshift: This attribute is a threshold on the cumulative data rate upshift
achieved over one or more bearer channel data rate adaptations. An upshift
rate change (DRT up) notification is issued by the PPTP xDSL UNI part 1
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, W,
Set-by-create) (mandatory for xDSL standards that use this attribute)
(4 bytes)
Data rate threshold downshift: This attribute is a threshold on the cumulative data rate
downshift achieved over one or more bearer channel data rate adaptations. A
downshift rate change (DRT down) notification is issued by the PPTP xDSL
UNI part 1 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, W, Set-by-create) (mandatory for xDSL standards that use this
attribute) (4 bytes)
Minimum reserved data rate: This attribute specifies the desired minimum reserved net
data rate for the bearer channel. The rate is coded in bit/s. This attribute is
needed only if the rate adaptation mode is set to dynamic in the xDSL line
configuration profile part 1. (R, W, Set-by-create) (optional) (4 bytes)
Minimum data rate in low power state: This parameter specifies the minimum desired net
data rate for the bearer channel during the low power state (L1/L2). The
power management low power states L1 and L2 are defined in
[ITU-T G.992.2] and [ITU-T G.992.3], respectively. The data rate is coded in
bit/s. (R, W, Set-by-create) (mandatory) (4 byte)
Minimum impulse noise protection: The INPmin attribute specifies the minimum impulse
noise protection for the bearer channel if it is transported over DMT symbols
with a subcarrier spacing of 4.3125 kHz. Impulse noise protection is
expressed in DMT symbols with a subcarrier spacing of 4.3125 kHz. It can
be symbol or any integer number of symbols from 0 to 16, inclusive.
Rec. ITU-T G.988 (10/2012)
231
If the xTU does not support the configured INPmin value, it uses the nearest
supported impulse noise protection value greater than INPmin.
Value INPmin
1
0 symbols
symbol
(N2) symbols, 3 N 18
(R, W, Set-by-create) (optional for [ITU-T G.992.1], mandatory for other

xDSL standards that use this attribute) (1 byte)
Maximum bit error ratio: This attribute specifies the desired maximum bit error ratio for
the bearer channel. It is only valid for [ITU-T G.992.3], [ITU-T G.992.4] and
[ITU-T G.992.5]. The bit error ratio is specified via the following values:
1 103
2 105
3 107
(R, W, Set-by-create) (mandatory for standards that use this attribute)
(1 byte)
Minimum impulse noise protection 8 kHz: The INPmin8 attribute specifies the minimum
impulse noise protection for the bearer channel if it is transported over DMT
symbols with a subcarrier spacing of 8.625 kHz. It is only valid for
[ITU-T G.993.2]. Impulse noise protection is expressed in DMT symbols
with a subcarrier spacing of 8.625 kHz. It can take any integer value from 0
(default) to 16, inclusive. (R, W) (mandatory for [ITU-T G.993.2]) (1 byte)
Maximum delay variation: The DVMAX attribute specifies the maximum value for delay
variation allowed in an OLR procedure. Its value ranges from 1 (0.1 ms) to
254 (25.4 ms). The special value 255 specifies that no delay variation bound
is imposed. (R, W) (optional: used by [ITU-T G.993.2]) (1 byte)
Channel initialization policy selection: The CIPOLICY attribute specifies the policy to
determine transceiver configuration at initialization. Valid values are 0..1, as
defined in the Recommendations that use this attribute. (R, W) (optional)
(1 byte)
Minimum SOS bit rate downstream: The MIN-SOS-BR-ds attribute specifies the
minimum net data rate required for a valid SOS request in the downstream
direction. The value is coded as an unsigned integer representing the data rate
as a multiple of 8 kbit/s. (R, W) (optional) (4 bytes)
Minimum SOS bit rate upstream: The MIN-SOS-BR-us attribute specifies the minimum
net data rate required for a valid SOS request in the upstream direction. The
value is coded as an unsigned integer representing the data rate as a multiple
of 8 kbit/s. (R, W) (optional) (4 bytes)
Actions
Notifications
None.
9.7.8
xDSL subcarrier masking downstream profile
This managed entity contains the subcarrier masking downstream profile for an xDSL UNI.
232
Rec. ITU-T G.988 (10/2012)
Relationships
Attributes
The four following attributes are bit maps that represent downstream mask values for subcarriers
1..128 (mask 1) through 385..512 (mask 4). The MSB of the first byte corresponds to the lowest
numbered subcarrier, and the LSB of the last byte corresponds to the highest. Each bit position
defines whether the corresponding downstream subcarrier is masked (1) or not masked (0).
NSCds is the highest numbered subcarrier that can be transmitted in the downstream direction. For
[ITU-T G.992.3], [ITU-T G.992.4] and [ITU-T G.992.5], it is defined in the corresponding
Recommendation. For [ITU-T G.992.1], NSCds = 256 and for [ITU-T G.992.2], NSCds = 128.
Downstream subcarrier mask 1: Subcarriers 1 to 128. (R, W, Set-by-create) (mandatory)
(16 bytes)
Downstream subcarrier mask 2: Subcarriers 129 to 256. (R, W) (mandatory for modems
that support NSCds > 128) (16 bytes)
Mask valid: This Boolean attribute controls and reports the operational status of the
downstream subcarrier mask attributes.
If this attribute is true (1), the downstream subcarrier mask represented in this
ME has been impressed on the DSL equipment.
If this attribute is false (0), the downstream subcarrier mask represented in
this ME has not been impressed on the DSL equipment. The 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 mask valid
false, then mask valid is false.
If mask valid is false and the OLT sets mask valid true, the ONU
impresses the downstream subcarrier mask data onto the DSL
equipment.
Actions
Notifications
None.
9.7.9
xDSL subcarrier masking upstream profile
This managed entity contains the subcarrier masking upstream profile for an xDSL UNI. An
instance of this managed entity is created and deleted by the OLT.
Rec. ITU-T G.988 (10/2012)
233
Relationships
Attributes
Upstream subcarrier mask: This attribute is a bit map representing upstream mask values
for subcarriers 1 to 64. The MSB of byte 1 corresponds to subcarrier 1, and
the LSB of byte 8 corresponds to subcarrier 64. Each bit position defines
whether the corresponding downstream subcarrier is masked (1) or not
masked (0).
Subcarrier number 1 is the lowest, and subcarrier number NSCus is the
highest subcarrier that can be transmitted in the upstream direction. For
[ITU-T G.992.3], [ITU-T G.992.4] and [ITU-T G.992.5], it is defined in the
corresponding Recommendation. For Annex A of [ITU-T G.992.1] and
[ITU-T G.992.2], NSCus = 32 and for Annex B of [ITU-T G.992.1],
NSCus = 64. (R, W, Set-by-create) (mandatory) (8 bytes)
Actions
Notifications
None.
9.7.10 xDSL PSD mask profile
This managed entity contains a PSD mask profile for an xDSL UNI. An instance of this managed
entity is created and deleted by the OLT.
Relationships
Attributes
PSD mask table: This attribute is a table that defines the PSD mask applicable at the U-C2
reference point (downstream) or the U-R2 reference point (upstream). This
mask may impose PSD restrictions in addition to the limit PSD mask defined
in the relevant Recommendations ([ITU-T G.992.3], [ITU-T G.992.5],
[ITU-T G.993.2]).
NOTE In [ITU-T G.997.1], this attribute is called PSDMASKds (downstream) and
PSDMASKus (upstream). In [ITU-T G.993.2], this attribute is called MIBMASKds
(downstream) and MIBMASKus (upstream). The ITU-T G.993.2 MIBMASKus
does not include breakpoints to shape US0.
234
Rec. ITU-T G.988 (10/2012)
The PSD mask is specified through a set of breakpoints. Each breakpoint

comprises a two-byte subcarrier index t, with a subcarrier spacing of
4.3125 kHz, and a one-byte PSD mask level at that subcarrier. The set of
breakpoints can then be represented as [(t1, PSD1), (t2, PSD2), , (tN,
PSDN)]. The PSD mask level is coded as 0 (0.0 dBm/Hz) to 190
(95.0 dBm/Hz), in steps of 0.5 dB.
The maximum number of downstream breakpoints is 32. In the upstream
direction, the maximum number of breakpoints is 4 for [ITU-T G.992.3] and
16 for [ITU-T G.993.2]. The requirements for a valid set of breakpoints are
defined in the relevant Recommendations ([ITU-T G.992.3],
[ITU-T G.992.5], [ITU-T G.993.2]).
Each table entry in this attribute comprises:
a subcarrier index field, denoted t (2 bytes)
a PSD mask level field (1 byte).
By default, the PSD mask table is empty. Setting a subcarrier entry with a
valid PSD mask level implies insertion into the table or replacement of an
existing entry. Setting an entry's PSD mask level to 0xFF implies deletion
from the table.
(R, W) (mandatory) (4 * N bytes where N is the number of breakpoints)
Mask valid: This Boolean attribute controls and reports the status of the PSD mask
attribute.
As a status report, the value false indicates that the PSD mask represented in
this ME has not been impressed on the DSL equipment. The value true
indicates that the PSD mask represented in this ME has been impressed on
the DSL equipment.
This attribute behaves as follows:
If the OLT changes any of the PSD mask table entries or sets mask
valid false, then mask valid is false.
If mask valid is false and the OLT sets mask valid true, the ONU
impresses the PSD mask data on the DSL equipment.
Actions
Notifications
None.
9.7.11 xDSL downstream RFI bands profile
This managed entity contains the downstream RFI bands profile for an xDSL UNI. Instances of this
Relationships
Rec. ITU-T G.988 (10/2012)
235
Attributes
Downstream RFI bands table: The RFIBANDS attribute is a table where each entry
comprises:
subcarrier index 1 field (2 bytes)
subcarrier index 2 field (2 bytes).
For [ITU-T G.992.5], this configuration attribute defines the subset of
downstream PSD mask breakpoints, as specified in the downstream PSD
mask, to be used to notch an RFI band. This subset consists of couples of
consecutive subcarrier indices belonging to breakpoints: [ti; ti+1],
corresponding to the low level of the notch. Interpolation around these points
is defined in [ITU-T G.992.5].
For [ITU-T G.993.2], this attribute defines the bands where the PSD is to be
reduced as specified in clause 7.2.1.2 of [ITU-T G.993.2]. Each band is
represented by start and stop subcarrier indices with a subcarrier spacing of
4.3125 kHz. Up to 16 bands may be specified. This attribute defines the RFI
bands for both upstream and downstream directions.
Entries have the default value 0 for both subcarrier index 1 and subcarrier
index 2. Setting an entry with a non-zero subcarrier index 1 and subcarrier
index 2 implies insertion into the table or replacement of an existing entry.
Setting an entry's subcarrier index 1 and subcarrier index 2 to 0 implies
deletion from the table, if present.
(R, W) (mandatory for [ITU-T G.992.5], [ITU-T G.993.2]) (5 * N bytes
where N is the number of RFI bands)
Bands valid: This Boolean attribute controls and reports the operational status of the
downstream RFI bands table.
If this attribute is true, the downstream RFI bands table has been impressed
on the DSL equipment.
If this attribute is false, the downstream RFI bands table has not been
impressed on the DSL equipment. The default value is false.
This attribute can be modified by the ONU and OLT, as follows:
If the OLT changes any of the RFI bands table entries or sets bands
valid false, then bands valid is false.
If bands valid is false and OLT sets bands valid true, the ONU
impresses the downstream RFI bands data onto the DSL equipment.
Actions
Notifications
None.
236
Rec. ITU-T G.988 (10/2012)
9.7.12 xDSL line inventory and status data part 1

This managed entity contains part 1 of the line inventory and status data for an xDSL UNI. The
ONU automatically creates or deletes an instance of this managed entity upon the creation or
deletion of a physical path termination point xDSL UNI part 1.
Relationships
An instance of this managed entity is associated with an xDSL UNI.
Attributes
xTU-C G.994.1 vendor ID: This is the vendor ID as inserted by the xTU-C in the
ITU-T G.994.1 CL message. It comprises 8 octets, including a country code
followed by a (regionally allocated) provider code, as defined in
[ITU-T T.35]. (R) (mandatory) (8 bytes)
xTU-R G.994.1 vendor ID: This is the vendor ID as inserted by the xTU-R in the
ITU-T G.994.1 CLR message. It comprises 8 binary octets, with the same
format as the xTU-C ITU-T G.994.1 vendor ID. (R) (mandatory) (8 bytes)
xTU-C system vendor ID: This is the vendor ID as inserted by the xTU-C in the overhead
messages of [ITU-T G.992.3] and [ITU-T G.992.4]. It comprises 8 binary
octets, with the same format as the xTU-C ITU-T G.994.1 vendor ID. (R)
xTU-R system vendor ID: This is the vendor ID as inserted by the xTU-R in the embedded
operations channel and overhead messages of [ITU-T G.992.3] and
[ITU-T G.992.4]. It comprises 8 binary octets, with the same format as the
xTU-C ITU-T G.994.1 vendor ID. (R) (mandatory) (8 bytes)
xTU-C version number: This is the vendor-specific version number as inserted by the
xTU-C in the overhead messages of [ITU-T G.992.3] and [ITU-T G.992.4]. It
comprises up to 16 binary octets. (R) (mandatory) (16 bytes)
xTU-R version number: This is the version number as inserted by the xTU-R in the
embedded operations channel of [ITU-T G.992.1] or [ITU-T G.992.2], or the
overhead messages of [ITU-T G.992.3], [ITU-T G.992.4], [ITU-T G.992.5]
and [ITU-T G.993.2]. The attribute value may be vendor-specific, but is
recommended to comprise up to 16 ASCII characters, null-terminated if it is
shorter than 16. The string should contain the xTU-R firmware version and
the xTU-R model, encoded in that order and separated by a space character:
"<xTU-R firmware version><xTU-R model>". It is recognized that legacy
xTU-Rs may not support this format. (R) (mandatory) (16 bytes)
xTU-C serial number part 1: The vendor-specific serial number inserted by the xTU-C in
the overhead messages of [ITU-T G.992.3] and [ITU-T G.992.4] comprises
up to 32 ASCII characters, null terminated if it is shorter than 32 characters.
This attribute contains the first 16 characters. (R) (mandatory) (16 bytes)
xTU-C serial number part 2: This attribute contains the second 16 characters of the xTU-C
serial number. (R) (mandatory) (16 bytes)
Rec. ITU-T G.988 (10/2012)
237
xTU-R serial number part 1: The serial number inserted by the xTU-R in the embedded
operations channel of [ITU-T G.992.1] or [ITU-T G.992.2], or the overhead
messages of [ITU-T G.992.3], [ITU-T G.992.4], [ITU-T G.992.5] and
[ITU-T G.993.2], comprises up to 32 ASCII characters, null-terminated if it
is shorter than 32. It is recommended to contain the equipment serial number,
the equipment model and the equipment firmware version, encoded in that
order and separated by space characters: "<equipment serial
number><equipment model><equipment firmware version>". It is
recognized that legacy xTU-Rs may not support this format. This attribute
contains the first 16 characters. (R) (mandatory) (16 bytes)
xTU-R serial number part 2: This attribute contains the second 16 characters of the xTU-R
serial number. (R) (mandatory) (16 bytes)
xTU-C self-test results: This parameter reports the xTU-C self-test result. It is coded in two
fields. The most significant octet is 0 if the self-test passed and 1 if it failed.
The three least significant octets are a vendor-discretionary integer that can
be interpreted in combination with [ITU-T G.994.1] and the system vendor
ID. (R) (mandatory) (4 bytes)
xTU-R self-test results: This parameter defines the xTU-R self-test result. It is coded in two
fields. The most significant octet is 0 if the self-test passed and 1 if it failed.
The three least significant octets are a vendor-discretionary integer that can
be interpreted in combination with [ITU-T G.994.1] and the system vendor
xTU-C transmission system capability: This attribute lists xTU-C transmission system
capabilities. It is a bit map, defined in Table 9.7.12-1. (R) (mandatory)
(7 bytes)
NOTE 1 This attribute is only 7 bytes long. An eighth byte identifying VDSL2
capabilities is defined in the VDSL2 line inventory and status data part 1 managed
entity.
xTU-R transmission system capability: This attribute lists xTU-R transmission system
capabilities. It is a bit map, defined in Table 9.7.12-1. (R) (mandatory)
(7 bytes)
capabilities is defined in the VDSL2 line inventory and status data part 2 managed
entity.
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 follows:
0 Successful
1
Configuration error
This error occurs with inconsistencies in configuration parameters, for
example, when the line is initialized in an xDSL transmission system
whose xTU does not support the configured maximum delay or the
configured minimum or maximum data rate for one or more bearer
channels.
Configuration not feasible on the line

This error occurs if the minimum data rate cannot be achieved on the
line with the minimum noise margin, maximum PSD level, maximum
delay and maximum bit error ratio for one or more bearer channels.
238
Rec. ITU-T G.988 (10/2012)
Communication problem
This error occurs, for example, due to corrupted messages, bad syntax
messages, if no common mode can be selected in the ITU-T G.994.1
handshake procedure, or due to a timeout.
No peer xTU detected

This error occurs if the peer xTU is not powered or not connected or
if the line is too long to allow detection of a peer xTU.
Any other or unknown initialization failure cause.

Actions
Get
Notifications
None.
Table 9.7.12-1 describes the xTU transmission system capability attributes in xDSL status managed
entities. It is a bit map (0 if not allowed, 1 if allowed) with the following definition:
Table 9.7.12-1 xTU transmission system table
Bit
Representation
Octet 1
1 (LSB)
[b-ATIS-0600413]
Annex C of [ETSI TS 101 388]
ITU-T G.992.1 operation over POTS non-overlapped spectrum (Annex A of [ITU-T G.992.1])
ITU-T G.992.1 operation over POTS overlapped spectrum (Annex A of [ITU-T G.992.1])
ITU-T G.992.1 operation over ISDN non-overlapped spectrum (Annex B of [ITU-T G.992.1])
ITU-T G.992.1 operation over ISDN overlapped spectrum (Annex B of [ITU-T G.992.1])
ITU-T G.992.1 operation in conjunction with TCM-ISDN non-overlapped spectrum (Annex C

of [ITU-T G.992.1])
ITU-T G.992.1 operation in conjunction with TCM-ISDN overlapped spectrum (Annex C of

[ITU-T G.992.1])
Octet 2
9
10
ITU-T G.992.2 operation over POTS overlapped spectrum (Annex B of [ITU-T G.992.2])
11

of [ITU-T G.992.2])
12

[ITU-T G.992.2])
13
14
15
16
Octet 3
17
18
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Rec. ITU-T G.988 (10/2012)
239

Bit
Representation
19
20
21
22
23

of [ITU-T G.992.3])
24

[ITU-T G.992.3]).
Octet 4
25
26
27
28
Reserved
Reserved
29
ITU-T G.992.3 All digital mode operation with non-overlapped spectrum (Annex I of
[ITU-T G.992.3])
30
ITU-T G.992.3 All digital mode operation with overlapped spectrum (Annex I of
[ITU-T G.992.3])
31
ITU-T G.992.3 All digital mode operation with non-overlapped spectrum (Annex J of
[ITU-T G.992.3])
32
ITU-T G.992.3 All digital mode operation with overlapped spectrum (Annex J of
[ITU-T G.992.3])
Octet 5
33
[ITU-T G.992.4])
34
[ITU-T G.992.4])
35
ITU-T G.992.3 Reach extended operation over POTS, Mode 1 (non-overlapped, wide
upstream) (Annex L of [ITU-T G.992.3])
36
ITU-T G.992.3 Reach extended operation over POTS, Mode 2 (non-overlapped, narrow
upstream) (Annex L of [ITU-T G.992.3])
37
ITU-T G.992.3 Reach extended operation over POTS, Mode 3 (overlapped, wide upstream)
(Annex L of [ITU-T G.992.3])
38
ITU-T G.992.3 Reach extended operation over POTS, Mode 4 (overlapped, narrow upstream)
(Annex L of [ITU-T G.992.3])
39
ITU-T G.992.3 Extended upstream operation over POTS non-overlapped spectrum (Annex M
of [ITU-T G.992.3])
40
ITU-T G.992.3 Extended upstream operation over POTS overlapped spectrum (Annex M of
[ITU-T G.992.3])
Octet 6
240
41
42
43
Rec. ITU-T G.988 (10/2012)

Bit
Representation
44
45

of [ITU-T G.992.5])
46

[ITU-T G.992.5])
47
[ITU-T G.992.5])
48
[ITU-T G.992.5])
Octet 7
49
ITU-T G.992.5 All digital mode operation with non-overlapped spectrum (Annex J of
[ITU-T G.992.5])
50
ITU-T G.992.5 All digital mode operation with overlapped spectrum (Annex J of
[ITU-T G.992.5])
51
ITU-T G.992.5 Extended upstream operation over POTS non-overlapped spectrum (Annex M
of [ITU-T G.992.5])
52
ITU-T G.992.5 Extended upstream operation over POTS overlapped spectrum (Annex M of
[ITU-T G.992.5])
Reserved
Reserved
Reserved
Reserved
53
54
55
56
Octet 8 (Note)
57
ITU-T G.993.2 region A (North America) (Annex A of [ITU-T G.993.2])
58
ITU-T G.993.2 region B (Europe) (Annex B of [ITU-T G.993.2])
59
60
61
62
63
64
ITU-T G.993.2 region C (Japan) (Annex C of [ITU-T G.993.2])

Reserved
Reserved
Reserved
Reserved
Reserved
NOTE For backward compatibility reasons, the eighth octet of this table is represented as a separate
attribute in separate managed entities.

This managed entity contains part 2 of the line inventory and status data for an xDSL UNI. The
ONU automatically creates or deletes an instance of this managed entity upon the creation or
deletion of a physical path termination point xDSL UNI part 1.
NOTE 1 [ITU-T G.997.1] specifies that bit rate attributes have granularity of 1000 bit/s. If ITU-T G.997.1
compliance is required, the ONU should only report values with this granularity.
Relationships
Rec. ITU-T G.988 (10/2012)
241
Attributes
xDSL transmission system: This parameter defines the transmission system in use. It is a
bit map, defined in Table 9.7.12-1. (R) (mandatory) (7 bytes)
capabilities in use is defined in the VDSL2 line inventory and status data part 1
managed entity.
Line power management state: The line has four possible power management states:
0 L0: Synchronized This line state occurs when the line has full
transmission (i.e., showtime).
1 L1: Power down data transmission This line state occurs 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 G.992.2] only.
2 L2: Power down data transmission This line state occurs 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 G.992.3] and [ITU-T G.992.4] only.
3 L3: No power This line state occurs when no power is transmitted
on the line at all.
Downstream line attenuation: The LATNds attribute is the squared magnitude of the
channel characteristics function H(f) averaged over this band, and measured
during loop diagnostic mode and initialization. The exact definition is
included in the relevant xDSL Recommendation. The attribute value ranges
from 0 (0.0 dB) to 1270 (127.0 dB) dB. The special value 0xFFFF indicates
that line attenuation is out of range. (R) (mandatory) (2 bytes)
NOTE 3 [ITU-T G.993.2] specifies a per-band array to represent this attribute. The
array is defined in the VDSL2 line inventory and status data part 3 managed entity.
In an ITU-T G.993.2 context, the downstream line attenuation attribute should be set
to 0 here, and populated in the VDSL2 line inventory and status data part 3 ME
instead.
Upstream line attenuation: The LATNus attribute is the squared magnitude of the channel
characteristics function H(f) averaged over this band, and measured during
loop diagnostic mode and initialization. The exact definition is included in
the relevant xDSL Recommendation. The attribute value ranges from 0 (0.0
dB) to 1270 (127.0 dB). The special value 0xFFFF indicates that line
attenuation is out of range. (R) (mandatory) (2 bytes)
In an ITU-T G.993.2 context, the upstream line attenuation attribute should be set to
0 here, and populated in the VDSL2 line inventory and status data part 3 ME
instead.
Downstream signal attenuation: The SATNds attribute is the measured difference in the
total power transmitted in this band by the xTU-C and the total power
received in this band by the xTU-R during loop diagnostic mode,
242
Rec. ITU-T G.988 (10/2012)
initialization and showtime. The exact definition is included in the relevant

xDSL Recommendation. The attribute value ranges from 0 (0.0 dB) to 1270
(127.0 dB). The special value 0xFFFF indicates that signal attenuation is out
of range. (R) (mandatory) (2 bytes)
NOTE 5 During showtime, only a subset of the subcarriers may be transmitted by
the xTU-C, as compared to loop diagnostic mode and initialization. Therefore, the
downstream signal attenuation value during showtime may be significantly lower
than the downstream signal attenuation value during loop diagnostic mode and
initialization.
In an ITU-T G.993.2 context, the downstream signal attenuation attribute should be
set to 0 here, and populated in the VDSL2 line inventory and status data part 3 ME
instead.
Upstream signal attenuation: The SATNus attribute is the measured difference in dB in

the total power transmitted in this band by the xTU-R and the total power
received in this band by the xTU-C during loop diagnostic mode,
initialization and showtime. The exact definition is included in the relevant
xDSL Recommendation. The attribute value ranges from 0 (0.0 dB) to 1270
(127.0 dB). The special value 0xFFFF indicates that signal attenuation is out
of range. (R) (mandatory) (2 bytes)
the xTU-R, as compared to loop diagnostic mode and initialization. Therefore, the
upstream signal attenuation value during showtime may be significantly lower than
the upstream signal attenuation value during loop diagnostic mode and initialization.
In an ITU-T G.993.2 context, the upstream signal attenuation attribute should be set
to 0 here, and populated in the VDSL2 line inventory and status data part 3 ME
instead.
Downstream signal-to-noise ratio margin: The downstream signal-to-noise ratio margin

SNRMds is the maximum increase of noise power received at the xTU-R,
such that the BER requirements can still be met for all downstream bearer
channels. The attribute value ranges from 0 (64.0 dB) to 1270 (+63.0 dB).
The special value 0xFFFF indicates that the attribute is out of range (R)
Upstream signal-to-noise ratio margin: The upstream signal-to-noise ratio margin
SNRMus is the maximum increase of noise power received at the xTU-C,
such that the BER requirements can still be met for all upstream bearer
channels. The attribute value ranges from 0 (64.0 dB) to 1270 (+63.0 dB).
The special value 0xFFFF indicates that the attribute is out of range. (R)
Downstream maximum attainable data rate: The ATTNDRds attribute indicates the
maximum downstream net data rate currently attainable. The rate is coded in
bit/s. (R) (mandatory) (4 bytes)
Upstream maximum attainable data rate: The ATTNDRus attribute indicates the
maximum upstream net data rate currently attainable. The rate is coded in
Downstream actual power spectrum density: The ACTPSDds attribute is the average
downstream transmit power spectrum density over the subcarriers in use
Rec. ITU-T G.988 (10/2012)
243
(subcarriers to which downstream user data are allocated) delivered by the

xTU-C at the U-C reference point, at the instant of measurement. The
attribute value ranges from 0 (90.0 dBm/Hz) to 900 (0.0 dBm/Hz). The
special value (0xFFFF) indicates that the parameter is out of range. (R)
Upstream actual power spectrum density: The ACTPSDus attribute is the average
upstream transmit power spectrum density over the subcarriers in use
(subcarriers to which upstream user data are allocated) delivered by the
xTU-R at the U-R reference point, at the instant of measurement. The
attribute value ranges from 0 (90.0 dBm/Hz) to 900 (0.0 dBm/Hz). The
special value 0xFFFF indicates that the attribute is out of range. (R)
Downstream actual aggregate transmit power: The ACTATPds attribute is the total
amount of transmit power delivered by the xTU-C at the U-C reference point,
at the instant of measurement. The attribute value ranges from 0 (31.0 dBm)
to 620 (+31.0 dBm). The special value (0xFFFF) indicates that the parameter
is out of range. (R) (mandatory) (2 bytes)
NOTE 9 The downstream nominal aggregate transmit power may be taken
as a best estimate of the parameter.
Upstream actual aggregate transmit power: The ACTATPus attribute is the total amount
of transmit power delivered by the xTU-R at the U-R reference point, at the
instant of measurement. The attribute value ranges from 0 (31.0 dBm) to
620 (+31.0 dBm). The special value (0xFFFF) indicates that the parameter is
out of range. (R) (mandatory) (2 bytes)
NOTE 10 The upstream nominal aggregate transmit power may be taken as a best
estimate of the parameter.
Initialization last state transmitted downstream: This attribute 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 xDSL Recommendations and are counted from 0 (if
[ITU-T G.994.1] is used) or 1 (if [ITU-T G.994.1] is not used) up to
showtime. This parameter must be interpreted along with the xDSL
transmission system capabilities.
This parameter is available only when, after a failed full initialization, line
diagnostic procedures are activated on the line. Line diagnostic procedures
can be activated by the operator of the system (through the loop diagnostics
mode forced attribute of the xDSL line configuration profile part 3) or
autonomously by the xTU-C or xTU-R.
244
Rec. ITU-T G.988 (10/2012)
Initialization last state transmitted upstream: This attribute 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 xDSL Recommendations and are counted from 0 (if [ITU-T
G.994.1] is used) or 1 (if [ITU-T G.994.1] is not used) up to showtime. This
parameter must be interpreted along with the xDSL transmission system
capabilities.
This parameter is available only when, after a failed full initialization, line
diagnostic procedures are activated on the line. Line diagnostic procedures
can be activated by the operator of the system (through the loop diagnostics
mode forced attribute of the xDSL line configuration profile part 3) or
autonomously by the xTU-C or xTU-R.
Actions
Get
Notifications
None.
This managed entity extends the attributes defined in the xDSL line inventory and status data
parts 1 and 2. This ME reports downstream attributes.
Relationships
This is one of the status MEs associated with an xDSL UNI. The ONU automatically creates
or deletes an instance of this managed entity upon creation or deletion of a physical path
termination point xDSL UNI part 1 that supports these attributes.
Attributes
instance of the physical path termination point xDSL UNI part 1 managed
entity. (R) (mandatory) (2 bytes)
TSSpsds table: This table contains downstream transmit spectrum shaping attributes
expressed as the set of breakpoints exchanged during [ITU-T G.994.1]. Each
breakpoint consists of a two-byte subcarrier index and the associated shaping
attribute. The shaping attribute is one byte, an integer value in the 0 to 126
range, represented as a multiple of 0.5 dB. The special value 127 indicates
that the subcarrier is not transmitted. (R) (mandatory) (3 * N bytes, where N
is the number of breakpoints)
HLINSCds: This attribute is the scale factor to be applied to the downstream Hlin(f)
values. It is coded as a 16-bit unsigned integer. This attribute is only
available after a loop diagnostic procedure. (R) (mandatory) (2 bytes)
HLINpsds table: This attribute is an array of complex coefficients {a, b} that represent the
downstream transfer function Hlin(f) in linear form. Each array entry
represents Hlin(f) = i*HLINGds*f for a particular subcarrier group index i,
ranging from 0 to min(NSds, 511). Hlin(f) may be reconstructed from the
array as ((HLINSCds/215)*((a(i) + j*b(i))/215)), where a(i) and b(i) are 2s
Rec. ITU-T G.988 (10/2012)
245
complement integers in the range (215 + 1) to (+215 1). The granularity of a

and b depends on the scale factor.
The special value a(i) = b(i) = 215 indicates that no measurement could be
done for this subcarrier group because it is out of the passband or that the
attenuation is out of range to be represented.
This attribute is only available after a loop diagnostic procedure. (R)
(mandatory) (4 * N bytes, where N is the number of subcarrier groups)
HLOGMTds: After a loop diagnostic procedure, this attribute contains the number of
symbols used to measure the downstream Hlog(f) values. It is a 16-bit
unsigned value that corresponds to the value specified in the corresponding
Recommendation (e.g., the number of symbols in a one-second interval for
[ITU-T G.992.3]). (R) (mandatory) (2 bytes)
HLOGpsds table: The HLOGpsds attribute contains an array of numbers m(i), where i is a
particular subcarrier group index, ranging from 0 to min(NSds, 511), and m
lies in the range 0..1022, with a granularity of 0.1 dB. The downstream
transfer function Hlog(f) can be reconstructed by the OLT management client
as (6 m(i)/10) dBm/Hz, with a range from +6 to approximately
96 dBm/Hz.
The special value m = 1023 indicates that no measurement could be done for
this subcarrier group because it is out of the passband or that the attenuation
is out of range to be represented.
(R) (mandatory) (2 * N bytes, where N is the number of subcarrier groups)
QLNMTds:
After a loop diagnostic procedure, the quiet line noise PSD measurement
time attribute contains the number of symbols used to measure the
downstream QLN(f) values. It is a 16-bit unsigned value that corresponds to
the value specified in the corresponding Recommendation (e.g., the number
of symbols in a one-second interval for [ITU-T G.992.3]). (R) (mandatory)
(2 bytes)
QLNpsds table: The quiet line noise PSD attribute contains an array of numbers n(i), where
i is a subcarrier group index, ranging from 0 to min(NSds, 511), and n lies in
the range 0..254, with a granularity of 0.5 dB. The downstream quiet line
noise function QLN(f) can be reconstructed by the OLT management client
as (23 n(i)/2) dBm/Hz, with a range from 150 to 23 dBm/Hz.
The special value n = 255 indicates that no measurement could be done for
this subcarrier group because it is out of the passband or that the noise PSD is
out of range to be represented.
(R) (mandatory) (N bytes, where N is the number of subcarrier groups)
SNRMTds:
246
After a loop diagnostic procedure, the SNR measurement time attribute

contains the number of symbols used to measure the downstream SNR(f)
values. It is a 16-bit unsigned value that corresponds to the value specified in
the corresponding Recommendation (e.g., the number of symbols in a onesecond interval for [ITU-T G.992.3]). (R) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
SNRpsds table: The SNRpsds attribute contains an array of numbers snr(i), where i is a
subcarrier group index, ranging from 0 to min(NSds, 511), and snr lies in the
range 0..254, with a granularity of 0.5 dB. The downstream SNR function
SNR(f) can be reconstructed by the OLT management client as
(32 + snr(i)/2) dBm/Hz, with a range from 160 to 32 dBm/Hz.
The special value snr = 255 indicates that no measurement could be done for
this subcarrier group because it is out of the passband or that the noise PSD is
out of range to be represented.
(R) (mandatory) (N bytes, where N is the number of subcarrier groups)
BITSpsds table: This attribute reports the downstream bits allocation table per subcarrier. It
is an array of values in the range 0..15 for subcarriers 0..NSds. Entries for
subcarriers out of the downstream medley set are set to 0. (R) (mandatory) (N
bytes, where N is the number of subcarriers)
GAINSpsds table: This attribute contains the downstream gain allocation table per
subcarrier. It is an array of integer values in the range 0..4093 for subcarriers
0..NSds. The gain is represented as a multiple of 1/512 on a linear scale.
Entries for subcarriers out of the downstream medley set are set to 0. (R)
(mandatory) (2N bytes, where N is the number of subcarriers)
Actions
Get, get next
Notifications
None.
parts 1, 2 and 3. This ME reports upstream attributes.
Relationships
This is one of the status data MEs associated with an xDSL UNI. The ONU automatically
creates or deletes an instance of this managed entity upon creation or deletion of a physical
path termination point xDSL UNI part 1 that supports these attributes.
Attributes
TSSpsus table: This attribute contains the upstream transmit spectrum shaping attributes,
expressed as the set of breakpoints exchanged during [ITU-T G.994.1]. Each
breakpoint consists of a two-byte subcarrier index and the associated shaping
attribute. The shaping attribute is one byte, a value in the range 0..126,
representing a multiple of 0.5 dB. The special value 127 indicates that the
subcarrier is not transmitted. (R) (mandatory) (3 * N bytes, where N is the
number of breakpoints)
HLINSCus: This attribute is a 16-bit unsigned integer, the scale factor to be applied to the
upstream Hlin(f) values. It is only available after a loop diagnostic procedure.
Rec. ITU-T G.988 (10/2012)
247
HLINpsus table: This attribute is an array of complex upstream Hlin(f) values in linear
scale. It is coded in the same way as the related downstream attribute
HLINpsds (see xDSL line inventory and status data part 3). This attribute is
only available after a loop diagnostic procedure. (R) (mandatory) (4N bytes,
where N is the number of subcarrier groups)
HLOGMTus: After a loop diagnostic procedure, this attribute contains the number of
symbols used to measure the upstream Hlog(f) values. Its value corresponds
to the value specified in the corresponding Recommendation (e.g., the
number of symbols in a one-second interval for [ITU-T G.992.3]). (R)
HLOGpsus table: This attribute is an array of real upstream Hlog(f) values. It is coded in
the same way as the related downstream attribute HLOGpsds (see xDSL line
inventory and status data part 3). (R) (mandatory) (2 * N bytes, where N is
the number of subcarrier groups)
QLNMTus:
After a loop diagnostic procedure, the quiet line noise PSD measurement
attribute contains the number of symbols used to measure the upstream
QLN(f) values. Its value corresponds to the value specified in the governing
QLNpsus table: The quiet line noise attribute represents an array of real upstream QLN(f)
values. It is coded in the same way as the related downstream attribute
QLNpsds (see xDSL line inventory and status data part 3). (R) (mandatory)
(N bytes, where N is the number of subcarrier groups)
SNRMTus:
After a loop diagnostic procedure, the SNR measurement time attribute

reports the number of symbols used to measure the upstream SNR(f) values.
Its value corresponds to the value specified in the governing
SNRpsus table: This attribute is an array of real upstream SNR(f) values. It is coded in the
same way as the related downstream attribute SNRpsds (see xDSL line
inventory and status data part 3). (R) (mandatory) (N bytes, where N is the
number of subcarrier groups)
BITSpsus table: This attribute contains the upstream bits allocation table per subcarrier. It
is an array in the range 0..15 for subcarriers 0..NSus. Entries for subcarriers
out of the upstream medley set are set to 0. (R) (mandatory) (N bytes, where
N is the number of subcarriers)
GAINSpsus table: This attribute contains the upstream gains allocation table per subcarrier.
It is an array in the range 0..4093 for subcarriers 0..NSus. The gain is
represented as a multiple of 1/512 on a linear scale. Entries for subcarriers
out of the upstream medley set are set to 0. (R) (mandatory) (2 * N bytes,
where N is the number of subcarriers)
Actions
Get, get next
Notifications
None.
248
Rec. ITU-T G.988 (10/2012)
9.7.16 VDSL2 line inventory and status data part 1

This managed entity extends the xDSL line configuration MEs. The ME name was chosen because
its attributes were initially unique to [ITU-T G.993.2] VDSL2. Due to continuing standards
development, some attributes and therefore this managed entity have also become applicable to
other Recommendations, specifically [ITU-T G.992.3] and [ITU-T G.992.5].
This ME contains general and downstream attributes.
Relationships
This is one of the status data MEs associated with an xDSL UNI. It is meaningful if the
PPTP supports [ITU-T G.992.3], [ITU-T G.992.5] or [ITU-T G.993.2]. The ONU
automatically creates or deletes an instance of this managed entity upon creation and
deletion of a physical path termination point xDSL UNI part 1 that supports these attributes.
Attributes
VDSL2 transmission system capability xTU-C: This attribute extends the xTU-C
transmission system capability attribute of the xDSL line inventory and status
data part 1 to include xTU-C VDSL2 capabilities. It is defined by bits 57..64
of Table 9.7.12-1. (R) (mandatory) (1 byte)
VDSL2 transmission system: This attribute reports the transmission system in use. It
extends the xDSL transmission system attribute of the xDSL line inventory
and status data part 2 managed entity with a byte that includes VDSL2
capabilities currently in use. It is defined by bits 57..64 of Table 9.7.12-1. (R)
VDSL2 profile: This attribute identifies the profile in use. It is a bit map (0 if not allowed, 1
if allowed) with the following definition:
Bit
Meaning
1 (LSB)
ITU-T G.993.2 profile 8c
ITU-T G.993.2 profile 8d

VDSL2 limit PSD mask and bandplan: This attribute defines the limit PSD mask and
band plan in use. It is a bit map as defined by Table 9.7.6-1. (R) (mandatory)
(8 bytes)
VDSL2 US0 PSD mask: This attribute defines the US0 PSD mask in use. It is a bit map as
defined by Table 9.7.6-2. (R) (mandatory) (4 bytes)
Rec. ITU-T G.988 (10/2012)
249
ACTSNRMODEds: This attribute indicates whether transmitter referred virtual noise is

active on the line in the downstream direction.
1 Virtual noise inactive
2 Virtual noise active
The following four attributes have similar definitions. In each case, valid attribute values are 1, 2, 4,
8. In ADSL applications, the corresponding value is fixed at 1, and therefore need not be specified.
For VDSL2, it is equal to the size of the subcarrier group used to compute these attributes (see
clause 11.4.1 of [ITU-T G.993.2]).
HLINGds:
This attribute contains the number of subcarriers per group used to report
HLINpsds. (R) (mandatory) (1 byte)
HLOGGds:
HLOGpsds. (R) (mandatory) (1 byte)
QLNGds:
QLNpsds. (R) (mandatory) (1 byte)
SNRGds:
SNRpsds. (R) (mandatory) (1 byte)
MREFPSDds table: The downstream medley reference PSD table contains the set of
breakpoints exchanged in the MREFPSDds fields of the O-PRM message of
[ITU-T G.993.2].
The format is similar to that specified for the PSD descriptor in
[ITU-T G.993.2]. In [ITU-T G.993.2], the first byte gives the size of the
table, each entry of which is three bytes. In the OMCI definition, the first
byte is omitted because the size of the table is known from the response to
the get command.
(R) (mandatory) (3 * N bytes, where N is the number of breakpoints)
TRELLISds: This attribute reports whether trellis coding is in use in the downstream
direction.
0 Trellis not used
1 Trellis used
(R) (mandatory for [ITU-T G.993.2] VDSL2, optional for others) (1 byte)
Actual rate adaptation mode downstream: The ACT-RA-MODEds attribute indicates the
actual active RA mode in the downstream direction.
1 MANUAL
2 AT_INIT
3 DYNAMIC
4 DYNAMIC with SOS ([ITU-T G.993.2] only)
Actual impulse noise protection ROC downstream: The ACTINP-ROC-ds attribute
reports the actual impulse noise protection (INP) of the robust operations
channel (ROC) in the downstream direction. The format and usage is
identical to that of the ACTINP attribute defined in the xDSL channel
downstream status data ME. (R) (optional) (1 byte)
SNR margin ROC downstream: The SNRM-ROC-ds attribute reports the actual signal-tonoise margin of the ROC in the downstream direction. Its value ranges from
250
Rec. ITU-T G.988 (10/2012)
0 (64.0 dB) to 1270 (+63.0 dB). The special value 0xFFFF indicates that the
attribute is out of range. (R) (optional) (2 bytes)
Actions
Get, get next
Notifications
None.
development, some attributes and therefore this managed entity have also become applicable to
other Recommendations, specifically [ITU-T G.992.3] and [ITU-T G.992.5].
This ME contains upstream attributes.
Relationships
This is one of the status data MEs associated with an xDSL UNI. It is meaningful if the
PPTP supports [ITU-T G.992.3], [ITU-T G.992.5] or [ITU-T G.993.2]. The ONU
automatically creates or deletes an instance of this managed entity upon creation and
deletion of a physical path termination point xDSL UNI part 1 that supports these attributes.
Attributes
VDSL2 transmission system capability xTU-R: This attribute extends the xTU-R
transmission system capability attribute of the xDSL line inventory and status
data part 1 to include xTU-R VDSL2 capabilities. It is a defined by bits
57..64 of Table 9.7.12-1. (R) (mandatory) (1 byte)
ACTSNRMODEus: This attribute indicates whether transmitter referred virtual noise is
active on the line in the upstream direction.
1 Virtual noise inactive
2 Virtual noise active
UPBOKLE: This attribute contains the electrical length estimated by the VTU-O
expressed in dB at 1 MHz, kl0 (see O-UPDATE in clause 12.3.3.2.1.2 of
[ITU-T G.993.2]). This is the final electrical length that would have been sent
from the VTU-O to the VTU-R if the electrical length were not forced by the
OLT. The value lies in the range 0 (0.0 dB) to 1280 (128.0 dB) (R)
The following four attributes have similar definitions. In each case, valid attribute values are 1, 2, 4,
8. In ADSL applications, the corresponding value is fixed at 1, and therefore need not be specified.
For VDSL2, it is equal to the size of the subcarrier group used to compute these attributes (see
clause 11.4.1 of [ITU-T G.993.2]).
HLINGus:
This attribute is the number of subcarriers per group used to report

HLINpsus. (R) (mandatory) (1 byte)
Rec. ITU-T G.988 (10/2012)
251
HLOGGus:
This attribute is the number of subcarriers per group used to report

HLOGpsus. (R) (mandatory) (1 byte)
QLNGus:
This attribute is the number of subcarriers per group used to report QLNpsus.
SNRGus:
This attribute is the number of subcarriers per group used to report SNRpsus.
MREFPSDus table: The upstream medley reference PSD attribute contains the set of
breakpoints exchanged in the MREFPSDus fields of the R-PRM message of
[ITU-T G.993.2].
The format is similar to that specified for the PSD descriptor in
[ITU-T G.993.2]. In [ITU-T G.993.2], the first byte gives the size of the
table, each entry of which is three bytes. In the OMCI definition, the first
byte is omitted because the size of the table is known from the response to
the get command.
(R) (mandatory) (3 * N bytes, where N is the number of breakpoints)
TRELLISus: This attribute reports whether trellis coding is in use in the upstream
direction.
0 Trellis not used
1 Trellis used
ACTUALCE: This attribute reports the cyclic extension used on the line. It is coded as an
unsigned integer from 2 to 16 in units of N/32 samples, where 2N is the IDFT
size. (R) (mandatory) (1 byte)
UPBOKLE-R: This attribute contains the electrical length estimated by the VTU-R
expressed in dB at 1 MHz. This is the value contained in the message
R-MSG1 (see clause 12.3.3.2.2.1of [ITU-T G.993.2]). Its value lies in the
range 0 (0.0 dB) to 1280 (128.0 dB) (R) (optional) (2 bytes)
Actual rate adaptation mode upstream: The ACT-RA-MODEus attribute indicates the
actual active RA mode in the upstream direction.
1 MANUAL
2 AT_INIT
3 DYNAMIC
4 DYNAMIC with SOS ([ITU-T G.993.2] only)
Actual impulse noise protection ROC upstream: The ACTINP-ROC-us attribute reports
the actual impulse noise protection (INP) of the robust operations channel
(ROC) in the upstream direction. The format and usage is identical to that of
the ACTINP attribute defined in the xDSL channel upstream status data ME.
SNR margin ROC upstream: The SNRM-ROC-us attribute reports the actual signal-tonoise margin of the ROC in the upstream direction. Its value ranges from 0
(64.0 dB) to 1270 (+63.0 dB). The special value 0xFFFF indicates that the
attribute is out of range. (R) (optional) (2 bytes)
Actions
Get, get next
252
Rec. ITU-T G.988 (10/2012)
Notifications
None.
This managed entity extends the other xDSL line inventory and status data MEs with attributes
specific to VDSL2. This ME contains per-band attributes for both directions. These same attributes
are defined in the xDSL line inventory and status data part 2 managed entity, but only for a single
band. [ITU-T G.993.2] allows for VDSL2 to have as many as five bands upstream and as many as
five bands downstream.
Relationships
This is one of the status data MEs associated with an xDSL UNI. It is required only if
VDSL2 is supported by the PPTP. The ONU automatically creates or deletes an instance of
this managed entity upon creation or deletion of a PPTP xDSL UNI part 1 that supports
these attributes.
Attributes
Upstream bands count: This attribute reports the number of upstream bands. It can be used
to filter the upstream attributes. All upstream attributes are arrays of per-band
entries, of which the first upstream bands count are populated. The contents
of the arrays for unused frequency bands are unspecified. The original
attributes were allocated for as many as four upstream bands, US0, 1, 2, 3;
optional extended attributes have been added to accommodate the possibility
that five upstream bands may be needed. (R) (mandatory) (1 byte)
Downstream bands count: This attribute reports the number of downstream bands. It can
be used to filter the downstream attributes. All downstream attributes are
arrays of per-band entries, of which the first downstream bands count are
populated. The contents of the arrays for unused frequency bands are
unspecified. The original attributes were allocated for as many as three
downstream bands, DS1, 2, 3; optional extended attributes have been added
to accommodate the possibility that five downstream bands may be needed.
Downstream line attenuation per band: The LATNds attribute is defined per usable band.
It is the squared magnitude of the channel characteristics function H(f)
averaged over this band, and measured during loop diagnostic mode and
initialization. The exact definition is included in the relevant xDSL
Recommendation. The upstream line attenuation per band ranges from 0
(0.0 dB) to 1270 (+127.0 dB). The special value 0xFFFF indicates the line
attenuation per band is out of range to be represented. (R) (mandatory)
(3 bands * 2 bytes = 6 bytes)
Upstream line attenuation per band: The LATNus attribute is defined per usable band. It
is the squared magnitude of the channel characteristics function H(f)
averaged over this band, and measured during loop diagnostic mode and
initialization. The exact definition is included in the relevant xDSL
Recommendation. The upstream line attenuation per band ranges from 0
(0.0 dB) to 1270 (+127.0 dB). The special value 0xFFFF indicates that line
Rec. ITU-T G.988 (10/2012)
253
attenuation per band is out of range to be represented. (R) (mandatory)

Downstream signal attenuation per band: The SATNds attribute is defined per usable
band. It is the measured difference in the total power transmitted in this band
by the xTU-C and the total power received by the xTU-R during loop
diagnostic mode, initialization and showtime. The exact definition is included
in the relevant xDSL Recommendation. The downstream signal attenuation
per band ranges from 0 (0.0 dB) to 1270 (+127.0 dB). The special value
0xFFFF indicates that signal attenuation per band is out of range to be
represented. (R) (mandatory) (3 bands * 2 bytes = 6 bytes)
the xTU-C, as compared to loop diagnostic mode and initialization. Therefore, the
downstream signal attenuation value during showtime may be significantly lower
than the downstream signal attenuation value during loop diagnostic mode and
initialization.
Upstream signal attenuation per band: The SATNus attribute is defined per usable band.
It is the measured difference in dB in the total power transmitted in this band
by the xTU-R and the total power received in this band by the xTU-C during
loop diagnostic mode, initialization and showtime. The exact definition is
included in the relevant xDSL Recommendation. The upstream signal
attenuation per band ranges from 0 (0.0 dB) to 1270 (+127.0 dB). The special
value 0xFFFF indicates the signal attenuation per band is out of range to be
represented. (R) (mandatory) (4 bands * 2 bytes = 8 bytes)
the xTU-R, as compared to loop diagnostic mode and initialization. Therefore, the
upstream signal attenuation value during showtime may be significantly lower than
the upstream signal attenuation value during loop diagnostic mode and initialization.
Downstream signal-to-noise ratio margin per band: The SNRMpbds attribute is defined
per usable band. The downstream signal-to-noise ratio margin per band is the
maximum increase of noise power received at the xTU-R, such that the BER
requirements are met for all downstream bearer channels. Each array value
ranges from 0 (64.0 dB) to 1270 (+63.0 dB). The special value 0xFFFF
indicates that the attribute is out of range to be represented. (R) (mandatory)
Upstream signal-to-noise ratio margin per band: The SNRMpbus attribute is defined per
usable band. The upstream signal-to-noise ratio margin per band is the
maximum increase of noise power received at the xTU-C, such that the BER
requirements are met for all upstream bearer channels. Each array value
ranges from 0 (64.0 dB) to 1270 (+63.0 dB). The special value 0xFFFF
indicates that the attribute is out of range to be represented. (R) (mandatory)
Downstream line attenuation extension: This attribute extends LATNds when more than
three downstream bands are used. It is defined in the same way as the
downstream line attenuation per band attribute. (R) (optional) (2 bands *
2 bytes = 4 bytes)
Upstream line attenuation extension: This attribute extends LATNus when more than four
upstream bands are used. It is defined in the same way as the upstream line
attenuation per band attribute. (R) (optional) (1 band * 2 bytes = 2 bytes)
254
Rec. ITU-T G.988 (10/2012)
Downstream signal attenuation extension: This attribute extends SATNds when more
than three downstream bands are used. It is defined in the same way as the
downstream signal attenuation per band attribute. (R) (optional) (2 bands *
2 bytes = 4 bytes)
Upstream signal attenuation extension: This attribute extends SATNus when more than
four upstream bands are used. It is defined in the same way as the upstream
signal attenuation per band attribute. (R) (optional) (1 band *
2 bytes = 2 bytes)
Downstream signal-to-noise ratio margin extension: This attribute extends SNRMpbds
when more than three downstream bands are used. It is defined in the same
way as the downstream signal-to-noise ratio margin per band attribute. (R)
(optional) (2 bands * 2 bytes = 4 bytes)
Upstream signal-to-noise ratio margin extension: This attribute extends SNRMpbus when
more than four upstream bands are used. It is defined in the same way as the
upstream signal-to-noise ratio margin per band attribute. (R) (optional)
(1 band * 2 bytes = 2 bytes)
Actions
Get
Notifications
None.
9.7.19 xDSL channel downstream status data
This managed entity contains downstream channel status data for an xDSL UNI. The ONU
automatically creates or deletes instances of this managed entity upon the creation or deletion of a
NOTE [ITU-T G.997.1] specifies that bit rate attributes have a granularity of 1000 bit/s. If ITU-T G.997.1
compliance is required, the ONU should only report values with this granularity.
Relationships
One or more instances of this managed entity are associated with an instance of an xDSL
UNI.
Attributes
The two most significant bits of the first byte are the bearer channel ID.
Excluding the first two bits of the first byte, the remaining part of the
managed entity ID is identical to that of this ME's parent physical path
termination point xDSL UNI part 1. (R) (mandatory) (2 bytes)
Actual interleaving delay: This attribute is the actual one-way interleaving delay
introduced by the PMS-TC between the alpha and beta reference points,
excluding delay in the L1 and L2 states. In the L1 and L2 states, the attribute
contains the interleaving delay in the previous L0 state. For ADSL, this
attribute is derived from the S and D attributes as cap(S*D)/4 ms, where S is
the number of symbols per codeword, D is the interleaving depth and cap()
denotes rounding to the next higher integer. For [ITU-T G.993.2], this
attribute is computed according to the formula in clause 9.7 of
[ITU-T G.993.2]. The actual interleaving delay is coded in ms, rounded to the
nearest ms. (R) (mandatory) (1 byte)
Rec. ITU-T G.988 (10/2012)
255
Actual data rate: This parameter reports the actual net data rate of the bearer channel,
excluding the rate in the L1 and L2 states. In the L1 or L2 state, 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 of the bearer channel
just before the latest rate change event occurred, excluding transitions
between the L0 state and the 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)
Actual impulse noise protection: The ACTINP attribute reports the actual impulse noise
protection (INP) on the bearer channel in the L0 state. In the L1 or L2 state,
the attribute contains the INP in the previous L0 state. The value of this
attribute is a number of DMT symbols, with a granularity of 0.1 symbols. Its
range is from 0 (0.0 symbols) to 254 (25.4 symbols). The special value 255
indicates an ACTINP higher than 25.4. (R) (optional for [ITU-T G.992.1],
mandatory for other xDSL Recommendations that support this attribute)
(1 byte)
Actual size of Reed-Solomon codeword: The NFEC attribute reports the actual ReedSolomon codeword size used in the latency path in which the bearer channel
is transported. The value is coded in bytes, and ranges from 0..255. (R)
(mandatory for [ITU-T G.993.2] VDSL2, optional for others) (1 byte)
Actual number of Reed-Solomon redundancy bytes: The RFEC attribute reports the
actual number of Reed-Solomon redundancy bytes per codeword used in the
latency path in which the bearer channel is transported. The value is coded in
bytes, and ranges from 0..16. The value 0 indicates no Reed-Solomon coding.
Actual number of bits per symbol: The LSYMB attribute reports the actual number of bits
per symbol assigned to the latency path in which the bearer channel is
transported, excluding trellis overhead. The value is coded in bits, and ranges
from 0..65535. (R) (mandatory for [ITU-T G.993.2] VDSL2, optional for
others) (2 bytes)
Actual interleaving depth: The INTLVDEPTH attribute reports the actual depth of the
interleaver used in the latency path in which the bearer channel is
transported. The value ranges from 1..4096 in steps of 1. The value 1
indicates no interleaving. (R) (mandatory for [ITU-T G.993.2] VDSL2,
optional for others) (2 bytes)
Actual interleaving block length: The INTLVBLOCK attribute reports the actual block
length of the interleaver used in the latency path in which the bearer channel
is transported. The value ranges from 4..255 in steps of 1. (R) (mandatory for
[ITU-T G.993.2] VDSL2, undefined for others) (1 byte)
Actual latency path: The LPATH attribute reports the index of the actual latency path in
which the bearer channel is transported. Valid values are 0..3. In
[ITU-T G.992.1], the fast path is mapped to latency index 0; the interleaved
path to index 1. (R) (mandatory for [ITU-T G.993.2] VDSL2, optional for
others) (1 byte)
Actions
Get
256
Rec. ITU-T G.988 (10/2012)
Notifications
None.
9.7.20 xDSL channel upstream status data
This managed entity contains upstream channel status data for an xDSL UNI. The ONU
automatically creates or deletes instances of this managed entity upon the creation or deletion of a
Relationships
One or more instances of this managed entity are associated with an instance of an xDSL
UNI.
Attributes
termination point xDSL UNI part 1. (R) (mandatory) (2 bytes)
Actual interleaving delay: This attribute is the actual one-way interleaving delay
introduced by the PMS-TC between the alpha and beta reference points,
excluding the L1 and L2 states. In the L1 and L2 states, this attribute contains
the interleaving delay in the previous L0 state. For ADSL, this attribute is
derived from the S and D attributes as cap(S*D)/4 ms, where S is the number
of symbols per codeword, D is the interleaving depth and cap() denotes
rounding to the next higher integer. For [ITU-T G.993.2], this attribute is
computed according to the formula in clause 9.7 of [ITU-T G.993.2]. The
actual interleaving delay is coded in ms, rounded to the nearest ms. (R)
Actual data rate: This parameter reports the actual net data rate of the bearer channel,
excluding the L1 and L2 states. In the L1 or L2 state, the parameter contains
the net data rate in the previous L0 state. The data rate is coded in bit/s. (R)
Previous data rate: This parameter reports the previous net data rate of the bearer channel
just before the latest rate change event occurred, excluding transitions
between the L0 state and the L1 or L2 state. 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
Actual impulse noise protection: The ACTINP attribute reports the actual impulse noise
protection (INP) on the bearer channel in the L0 state. In the L1 or L2 state,
the attribute contains the INP in the previous L0 state. The value is coded in
fractions of DMT symbols with a granularity of 0.1 symbols. The range is
from 0 (0.0 symbols) to 254 (25.4 symbols). The special value 255 indicates
an ACTINP higher than 25.4. (R) (mandatory for [ITU-T G.993.2] VDSL2,
optional for other xDSL Recommendations that support it) (1 byte)
Impulse noise protection reporting mode: The INPREPORT attribute reports the method
used to compute the ACTINP. If set to 0, the ACTINP is computed according
to the INP_no_erasure formula (clause 9.6 of [ITU-T G.993.2]). If set to 1,
ACTINP is the value estimated by the xTU receiver. (R) (mandatory for
[ITU-T G.993.2] VDSL2) (1 byte)
Rec. ITU-T G.988 (10/2012)
257
Actual size of Reed-Solomon codeword: The NFEC attribute reports the actual ReedSolomon codeword size used in the latency path in which the bearer channel
is transported. Its value is coded in bytes in the range 0..255. (R) (mandatory
for [ITU-T G.993.2] VDSL2, optional for others) (1 byte)
Actual number of Reed-Solomon redundancy bytes: The RFEC attribute reports the
actual number of Reed-Solomon redundancy bytes per codeword used in the
latency path in which the bearer channel is transported. Its value is coded in
bytes in the range 0..16. The value 0 indicates no Reed-Solomon coding. (R)
(mandatory for [ITU-T G.993.2] VDSL2, optional for others) (1 byte)
Actual number of bits per symbol: The LSYMB attribute reports the actual number of bits
per symbol assigned to the latency path in which the bearer channel is
transported, excluding trellis overhead. Its value is coded in bits in the range
0..65535. (R) (mandatory for [ITU-T G.993.2] VDSL2, optional for others)
(2 bytes)
Actual interleaving depth: The INTLVDEPTH attribute reports the actual depth of the
interleaver used in the latency path in which the bearer channel is
transported. Its value ranges from 1..4096 in steps of 1. The value 1 indicates
no interleaving. (R) (mandatory for [ITU-T G.993.2] VDSL2, optional for
others) (2 bytes)
Actual interleaving block length: The INTLVBLOCK attribute reports the actual block
length of the interleaver used in the latency part in which the bearer channel
is transported. Its value ranges from 4..255 in steps of 1. (R) (mandatory for
[ITU-T G.993.2] VDSL2, optional for others) (1 byte)
Actual latency path: The LPATH attribute reports the index of the actual latency path in
which the bearer channel is transported. Valid values are 0..3. In
[ITU-T G.992.1], the fast path is mapped to latency index 0; the interleaved
path to index 1. (R) (mandatory for [ITU-T G.993.2] VDSL2, optional for
others) (1 byte)
Actions
Get
Notifications
None.
9.7.21 xDSL xTU-C performance monitoring history data
This managed entity collects performance monitoring data on the xTU-C to xTU-R path as seen
from the xTU-C. Instances of this managed entity are created and deleted by the OLT.
Relationships
Attributes
instance of the physical path termination point xDSL UNI part 1. (R,
258
Rec. ITU-T G.988 (10/2012)
managed entities that contain PM threshold values. (R, W, Set-by-create)
Loss of frame seconds: (R) (mandatory) (2 bytes)
Loss of signal seconds: (R) (mandatory) (2 bytes)
Loss of link seconds: (R) (mandatory) (2 bytes)
Loss of power seconds: (R) (mandatory) (2 bytes)
Errored seconds: This attribute counts one-second intervals with one or more CRC-8
anomalies summed over all received bearer channels, or one or more LOS
defects, or one or more SEF defects, or one or more LPR defects. (R)
Severely errored seconds: This attribute counts severely errored seconds (SES-L). An SES
is declared if, during a one-second interval, there were 18 or more CRC-8
anomalies in one or more of the received bearer channels, or one or more
LOS defects, or one or more SEF defects, or one or more LPR defects.
If the relevant Recommendation ([ITU-T G.992.3], [ITU-T G.992.5], or
[ITU-T G.993.2]) supports a one-second normalized CRC-8 anomaly counter
increment, the one-second SES counter follows this value instead of counting
CRC-8 anomalies directly.
If a common CRC is applied over multiple bearer channels, then each related
CRC-8 anomaly is counted only once for the whole set of bearer channels
over which the CRC is applied.
Line initializations: This attribute counts the total number of full initializations attempted
on the line, both successful and failed. (R) (mandatory) (2 bytes)
Failed line initializations: This attribute counts the total number of failed full initializations
during the accumulation period. A failed full initialization occurs when
showtime is not reached at the end of the full initialization procedure. (R)
Short initializations: This attribute counts the total number of fast retrains or short
initializations attempted on the line, successful and failed. Fast retrain is
defined in [ITU-T G.992.2]. Short initialization is defined in
[ITU-T G.992.3] and [ITU-T G.992.4]. (R) (optional) (2 bytes)
Failed short initializations: This attribute counts the total number of failed fast retrains or
short initializations during the accumulation period, e.g., when:
a CRC error is detected
a timeout occurs
a fast retrain profile is unknown.
Unavailable seconds: This attribute counts one-second intervals during which the xDSL
UNI is unavailable. The line becomes unavailable at the onset of ten
Rec. ITU-T G.988 (10/2012)
259
contiguous SES-Ls. The ten SES-Ls are included in unavailable time. Once
unavailable, the line becomes available at the onset of ten contiguous seconds
that are not severely errored. The ten seconds with no SES-Ls are excluded
from unavailable time. Some attribute counts are inhibited during
unavailability see clause 7.2.7.13 of [ITU-T G.997.1]. (R) (mandatory)
(2 bytes)
SOS success count, near end: The SOS-SUCCESS-NE attribute is a count of the total
number of successful SOS procedures initiated by the near-end xTU on the
line during the accumulation period. Successful SOS is defined in
clause 12.1.4 of [ITU-T G.993.2]. (R) (optional) (2 bytes)
SOS success count, far end: The SOS-SUCCESS-FE attribute is a count of the total
number of successful SOS procedures initiated by the far-end xTU on the line
during the accumulation period. Successful SOS is defined in clause 12.1.4 of
[ITU-T G.993.2]. (R) (optional) (2 bytes)
Actions
Notifications
Alarm number
Threshold value attribute #

(Note)
Loss of frame seconds
Loss of signal seconds
Loss of link seconds
Loss of power seconds
Errored seconds
Severely errored seconds
Line initializations
Failed line initializations
Short initializations
Failed short initializations
10
10
FEC seconds
11
11
Unavailable seconds
12
9.7.22 xDSL xTU-R performance monitoring history data

This managed entity collects performance monitoring data of the xTU-C to xTU-R path as seen
from the xTU-R. Instances of this managed entity are created and deleted by the OLT.
Relationships
260
Rec. ITU-T G.988 (10/2012)
Attributes
instance of the physical path termination point xDSL UNI part 1. (R,
Loss of frame seconds: (R) (mandatory) (2 bytes)
Loss of signal seconds: (R) (mandatory) (2 bytes)
Loss of power seconds: (R) (mandatory) (2 bytes)
Errored seconds: This attribute counts one-second intervals with one or more FEBE
anomalies summed over all transmitted bearer channels, or one or more
LOS-FE defects, or one or more RDI defects, or one or more LPR-FE
defects. (R) (mandatory) (2 bytes)
Severely errored seconds: This attribute counts severely errored seconds (SES-LFE). An
SES is declared if, during a one-second interval, 18 or more FEBE anomalies
were reported across the totality of bearer channels, or there were one or
more far-end LOS defects, or one or more RDI defects, or one or more
LPR-FE defects.
If the relevant Recommendation ([ITU-T G.992.3], [ITU-T G.992.5], or
[ITU-T G.993.2]) supports a one-second normalized CRC-8 anomaly counter
increment, the one-second SES counter follows this value instead of counting
FEBE anomalies directly.
If a CRC is applied for multiple bearer channels, then each related FEBE
anomaly is counted only once for the whole set of related bearer channels.
Unavailable seconds: This attribute counts one-second intervals during which the far-end
xDSL termination is unavailable.
The far-end xDSL termination becomes unavailable at the onset of ten
contiguous SES-LFEs. The ten SES-LFEs are included in unavailable time.
Once unavailable, the far-end line becomes available at the onset of ten
contiguous seconds with no SES-LFEs. The ten seconds with no SES-LFEs
are excluded from unavailable time. Some attribute counts are inhibited
during unavailability see clause 7.2.7.13 of [ITU-T G.997.1].
Actions
Rec. ITU-T G.988 (10/2012)
261
Notifications
Alarm
number
Loss of frame seconds
Loss of power seconds
Errored seconds
Severely errored seconds
FEC seconds
Unavailable seconds
9.7.23 xDSL xTU-C channel performance monitoring history data

This managed entity collects performance monitoring data of an xTU-C to xTU-R channel as seen
from the xTU-C. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an xDSL bearer channel. Several
instances may therefore be associated with an xDSL UNI.
Attributes
termination point xDSL UNI part 1. (R, Set-by-create) (mandatory) (2 bytes)
Corrected blocks: This attribute counts blocks received with errors that were corrected on
this channel. (R) (mandatory) (4 bytes)
Uncorrected blocks: This attribute counts blocks received with uncorrectable errors on this
channel. (R) (mandatory) (4 bytes)
Transmitted blocks: This attribute counts encoded blocks transmitted on this channel. (R)
Received blocks: This attribute counts encoded blocks received on this channel. (R)
Code violations: This attribute counts CRC-8 anomalies in the bearer channel. (R)
262
Rec. ITU-T G.988 (10/2012)
Forward error corrections: This attribute counts FEC anomalies in the bearer channel. (R)
Actions
Notifications
Alarm
number
Corrected blocks
Uncorrected blocks
Code violations
Forward error corrections
9.7.24 xDSL xTU-R channel performance monitoring history data

This managed entity collects performance monitoring data of the xTU-C to xTU-R channel as seen
from the xTU-R. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an xDSL bearer channel. Several
instances may therefore be associated with an xDSL UNI.
Attributes
Corrected blocks: This attribute counts blocks received with errors that were corrected on
this channel. (R) (mandatory) (4 bytes)
Uncorrected blocks: This attribute counts blocks received with uncorrectable errors on this
channel. (R) (mandatory) (4 bytes)
Transmitted blocks: This attribute counts encoded blocks transmitted on this channel. (R)
Received blocks: This attribute counts encoded blocks received on this channel. (R)
Rec. ITU-T G.988 (10/2012)
263
Code violations: This attribute counts FEBE anomalies reported in the downstream bearer
channel. If the CRC is applied over multiple bearer channels, then each
related FEBE anomaly increments each of the counters related to the
individual bearer channels. (R) (mandatory) (2 bytes)
Forward error corrections: This attribute counts FFEC anomalies reported in the
downstream bearer channel. If FEC is applied over multiple bearer channels,
each related FFEC anomaly increments each of the counters related to the
individual bearer channels. (R) (mandatory) (2 bytes)
Actions
Notifications
Alarm
number
Corrected blocks
Uncorrected blocks
Code violations
Forward error corrections
9.7.25 TC adaptor performance monitoring history data xDSL

This managed entity collects performance monitoring data of an xTU-C to xTU-R ATM data path.
Relationships
Attributes
Threshold data1/2 ID: This attribute points to an instance of the threshold data1 managed
Near-end HEC violation count: This attribute counts near-end HEC anomalies in the ATM
data path. (R) (mandatory) (2 bytes)
264
Rec. ITU-T G.988 (10/2012)
Near-end delineated total cell count (CD-P): This attribute counts 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. (R) (mandatory) (4 bytes)
Near-end user total cell count: This attribute counts the total number of cells in the ATM
data path delivered at the V-C interface. (R) (mandatory) (4 bytes)
Near-end idle cell bit error count: This attribute counts cells with bit errors in the ATM
data path idle payload received at the near end. (R) (mandatory) (2 bytes)
Far-end HEC violation count: This attribute counts far-end HEC anomalies in the ATM
data path. (R) (mandatory) (2 bytes)
Far-end delineated total cell count: This attribute counts 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: This attribute counts the total number of cells in the ATM
data path delivered at the T-R interface. (R) (mandatory) (4 bytes)
Far-end idle cell bit error count: This attribute counts cells with bit errors in the ATM data
path idle payload received at the far end. (R) (mandatory) (2 bytes)
Actions
Notifications
Alarm
number
Near-end HEC violation
Near-end idle cell bit error count
Far-end HEC violation count
Far-end idle cell bit error count
9.7.26 VDSL2 line configuration extensions 2

development, two of the attributes (FEXT and NEXT TXREFVNds) are also used in
[ITU-T G.992.3] and [ITU-T G.992.5]. This managed entity therefore pertains to the latter
Recommendations as well as to [ITU-T G.993.2].
The attributes of this ME are further defined in [ITU-T G.997.1].
An instance of this managed entity is created and deleted by the OLT.
Relationships
Rec. ITU-T G.988 (10/2012)
265
together through a common managed entity ID. (The client physical path termination point xDSL
UNI part 1 has a single pointer, which refers to the entire set of line configuration parts.)
Attributes
to a given physical path termination point xDSL must share a common
SOS time downstream: The SOS-TIME-ds attribute is used in the specification of receiver
initiated SOS (see clause 13.4.3 of [ITU-T G.993.2]). If the attribute value is
not zero, the standard SOS triggering criteria are enabled, and the value
specifies the duration of the window used in the standard SOS triggering
criteria in the downstream direction. The special value zero indicates that the
standard SOS triggering criteria are disabled, i.e., vendor-discretionary values
may be used instead of the values configured in the MIB for the following
parameters: SOS-NTONES-ds, SOS-CRC-ds, SOS-TIME-ds. The valid
range of non-zero values is from 1..255, specifying 64 to 16320 ms in steps
of 64 ms. (R, W, Set-by-create) (optional) (1 byte)
SOS time upstream: The SOS-TIME-us attribute is used in the specification of receiver
initiated SOS (see clause 13.4.3 of [ITU-T G.993.2]). If the attribute value is
not zero, the standard SOS triggering criteria are enabled, and the value
specifies the duration of the window used in the standard SOS triggering
criteria in the upstream direction. The special value zero indicates that the
standard SOS triggering criteria are disabled, i.e., vendor-discretionary values
may be used instead of the values configured in the MIB for the following
parameters: SOS-NTONES-us, SOS-CRC-us, SOS-TIME-us. The valid
range of non-zero values is from 1..255, specifying 64 to 16320 ms in steps
of 64 ms. (R, W, Set-by-create) (optional) (1 byte)
SOS degraded tones threshold downstream: The SOS-NTONES-ds attribute is the
minimum percentage of tones in the downstream medley set that must be
degraded in order to arm the first sub-condition of the standard SOS
triggering criteria in the downstream direction. The valid range of values is
from 1 to 100% in steps of 1. Use of the special value 0 is described in clause
13.4.3.2 of [ITU-T G.993.2]. (R, W, Set-by-create) (optional) (1 byte)
SOS degraded tones threshold upstream: The SOS-NTONES-us attribute is the minimum
percentage of tones in the upstream medley set that must be degraded in
order to arm the first sub-condition of the standard SOS triggering criteria in
the upstream direction. The valid range of values is from 1 to 100% in steps
of 1. Use of the special value 0 is described in clause 13.4.3.2 of
[ITU-T G.993.2]. (R, W, Set-by-create) (optional) (1 byte)
SOS CRC threshold downstream: The SOS-CRC-ds attribute is the minimum number of
normalized CRC anomalies received in SOS-TIME-ds seconds in order to
arm the second sub-condition of the standard SOS triggering criteria (see
clause 13.4.3.2 of [ITU T G.993.2]) in the downstream direction. The valid
range of SOS-CRC values is 0.02 to (216-1)*0.02, in steps of 0.02. The
value 0 specifies that the ONU use its internal default. (R, W, Set-by-create)
266
Rec. ITU-T G.988 (10/2012)
SOS CRC threshold upstream: The SOS-CRC-us attribute is the minimum number of
normalized CRC anomalies received in SOS-TIME-us seconds in order to
arm the second sub-condition of the standard SOS triggering criteria (see
clause 13.4.3.2 of [ITU T G.993.2]) in the upstream direction. The valid
range of SOS-CRC values is 0.02 to (216-1)*0.02, in steps of 0.02. The
MAX SOS downstream: The MAX-SOS-ds attribute is used in deactivation. If the number
of successful SOS procedures in the downstream direction performed within
a 120-second interval exceeds MAX-SOS-ds, the modem goes to state L3.
See clause 12.1.4 of [ITU-T G.993.2] for details. The valid range of values is
1 to 15, with the special value 0 as described in clause 12.1 of [ITU-T
G.993.2]. (R, W, Set-by-create) (optional) (1 byte)
MAX SOS upstream: The MAX-SOS-us attribute is used in deactivation. If the number of
successful SOS procedures in the upstream direction performed within a
120-second interval exceeds MAX-SOS-us, the modem goes to state L3. See
clause 12.1.4 of [ITU-T G.993.2] for details. The valid range of values is 1 to
15, with the special value 0 as described in clause 12.1 of [ITU-T G.993.2].
SNR max offset downstream: The SNRMOFFSET-ROC-ds attribute is the SNR margin
offset for the robust operations channel (ROC) in the downstream direction.
The attribute is used in the specification of the channel initialization policy
(see clause 12.3.7.1 of [ITU-T G.993.2]). The valid range of SNR margin
offset values is from 0..31 dB in 0.1 dB steps. (R, W, Set-by-create)
SNR max offset upstream: The SNRMOFFSET-ROC-us attribute is the SNR margin offset
for the robust operations channel (ROC) in the upstream direction. The
attribute is used in the specification of the channel initialization policy (see
clause 12.3.7.1 of [ITU-T G.993.2]). The valid range of SNR margin offset
values is from 0..31 dB in 0.1 dB steps. (R, W, Set-by-create) (optional)
(2 bytes)
ROC minimum impulse noise protection downstream: The INPMIN-ROC-ds attribute
specifies the minimum impulse noise protection to apply on the robust
operations channel (ROC) in the downstream direction. The minimum
impulse noise protection is an integer ranging from 0 to 16. (R, W,
ROC minimum impulse noise protection upstream: The INPMIN-ROC-us attribute
specifies the minimum impulse noise protection to apply on the robust
operations channel (ROC) in the upstream direction. The minimum impulse
noise protection is an integer ranging from 0 to 16. (R, W, Set-by-create)
(optional) (1 byte)
FEXT downstream transmitter referred virtual noise table: The FEXT TXREFVNds
attribute is the downstream transmitter referred virtual noise specified for
FEXTR duration in Annex C of [ITU-T G.992.3] (ADSL2) and Annex C of
[ITU-T G.992.5] (ADSL2plus). The syntax of this attribute is the same as
that of the TXREFVNds table attribute of the VDSL2 line configuration
extensions managed entity. (R, W) (mandatory for Annex C of
[ITU-T G.992.3]and Annex C of [ITU-T G.992.5]) (3 * N bytes, where N is
the number of breakpoints)
Rec. ITU-T G.988 (10/2012)
267
NEXT downstream transmitter referred virtual noise table: The NEXT TXREFVNds
attribute is the downstream transmitter referred virtual noise specified for
NEXTR duration in Annex C of [ITU-T G.992.3] (ADSL2) and Annex C of
[ITU-T G.992.5] (ADSL2plus). The syntax of this attribute is the same as
that of the TXREFVNds table attribute of the VDSL2 line configuration
extensions managed entity. (R, W) (mandatory for Annex C of
[ITU-T G.992.3]and Annex C of [ITU-T G.992.5]) (3 * N bytes, where N is
the number of breakpoints)
Actions
Notifications
None.
9.7.27 xDSL impulse noise monitor performance monitoring history data
This managed entity collects performance monitoring data from the impulse noise monitor function
at both near and far ends. Instances of this managed entity are created and deleted by the OLT. Note
that, unlike most xDSL PM, [ITU-T G.997.1] only requires current and previous 15-minute interval
storage; a longer view of this PM is not expected at 15-minute granularity.
Relationships
An instance of this managed entity may be associated with an xDSL UNI. This managed
entity is meaningful only for [ITU-T G.993.2] VDSL2, [ITU-T G.992.3] and
[ITU-T G.992.5].
Attributes
The managed entity ID is identical to that of this ME's parent physical path
INM INPEQ histogram table: INMINPEQ1..17-L is a count of the near-end
INMAINPEQi anomalies occurring on the line during the accumulation
period. This parameter is subject to inhibiting see clause 7.2.7.13 of
[ITU-T G.997.1]. (R) (optional) (2 bytes * 17 entries = 34 bytes)
INM total measurement: INMME-L is a count of the near-end INMAME anomalies
occurring on the line during the accumulation period. This parameter is
subject to inhibiting see clause 7.2.7.13 of [ITU-T G.997.1]. (R) (optional)
(2 bytes)
INM IAT histogram: INMIAT0..7-L is a count of the near-end INMAIATi anomalies
(2 bytes * 8 entries = 16 bytes)
268
Rec. ITU-T G.988 (10/2012)
INM INPEQ histogram LFE table: INMINPEQ1..17-LFE is a count of the far-end

INMAINPEQi anomalies occurring on the line during the accumulation
period. This parameter is subject to inhibiting see clause 7.2.7.13 of
[ITU-T G.997.1]. (R) (optional) (2 bytes * 17 entries = 34 bytes)
INM total measurement LFE: INMME-LFE is a count of the far-end INMAME anomalies
(2 bytes)
INM IAT histogram LFE: INMIAT0..7-LFE is a count of the far-end INMAIATi
anomalies occurring on the line during the accumulation period. This
parameter is subject to inhibiting see clause 7.2.7.13 of [ITU-T G.997.1].
(R) (optional) (2 bytes * 8 entries = 16 bytes)
Actions
Notifications
None.
This managed entity extends the attributes defined in the xDSL line inventory and status data parts
1..4. This ME reports FEXT and NEXT attributes, and pertains to Annex C of [ITU-T G.992.3]
(ADSL2) and Annex C of [ITU-T G.992.5] (ADSL2plus).
Relationships
Attributes
FEXT downstream signal-to-noise ratio margin: The FEXT SNRMds attribute is the
downstream signal-to-noise ratio margin measured during FEXTR duration at
the ATU-R. The attribute value ranges from 0 (64.0 dB) to 1270 (+63.0 dB).
NEXT downstream signal-to-noise ratio margin: The NEXT SNRMds attribute is the
downstream signal-to-noise ratio margin measured during NEXTR duration at
the ATU-R. The attribute value ranges from 0 (64.0 dB) to 1270 (+63.0 dB).
FEXT upstream signal-to-noise ratio margin: The FEXT SNRMus attribute is the
upstream signal-to-noise ratio margin (see clause 7.5.1.16 of [ITU-T
G.997.1]) measured during FEXTC duration at the ATU-C. The attribute
value ranges from 0 (64.0 dB) to 1270 (+63.0 dB). The special value
0xFFFF indicates that the attribute is out of range. (R) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
269
NEXT upstream signal-to-noise ratio margin: The NEXT SNRMus attribute is the
upstream signal-to-noise ratio margin (see clause 7.5.1.16 of
[ITU-T G.997.1]) measured during NEXTC duration at the ATU-C. The
attribute value ranges from 0 (64.0 dB) to 1270 (+63.0 dB). The special
value 0xFFFF indicates that the attribute is out of range. (R) (mandatory)
(2 bytes)
FEXT downstream maximum attainable data rate: The FEXT ATTNDRds attribute is
the maximum downstream net data rate calculated from FEXT downstream
SNR (f) (see clause 7.5.1.28.3.1 of [ITU-T G.997.1]). The rate is coded in
NEXT downstream maximum attainable data rate: The NEXT ATTNDRds attribute is
the maximum downstream net data rate calculated from NEXT downstream
SNR (f) (see clause 7.5.1.28.3.2 of [ITU-T G.997.1]). The rate is coded in
FEXT upstream maximum attainable data rate: The FEXT ATTNDRus attribute is the
maximum upstream net data rate calculated from FEXT upstream SNR (f)
(see clause 7.5.1.28.6.1 of [ITU-T G.997.1]). The rate is coded in bit/s. (R)
NEXT upstream maximum attainable data rate: The NEXT ATTNDRus attribute is the
maximum upstream net data rate calculated from NEXT upstream SNR (f)
(see clause 7.5.1.28.6.2 of [ITU-T G.997.1]). The rate is coded in bit/s. (R)
FEXT downstream actual power spectral density: The FEXT ACTPSDds attribute is the
average downstream transmit PSD over the used subcarriers (see
clause 7.5.1.21.1 of [ITU-T G.997.1]) calculated from the REFPSDds and
RMSGIds for FEXTR duration. The attribute value ranges from 0
(90.0 dBm/Hz) to 900 (0.0 dBm/Hz). The special value 0xFFFF indicates
that the parameter is out of range. (R) (mandatory) (2 bytes)
NEXT downstream actual power spectral density: The NEXT ACTPSDds attribute is the
average downstream transmit PSD over the used subcarriers (see
clause 7.5.1.21.2 of [ITU-T G.997.1]) calculated from the REFPSDds and
RMSGIds for NEXTR duration. The attribute value ranges from 0
FEXT upstream actual power spectral density: The FEXT ACTPSDus attribute is the
average upstream transmit PSD over the used subcarriers (see
clause 7.5.1.22.1 of [ITU-T G.997.1]) calculated from the REFPSDus and
RMSGIus for FEXTC duration. The attribute value ranges from 0
NEXT upstream actual power spectral density: The NEXT ACTPSDus attribute is the
average upstream transmit PSD over the used subcarriers (see
clause 7.5.1.22.2 of [ITU-T G.997.1]) calculated from the REFPSDus and
RMSGIus for NEXTC duration. The attribute value ranges from 0
270
Rec. ITU-T G.988 (10/2012)
FEXT downstream actual aggregate transmit power: The FEXT ACTATPds attribute is
the total amount of transmit power (see clause 7.5.1.24.1 of [ITU-T G.997.1])
calculated from PSDds measured during FEXTR duration at the ATU-R. The
attribute value ranges from 0 (31.0 dBm) to 620 (+31.0 dBm). The special
value 0xFFFF indicates that the parameter is out of range. (R) (mandatory)
(2 bytes)
NEXT downstream actual aggregate transmit power: The NEXT ACTATPds attribute is
the total amount of transmit power (see clause 7.5.1.24.2 of [ITU-T G.997.1])
calculated from PSDds measured during NEXTR duration at the ATU-R. The
attribute value ranges from 0 (31.0 dBm) to 620 (+31.0 dBm). The special
value 0xFFFF indicates that the parameter is out of range. (R) (mandatory)
(2 bytes)
FEXT upstream actual aggregate transmit power: The FEXT ACTATPus attribute is the
total transmit power (see clause 7.5.1.25.1 of [ITU-T G.997.1]) calculated
from PSDus measured during FEXTC duration at the ATU-C. The attribute
value ranges from 0 (31.0 dBm) to 620 (+31.0 dBm). The special value
0xFFFF indicates that the parameter is out of range. (R) (mandatory)
(2 bytes)
NEXT upstream actual aggregate transmit power: The NEXT ACTATPus attribute is
the total transmit power (see clause 7.5.1.25.2 of [ITU-T G.997.1]) calculated
from PSDus measured during NEXTC duration at the ATU-C. The attribute
value ranges from 0 (31.0 dBm) to 620 (+31.0 dBm). The special value
0xFFFF indicates that the parameter is out of range. (R) (mandatory)
(2 bytes)
Actions
Get, get next
Notifications
None.
parts 1..4. This ME reports FEXT and NEXT attributes, and pertains to Annex C of
[ITU-T G.992.3] (ADSL2) and Annex C of [ITU-T G.992.5] (ADSL2plus).
Relationships
Attributes
FEXT downstream quiet line noise PSD measurement time: The FEXT QLNMTds
attribute is the number of symbols used to measure FEXT downstream QLN
(f) (see clause 7.5.1.27.3.1 of [ITU-T G.997.1]). (R) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
271
NEXT downstream quiet line noise PSD measurement time: The NEXT QLNMTds
attribute is the number of symbols used to measure NEXT downstream QLN
(f) (see clause 7.5.1.27.3.2 of [ITU-T G.997.1]). (R) (mandatory) (2 bytes)
FEXT downstream QLN (f) table: The FEXT QLNpsds attribute is the downstream QLN
(f) (see clause 7.5.1.27.3.1 of [ITU-T G.997.1]) measured during FEXTR
duration at the ATU-R. The attribute syntax is the same as that of the
downstream QLNpsds table attribute of the xDSL line inventory and status
data part 3 managed entity. (R) (mandatory) (N bytes, where N is the number
of subcarrier groups)
NEXT downstream QLN (f) table: The NEXT QLNpsds attribute is the downstream QLN
(f) (see clause 7.5.1.27.3.2 of [ITU-T G.997.1]) measured during NEXTR
duration at the ATU-R. The attribute syntax is the same as that of the
FEXT upstream quiet line noise PSD measurement time: The FEXT QLNMTus attribute
is the number of symbols used to measure FEXT upstream QLN (f) (see
clause 7.5.1.27.6.1 of [ITU-T G.997.1]). (R) (mandatory) (2 bytes)
NEXT upstream quiet line noise PSD measurement time: The NEXT QLNMTus
attribute is the number of symbols used to measure NEXT upstream QLN (f)
(see clause 7.5.1.27.6.2 of [ITU-T G.997.1]). (R) (mandatory) (2 bytes)
FEXT upstream QLN (f) table: The FEXT QLNpsus attribute is the upstream QLN (f)
(see clause 7.5.1.27.6.1 of [ITU-T G.997.1]) measured during FEXTC
duration at the ATU-C. The attribute syntax is the same as that of the
NEXT upstream QLN (f) table: The NEXT QLNpsus attribute is the upstream QLN (f)
(see clause 7.5.1.27.6.2 of [ITU-T G.997.1]) measured during NEXTC
duration at the ATU-C. The attribute syntax is the same as that of the
FEXT downstream SNR measurement time: The FEXT SNRMTds attribute is the
number of symbols used to measure FEXT downstream SNR (f) values (see
clause 7.5.1.28.1.1 of [ITU-T G.997.1]). Its value corresponds to the value
specified in the corresponding Recommendation (e.g., the number of symbols
in a one-second interval for [ITU-T G.992.3]). (R) (mandatory) (2 bytes)
NEXT downstream SNR measurement time: The NEXT SNRMTds attribute is the
number of symbols used to measure NEXT downstream SNR (f) values (see
FEXT downstream SNR (f) table: The FEXT SNRpsds attribute is the downstream SNR
(f) (see clause 7.5.1.28.3.1 of [ITU-T G.997.1]) measured during FEXTR
duration at the ATU-R. The attribute is represented in the same way as the
SNRpsds table attribute of the xDSL line inventory and status data part 3
272
Rec. ITU-T G.988 (10/2012)
managed entity. (R) (mandatory) (N bytes, where N is the number of

subcarrier groups)
NEXT downstream SNR (f) table: The NEXT SNRpsds attribute is the downstream SNR
(f) (see clause 7.5.1.28.3.2 of [ITU-T G.997.1]) measured during NEXTR
duration at the ATU-R. The attribute is represented in the same way as the
SNRpsds table attribute of the xDSL line inventory and status data part 3
managed entity. (R) (mandatory) (N bytes, where N is the number of
subcarrier groups)
FEXT upstream SNR measurement time: The FEXT SNRMTus attribute is the number of
symbols used to measure FEXT upstream SNR (f) values (see
NEXT upstream SNR measurement time: The NEXT SNRMTus attribute is the number
of symbols used to measure NEXT upstream SNR (f) values (see
FEXT upstream SNR (f) table: The FEXT SNRpsus attribute is the upstream SNR (f) (see
clause 7.5.1.28.6.1 of [ITU-T G.997.1]) measured during FEXTC duration at
the ATU-C. The attribute is represented in the same way as the SNRpsds
table attribute of the xDSL line inventory and status data part 3 managed
entity. (R) (mandatory) (N bytes, where N is the number of subcarrier
groups)
NEXT upstream SNR (f) table: The NEXT SNRpsus attribute is the upstream SNR (f) (see
clause 7.5.1.28.6.2 of [ITU-T G.997.1]) measured during NEXTC duration at
the ATU-C. The attribute is represented in the same way as the SNRpsds
table attribute of the xDSL line inventory and status data part 3 managed
entity. (R) (mandatory) (N bytes, where N is the number of subcarrier
groups)
Actions
Get, get next
Notifications
None.
parts 1..4. This ME reports FEXT and NEXT attributes, and pertains to Annex C of
[ITU-T G.992.3] (ADSL2) and Annex C of [ITU-T G.992.5] (ADSL2plus).
Relationships
Attributes
Rec. ITU-T G.988 (10/2012)
273
FEXT downstream bits allocation table: The FEXT BITSpsds attribute is the downstream
bits allocation table per subcarrier (see clause 7.5.1.29.1.1 of
[ITU-T G.997.1]) used during FEXTR duration. The syntax of this attribute is
the same as that of the BITSpsds table attribute of the xDSL line inventory
and status data part 3 managed entity. (R) (mandatory) (N bytes, where N is
the number of subcarriers)
NEXT downstream bits allocation table: The NEXT BITSpsds attribute is the
downstream bits allocation table per subcarrier (see clause 7.5.1.29.1.2 of
[ITU-T G.997.1]) used during NEXTR duration. The syntax of this attribute is
the same as that of the BITSpsds table attribute of the xDSL line inventory
and status data part 3 managed entity. (R) (mandatory) (N bytes, where N is
FEXT upstream bits allocation table: The FEXT BITSpsus attribute is the upstream bits
allocation table per subcarrier (see clause 7.5.1.29.2.1 of [ITU-T G.997.1])
used during FEXTC duration. The syntax of this attribute is the same as that
of the BITSpsds table attribute of the xDSL line inventory and status data
part 3 managed entity. (R) (mandatory) (N bytes, where N is the number of
subcarriers)
NEXT upstream bits allocation table: The NEXT BITSpsus attribute is the upstream bits
allocation table per subcarrier (see clause 7.5.1.29.2.2 of [ITU-T G.997.1])
used during NEXTC duration. The syntax of this attribute is the same as that
of the BITSpsds table attribute of the xDSL line inventory and status data
part 3 managed entity. (R) (mandatory) (N bytes, where N is the number of
subcarriers)
FEXT downstream gains allocation table: The FEXT GAINSpsds attribute is the
downstream gains allocation table per subcarrier (see clause 7.5.1.29.3.1 of
[ITU-T G.997.1]) used during FEXTR duration. The syntax of this attribute is
the same as that of the GAINSpsds table attribute of the xDSL line inventory
and status data part 3 managed entity. (R) (mandatory) (2N bytes, where N is
NEXT downstream gains allocation table: The NEXT GAINSpsds attribute is the
downstream gains allocation table per subcarrier (see clause 7.5.1.29.3.2 of
[ITU-T G.997.1]) used during NEXTR duration. The syntax of this attribute is
FEXT upstream gains allocation table: The FEXT GAINSpsus attribute is the upstream
gains allocation table per subcarrier (see clause 7.5.1.29.4.1 of
[ITU-T G.997.1]) used during FEXTC duration. The syntax of this attribute is
NEXT upstream gains allocation table: The NEXT GAINSpsus attribute is the upstream
gains allocation table per subcarrier (see clause 7.5.1.29.4.2 of
[ITU-T G.997.1]) used during NEXTC duration. The syntax of this attribute is
274
Rec. ITU-T G.988 (10/2012)
FEXT downstream transmit spectrum shaping table: The FEXT TSSpsds attribute is the
downstream transmit spectrum shaping parameter set per subcarrier (see
clause 7.5.1.29.5.1 of [ITU-T G.997.1]) used during FEXTR duration. The
syntax of this attribute is the same as that of the TSSpsds table attribute of the
xDSL line inventory and status data part 3 managed entity. (R) (mandatory)
(3N bytes, where N is the number of breakpoints)
NEXT downstream transmit spectrum shaping table: The NEXT TSSpsds attribute is the
downstream transmit spectrum shaping parameter set per subcarrier (see
clause 7.5.1.29.5.2 of [ITU-T G.997.1]) used during NEXTR duration. The
syntax of this attribute is the same as that of the TSSpsds table attribute of the
FEXT upstream transmit spectrum shaping table: The FEXT TSSpsus attribute is the
upstream transmit spectrum shaping parameter set per subcarrier (see
clause 7.5.1.29.6.1 of [ITU-T G.997.1]) used during FEXTC duration. The
syntax of this attribute is the same as that of the TSSpsus table attribute of the
NEXT upstream transmit spectrum shaping table: The NEXT TSSpsus attribute is the
upstream transmit spectrum shaping parameter set per subcarrier (see clause
7.5.1.29.6.2 of [ITU-T G.997.1]) used during NEXTC duration. The syntax of
this attribute is the same as that of the TSSpsus table attribute of the xDSL
line inventory and status data part 4 managed entity. (R) (mandatory)
Actions
Get, get next
Notifications
None.
9.8
TDM services
This clause defines managed entities associated with CES UNIs, as shown in Figure 9.8-1.
Rec. ITU-T G.988 (10/2012)
275
N 9.8.3: CES service

profile
Pointed to by:
GEM interworking TP
9.8.1: PPTP CES

UNI
Pointed to by:
GEM interworking TP
Pointed to by:
GEM interworking TP
9.8.4: CES physical

interface PM history
data
9.8.12: part 2
9.8.13: part 3
9.8.2: Logical N 64
sub-port CTP
Points to:
TCP/UDP config data
Large string (FE TP URI)
Pointed to by:
(Extended) VLAN tagging operation
config data
Points to:
TCP/UDP config data
PPTP ATM UNI
9.8.6: RTP
pseudowire
parameters
9.8.8: Pseudowire
PM history data
9.8.5: Pseudowire
termination
point
9.8.9: Ethernet flow

TP
Points to:
GEM interworking
TP
9.8.15: PW ATM
config data
9.8.16: PW ATM
PM history data
9.8.7: Pseudowire
maintenance
profile
9.8.14: MPLS
PW TP
9.8.17: PW Ethernet
config data
Points to:
PPTP UNI
802.1p mapper
VEIP
G.988(12)_F9.8-1
Figure 9.8-1 Managed entities associated with TDM services

9.8.1
This managed entity represents the point at a CES UNI in the ONU where the physical path
terminates and physical level functions are performed.
when the ONU has CES ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of a CES type;
when a cardholder provisioned for plug-and-play is equipped with a circuit pack of a CES
type. Note that the installation of a plug-and-play card may indicate the presence of CES
ports via equipment ID as well as its type, and indeed may cause the ONU to instantiate a
port mapping package that specifies CES ports.
provisioned to expect a CES circuit pack, nor is it equipped with a CES circuit pack.
Relationships
An instance of this managed entity is associated with each real or pre-provisioned CES port.
It can be linked from a GEM interworking termination point, a pseudowire termination point
or a logical N 64 kbit/s CTP.
276
Rec. ITU-T G.988 (10/2012)
Attributes
Expected type: The following coding is used for this attribute:
0
Autosense
1 to 254 One of the values from Table 9.1.5-1 that is compatible with a
CES circuit pack
(1 byte)
Sensed type: If the value of expected type is not 0, then the value of sensed type equals the
value of expected type. If expected type = 0, then the value of sensed type is
one of the compatible values from Table 9.1.5-1. Upon ME instantiation, the
ONU sets this attribute to 0 or to the value that reflects the physically present
equipment. (R) (mandatory if the ONU supports circuit packs with
configurable interface types, e.g., C1.5/2/6.3) (1 byte)
CES loopback configuration: This attribute specifies and reports the loopback
configuration of the physical interface.
0 No loopback
1 Payload loopback
2 Line loopback
3 OS-directed loopback 1 (loopback from/to PON side)
4 OS-directed loopback 2 (loopback from/to CES UNI side)
5 OS-directed loopback 3 (loopback of both PON side and CES UNI
side)
6 Manual button-directed loopback (read only)
7 Network-side code inband-directed loopback (read only)
8 SmartJack-directed loopback (read only)
9 Network-side code inband-directed loopback (armed; read only).
(1 byte)
ONU
CES UNI
PHY
framer
PON
PON
interface
Loopback 2 Loopback 1
Loopback 3
G.988(12)_F9.8.1-1
Figure 9.8.1-1 CES loopback configuration

(optional) (1 byte)
Rec. ITU-T G.988 (10/2012)
277
Framing: This attribute specifies the framing structure.

These code points are for use with DS1 services. Code point 2 may also be
used for an unframed E1 service.
0 Extended superframe
1 Superframe
2 Unframed
3 ITU-T G.704
NOTE [ITU-T G.704] describes both SF and ESF framing for DS1
signals. This code point is retained for backward compatibility, but its
meaning is undefined.
JT-G.704
The following code points are for use with E1 services.

5 Basic framing: clause 2.3.2 of [ITU-T G.704]
6 Basic framing with CRC-4: clause 2.3.3 of [ITU-T G.704]
7 Basic framing with TS16 multiframe
8 Basic framing with CRC-4 and TS16 multiframe
Upon ME instantiation, the ONU sets this attribute to a value that reflects the
vendor's default. (R, W) (optional) (1 byte)
Encoding:
This attribute specifies the line coding scheme. Valid values are:
0 B8ZS
1 AMI
2 HDB3
3 B3ZS
Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (mandatory
for DS1 and DS3 interfaces) (1 byte)
Line length: This attribute specifies the length of the twisted pair cable from a DS1
physical UNI to the DSX-1 cross-connect point or the length of coaxial cable
from a DS3 physical UNI to the DSX-3 cross-connect point. Valid values are
given in Table 9.8.1-1. Upon ME instantiation for a DS1 interface, the ONU
assigns the value 0 for non-power feed type DS1 and the value 6 for power
feed type DS1. Upon ME instantiation for a DS3 interface, the ONU sets this
attribute to 0x0F. (R, W) (optional) (1 byte)
DS1 mode:
This attribute specifies the mode of a DS1. Valid values are as shown:
Value
Mode
Connect
Line length
Power
Loopback
#1
DS1 CPE
Short haul
No power feed
Smart jack
#2
DS1 CPE
Long haul
No power feed
Smart jack
#3
DS1 NIU CPE
Long haul
No power feed
Intelligent office repeater.

Transparent to FDL.
#4
DS1 NIU CPE
Long haul
With power feed
Intelligent office repeater.

Transparent to FDL.
In the event of conflicting values between this attribute and the (also
optional) line length attribute, the line length attribute is taken to be valid.
This permits the separation of LBO and power settings from smart jack and
FDL behaviour. Upon ME instantiation, the ONU sets this attribute to 0.
ARC:
278
Rec. ITU-T G.988 (10/2012)

This attribute specifies the line type used in a DS3 or E3 application, or when
the sensed type of the PPTP is configurable. Valid values are:
0 Other
1 ds3 m23
2 ds3 syntran
3 ds3 Cbit parity
4 ds3 clear channel
5 e3 framed
6 e3 plcp
7 DS1
8 E1
9 J1
Line type:
(R, W) (mandatory for DS3, E3 and multi-configuration interfaces, not

applicable to other interfaces) (1 byte)
Actions
Get, set
Notifications
Number
Description
N/A
Sensed type
Sensed circuit pack type (value from Table 9.1.5-1)
CES loopback config
Loopback configuration of physical interface
N/A
Op state
6..9
N/A
10
ARC
11..12
N/A
13..16
Reserved
Operational state
Alarms should be declared and cleared according to criteria defined separately in existing
TDM standards.
Alarm
Alarm
number
Alarm
Description
TF
Transmitter failure
LOS
Loss of signal
LOF
Loss of frame
OOF
Out of frame
RAI
Remote alarm indication
1.5 M BAIS
1.544 Mbit/s back alarm indication signal
R-INH
Receive alarm inhibit
6M REC
6.312 Mbit/s receive alarm
6M SEND
6.312 Mbit/s send alarm

Rec. ITU-T G.988 (10/2012)
279
Alarm
Alarm
number
Alarm
Description
6M ERR
6.312 Mbit/s block error
10
6M BERR
6.312 Mbit/s back error
11
34M REC
12
34M AIS
34.368 Mbit/s alarm indication signal
13
2M REC
14
2M AIS
15
1.5M REC
16
1.5 AIS
17
INFO0
INFO0 reception (INFO0)
18
45M RDI
44.736 Mbit/s remote defect indication
19
45M AIS
20
AIS-CI
Refer to [b-ATIS-0300231]
21
DS1 idle
22
RAI-CI
23..207
Reserved
208..223
Table 9.8.1-1 Values for the line length attribute

Value
280
Power feed
Line length
0x00
Non-power feed type DS1
0x01
33.5..67.1 m (110..220 ft)
0x02
67.1..100.6 m (220..330 ft)
0x03
100.6..134.1 m (330..440 ft)
0x04
0x05
0x06
Power feed type DS1 (Wet T1), short haul
0x07
40.5..81.1 m (133..266 ft)
0x08
81.1..121.6 m (266..399 ft)
0x09
121.6..162.5 m (399..533 ft)
0x0A
162.5..199.6 m (533..655 ft)
0x0B
Power feed type DS1 (Wet T1), long haul
0 dB
0x0C
7.5 dB
0x0D
15 dB
0x0E
22.5 dB
0x0F
DS3 power feed
0x10
DS3 power feed
Rec. ITU-T G.988 (10/2012)
0..33.5 m (0..110 ft)
134.1..167.6 m (440..550 ft)

167.6..201.2 m (550..660 ft)
0..40.5 m (0..133 ft)
0..68.6 m (0..225 ft)

68.6..137.2 m (225..450 ft)
9.8.2
Logical N 64 kbit/s sub-port connection termination point
This managed entity models a logical sub-port contained within a higher level TDM physical layer
interface (e.g., a group of DS0s within a DS1, a DS1 within a DS3, etc.). An 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) as an integral bundle.
Relationships
Zero or more instances of this ME are associated with an instance of the physical path
termination point CES UNI. It can be linked from a pseudowire TP.
Attributes
Physical path termination pointer: This attribute points to the corresponding physical path
termination point CES UNI managed entity instance. (R, W, Set-by-create)
List of time slots: This attribute is a bit map that indicates time slots or component
tributaries. Each bit indicates whether the corresponding time slot is included
in the connection (1) or not (0). Figure 9.8.2-1 shows the correspondence.
Bit
Byte 8 (MSB)
TS 3
TS 4
TS 5
TS 6
TS 7
TS 0
TS 1
TS 2
TS 8
TS 9
TS 10 TS 11 TS 12 TS 13 TS 14 TS 15
TS 88
TS 89 TS 90 TS 91 TS 92 TS 93 TS 94 TS 95
...
12
Figure 9.8.2-1 Mapping of time slots

Actions
Notifications
None.
9.8.3
CES service profile
NOTE In [ITU-T G.984.4], this managed entity is called a CES service profile-G.
An instance of this managed entity organizes data that describe the CES service functions of the
ONU. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity may be associated with zero or more instances of a GEM
interworking termination point.
Attributes
Rec. ITU-T G.988 (10/2012)
281
CES buffered CDV tolerance: This attribute represents the duration of user data that must
be buffered by the CES interworking entity to offset packet delay variation. It
is expressed in 10-microsecond increments. 75 (750 s) is suggested as a
default value. (R, W, Set-by-create) (mandatory) (2 bytes)
Channel associated signalling: This attribute selects the signalling format. It applies to
structured interfaces only. For unstructured interfaces, this value, if present,
must be set to the default 0. Valid values are:
0 Basic
1 E1 CAS
2 SF CAS
3 DS1 ESF CAS
4 J2 CAS
Actions
Notifications
None.
9.8.4
CES physical interface performance monitoring history data
This managed entity collects statistics for a CES physical interface. Interfaces include DS1, E1, J1,
J2 and possibly others. The performance management requirements of particular interfaces are
described in the corresponding ITU-T or other standards document, for example [ITU-T G.784] or
[b-ATIS-0300231].
Relationships
An instance of this managed entity is associated with one instance of the physical path
termination point CES UNI.
Attributes
instance of the physical path termination point CES UNI. (R, Set-by-create)
entity that contains PM threshold values. Since no mandatory threshold value
attribute number exceeds 7, a threshold data 2 ME is optional. (R, W,
Errored seconds: When a detailed distinction needs to be made, this attribute corresponds
to near-end line errored seconds, ES-L, also known as LES. (R) (mandatory)
(2 bytes)
Severely errored seconds: When a detailed distinction needs to be made, this attribute
corresponds to near-end line severely errored seconds, SES-L. (R)
282
Rec. ITU-T G.988 (10/2012)
Burst errored seconds: A burst errored second (BES) is any second that is not a UAS, that
contains between 2 and 319 error events but no LOS, AIS or OOF condition.
This attribute is also known as ESB-P. (R) (optional) (2 bytes)
Unavailable seconds: When a detailed distinction needs to be made, this attribute
corresponds to near-end path unavailable seconds, UAS-P. (R) (mandatory)
(2 bytes)
Controlled slip seconds: When a detailed distinction needs to be made, this attribute
corresponds to near-end path controlled slip seconds CSS-P. (R) (mandatory)
(2 bytes)
Each of the following attributes is (R) (optional) (2 bytes)
Attribute name
Common acronym
LOSS-L
AIS seconds
AISS-P
Errored seconds, path
ES-P
Errored seconds, type A
ESA-P
Severely errored seconds, path
SES-P
Severely errored frame and AIS seconds
SAS-P aka SEFS
Code violations, line
CV-L aka LCV
Code violations, path
CV-P aka PCV
Errored blocks (see [ITU-T G.826])
EB
Actions
Notifications
Alarm
number
ES
SES
BES
UAS
CSS
LOSS-L
AISS-P
ES-P
ESA-P
SES-P
10
10
SAS-P
11
11
CV-L
12
12
CV-P
13
Rec. ITU-T G.988 (10/2012)
283
13
EB
14
9.8.5
The pseudowire termination point supports packetized (rather than TDM) transport of TDM
services, transported either directly over Ethernet, over UDP/IP or over MPLS. Instances of this
Relationships
One pseudowire termination point ME exists for each distinct TDM service that is mapped
to a pseudowire.
Attributes
Underlying transport:
0 Ethernet, MEF 8
1 UDP/IP
2 MPLS
Service type: This attribute specifies the basic service type, either a transparent bit pipe or
an encapsulation that recognizes the underlying structure of the payload.
0 Basic unstructured (also known as structure agnostic)
1 Octet-aligned unstructured, structure agnostic. Applicable only to
DS1, a mode in which each frame of 193 bits is encapsulated in 25
bytes with 7 padding bits.
2 Structured (structure-locked)
Signalling:
0 No signalling visible at this layer

1 CAS, to be carried in the same packet stream as the payload
2 CAS, to be carried in a separate signalling channel
(R, W, Set-by-create) (mandatory for structured service type) (1 byte)
TDM UNI pointer: If service type = structured, this attribute points to a logical
N 64 kbit/s sub-port connection termination point. Otherwise, this attribute
points to a physical path termination point CES UNI. (R, W, Set-by-create)
North-side pointer: When the pseudowire service is transported via IP, as indicated by the
underlying transport attribute, the north-side pointer attribute points to an
instance of the TCP/UDP config data managed entity. When the pseudowire
service is transported directly over Ethernet, the north-side pointer attribute is
not used the linkage to the Ethernet flow termination point is implicit in the
ME IDs. When the pseudowire service is transported over MPLS, the
north-side pointer attribute points to an instance of the MPLS PW TP. (R, W,
Far-end IP info: When the pseudowire service is transported via IP, this attribute points to a
large string managed entity that contains the URI of the far-end termination
point, for example:
284
Rec. ITU-T G.988 (10/2012)
udp://192.168.100.221:5000 or
udp://pwe3srvr.int.example.net:2222
A null pointer is appropriate if the pseudowire is not transported via IP.
(R, W, Set-by-create) (mandatory for IP transport) (2 bytes)
Payload size: Number of payload bytes per packet. Valid only if service type = basic
unstructured or octet-aligned unstructured. Valid choices depend on the TDM
service, but must include the following. Other choices are at the vendor's
discretion.
DS1 192
DS1 200, required only if an octet-aligned unstructured service is
supported
E1 256
DS3 1024
E3 1024
(R, W, Set-by-create) (mandatory for unstructured service) (2 bytes)
Payload encapsulation delay: Number of 125-microsecond frames to be encapsulated in
each pseudowire packet. Valid only if service type = structured. The
minimum set of choices for various TDM services is listed below, and is
affected by the possible presence of in-band signalling. Other choices are at
the vendor's discretion.
Payload encapsulation delay
Payload type
64 required (8 ms),
40 desired (5 ms)
NxDS0, no signalling, N = 1
32 (4 ms)
NxDS0, no signalling, N = 2..4
8 (1 ms)
NxDS0, no signalling, N > 4
24 (3 ms)
NxDS0 with DS1 CAS
16 (2 ms)
NxDS0 with E1 CAS
(R, W, Set-by-create) (mandatory for structured service) (1 byte)

Timing mode: This attribute selects the timing mode of the TDM service. If RTP is used,
this attribute must be set to be consistent with the value of the RTP time
stamp mode attribute in the RTP pseudowire parameters managed entity, or
its equivalent, at the far end.
0 Network timing (default)
1 Differential timing
2 Adaptive timing
3 Loop timing: local TDM transmit clock derived from local TDM
receive stream
Transmit circuit ID: This attribute is a pair of ECID (emulated circuit ID) values that the
ONU transmits in the direction from the TDM termination towards the
packet-switched network. MEF 8 ECIDs lie in the range 1..1048575 (220 1).
To allow for the possibility of other transport (L2TP) in the future, each
ECID is allocated 4 bytes.
The first value is used for the payload ECID; the second is used for the
optional separate signalling ECID. The first ECID is required for all MEF 8
Rec. ITU-T G.988 (10/2012)
285
pseudowires; the second is required only if signalling is to be carried in a

distinct channel. If signalling is not present, or is carried in the same channel
as the payload, the second ECID should be set to 0.
(R, W) (mandatory for MEF 8 transport) (8 bytes)
Expected circuit ID: This attribute is a pair of ECID (emulated circuit ID) values that the
ONU can expect in the direction from the packet-switched network towards
the TDM termination. Checking ECIDs may be a way to detect circuit
misconnection. MEF 8 ECIDs lie in the range 1..1048575 (220 1). To allow
for the possibility of other transport (L2TP) in the future, each ECID is
allocated 4 bytes.
The first value is used for the payload ECID; the second is used for the
optional separate signalling ECID. In both cases, the default value 0 indicates
that no ECID checking is expected.
(R, W) (optional for MEF 8 transport) (8 bytes)
Received circuit ID: This attribute indicates the actual ECID(s) received on the payload and
signalling channels, respectively. It may be used for diagnostic purposes. (R)
(optional for MEF 8 transport) (8 bytes)
Exception policy: This attribute points to an instance of the pseudowire maintenance profile
managed entity. If the pointer has its default value 0, the ONU's internal
defaults apply. (R, W) (optional) (2 bytes)
ARC:

Actions
Notifications
Number
1..13
N/A
14
ARC
15
N/A
16
Reserved
Description
Alarm criteria may be customized through reference to a pseudowire maintenance profile managed
object, or defined by the ONU's internal defaults.
Alarm
Alarm
number
286
Event
Description
Misconnection
Excessive ratio of stray packets received from the PSN.
Loss of packets
Excessive ratio of lost packets from the PSN.
Buffer overrun
Excessive ratio of packets lost because they arrived from the

PSN too early to be buffered for playout.
Buffer underrun
Excessive ratio of packets lost because they arrived from the

PSN too late to be buffered for playout.
Rec. ITU-T G.988 (10/2012)
4
5..207
208..223
9.8.6
Malformed packets
alarm
Excessive ratio of packets lost because their structure or

payload type did not match the provisioned service.
Reserved
If a pseudowire service uses RTP, the RTP pseudowire parameters managed entity provides
configuration information for the RTP layer. Instances of this managed entity are created and
deleted by the OLT. The use of RTP on a pseudowire is optional, and is determined by the existence
of the RTP pseudowire parameters managed entity.
Relationships
An instance of the RTP pseudowire parameters managed entity may exist for each
pseudowire termination point managed entity, to which it is implicitly bound by a common
managed entity ID.
Attributes
instance of the pseudowire termination point managed entity. (R,
Clock reference: This attribute specifies the frequency of the common timing reference, in
multiples of 8 kHz. (R, W, Set-by-create) (mandatory) (2 bytes)
RTP time stamp mode: This attribute determines the mode in which RTP timestamps are
generated in the TDM to PSN direction.
0 Unknown or not applicable.
1 Absolute. Timestamps are based on the timing of the incoming TDM
signal.
2 Differential. Timestamps are based on the ONU's reference clock,
which is understood to be stratum-traceable along with the reference
clock at the far end.
PTYPE:
This attribute specifies the RTP payload type in the TDM to PSN direction. It
comprises two one-byte values. The first is for the payload channel, the
second, for the optional separate signalling channel. Assignable PTYPEs lie
in the dynamic range 96..127. If signalling is not transported in its own
channel, the second value should be set to 0. (R, W, Set-by-create)
SSRC:
This attribute specifies the RTP synchronization source in the TDM to PSN
direction. It comprises two four-byte values. The first is for the payload
channel, the second, for the optional separate signalling channel. If signalling
is not transported in its own channel, the second value should be set to 0.
Expected PTYPE: This attribute specifies the RTP payload type in the PSN to TDM
direction. The received payload type may be used to detect malformed
packets. It comprises two one-byte values. The first is for the payload
channel, the second, for the optional separate signalling channel. To disable
either or both of the check functions, set the corresponding value to its
default value 0. (R, W, Set-by-create) (optional) (2 bytes)
Rec. ITU-T G.988 (10/2012)
287
Expected SSRC: This attribute specifies the RTP synchronization source in the PSN to
TDM direction. The received SSRC may be used to detect misconnection
(stray packets). It comprises two four-byte values. The first is for the payload
channel, the second, for the optional separate signalling channel. To disable
either or both of the check functions, set the corresponding value to its
default value 0. (R, W, Set-by-create) (optional) (8 bytes)
Actions
Notifications
None.
9.8.7
The pseudowire maintenance profile permits the configuration of pseudowire service exception
handling. It is created and deleted by the OLT.
The settings, and indeed existence, of a pseudowire maintenance profile affect the behaviour of the
pseudowire performance monitoring history data managed entity only in establishing criteria for
counting severely errored seconds, but in no other way. The pseudowire maintenance profile
primarily affects the alarms declared by the subscribing pseudowire termination point.
Relationships
One or more instances of the pseudowire termination point may point to an instance of the
pseudowire maintenance profile. If the pseudowire termination point does not refer to a
pseudowire maintenance profile, the ONU's default exception handling is implied.
Attributes
Jitter buffer maximum depth: This attribute specifies the desired maximum depth of the
playout buffer in the PSN to TDM direction. The value is expressed as a
multiple of the 125 s frame rate. The default value 0 selects the ONU's
internal policy. (R, W, Set-by-create) (optional) (2 bytes)
Jitter buffer desired depth: This attribute specifies the desired nominal fill depth of the
playout buffer in the PSN to TDM direction. The value is expressed as a
multiple of the 125 s frame rate. The default value 0 selects the ONU's
internal policy. (R, W, Set-by-create) (optional) (2 bytes)
Fill policy:
288
This attribute defines the payload bit pattern to be applied towards the TDM
service if no payload packet is available to play out. The default value 0
specifies that the ONU apply its internal policy.
0
ONU default, vendor-specific (recommended:

unstructured service, all 1s for structured service)
Play out AIS according to the service definition (for example,

DS3 AIS)
Play out all 1s
Play out all 0s
Repeat the previous data
Play out DS1 idle (Appendix C of [b-ATIS-0600403])
Rec. ITU-T G.988 (10/2012)
AIS
for
6..15
Reserved for future standardization
16..255
Vendor-specific, not to be standardized

Four pairs of alarm-related policy attributes, defined below, share common behaviour.
The alarm declaration policy attribute defines the anomaly rate that causes the corresponding alarm
to be declared. It is an integer percentage between 1..100. If this density of anomalies occurs during
the alarm onset soak interval, the alarm is declared. The default value 0 selects the ONU's internal
policy.
The alarm clear policy attribute defines the anomaly rate that causes the corresponding alarm to be
cleared. It is an integer percentage between 0..99. If no more than this density of anomalies occurs
during the alarm clear soak interval, the alarm is cleared. The default value 255 selects the ONU's
internal policy.
Misconnected packets declaration policy: (R, W, Set-by-create) (optional) (1 byte)
Misconnected packets clear policy: (R, W, Set-by-create) (optional) (1 byte)
Loss of packets declaration policy: (R, W, Set-by-create) (optional) (1 byte)
Loss of packets clear policy: (R, W, Set-by-create) (optional) (1 byte)
Buffer overrun/underrun declaration policy: (R, W, Set-by-create) (optional) (1 byte)
Buffer overrun/underrun clear policy: (R, W, Set-by-create) (optional) (1 byte)
Malformed packets declaration policy: (R, W, Set-by-create) (optional) (1 byte)
Malformed packets clear policy: (R, W, Set-by-create) (optional) (1 byte)
R-bit transmit set policy: This attribute defines the number of consecutive lost packets that
causes the transmitted R bit to be set in the TDM to PSN direction, indicating
lost packets to the far end. The default value 0 selects the ONU's internal
policy. (R, W, Set-by-create) (optional) (1 byte)
R-bit transmit clear policy: This attribute defines the number of consecutive valid packets
that causes the transmitted R bit to be cleared in the TDM to PSN direction,
removing the remote failure indication to the far end. The default value 0
selects the ONU's internal policy. (R, W, Set-by-create) (optional) (1 byte)
R-bit receive policy: This attribute defines the action towards the N 64 TDM interface
when remote failure is indicated on packets received from the PSN (either
R-bit set or M = 0b10 while the L bit is cleared).
0 Do nothing (recommended to be the default)
1 Play out service-specific RAI/REI/RDI code
2 Send channel idle signalling and idle channel payload to all DS0s
comprising the service
L-bit receive policy: This attribute defines the action towards the TDM interface when
far-end TDM failure is indicated on packets received from the PSN (L bit
set).
0 Play out service-specific AIS (recommended to be the default)
1 Repeat last received packet
2 Send channel idle signalling and idle channel payload to all DS0s
comprising the service
Rec. ITU-T G.988 (10/2012)
289
SES threshold: Number of lost, malformed or otherwise unusable packets expected in the
PSN to TDM direction within a one-second interval that causes a severely
errored second to be counted. Stray packets do not count towards a severely
errored second, nor do packets whose L bit is set at the far end. The value 0
specifies that the ONU use its internal default, which is not necessarily the
same as the recommended default value 3. (R, W, Set-by-create) (optional) (2
bytes)
Actions
Notifications
None.
9.8.8
Pseudowire performance monitoring history data
This managed entity collects PM for a pseudowire termination point. Most of the attributes monitor
packets received from the PSN, and may therefore be considered egress PM. For the most part,
ingress PM is collected at the CES PPTP managed entity.
NOTE The pseudowire performance monitoring history data managed entity collects data similar, but not
identical, to that available from the MAC bridge port PM history data ME associated with a MAC bridge.
When the pseudowire is bridge-based, it may not be necessary to collect both.
Relationships
An instance of this managed entity is associated with an instance of the pseudowire
termination point.
Attributes
instance of the pseudowire termination point. (R, Set-by-create) (mandatory)
(2 bytes)
Received packets: This attribute counts the total number of packets, both payload and
signalling, received in the PSN to TDM direction. (R) (mandatory) (4 bytes)
Transmitted packets: This attribute counts the total number of packets, both payload and
signalling, transmitted in the TDM to PSN direction. The count includes
packets whose L bit is set and which may therefore not contain a payload. (R)
Missing packets: This attribute counts the number of lost packets, as indicated by gaps in
the control word numbering sequence. Both payload and signalling packets,
if any, contribute to this count. (R) (mandatory) (4 bytes)
Misordered packets, usable: This attribute counts the number of packets received out of
order, but which were able to be successfully re-ordered and played out. Both
290
Rec. ITU-T G.988 (10/2012)
payload and signalling packets, if any, contribute to this count. (R)

Misordered packets dropped: This attribute counts the number of packets received out of
sequence that were discarded, either because the ONU did not support
reordering or because it was too late to reorder them. Both payload and
signalling packets, if any, contribute to this count. (R) (mandatory) (4 bytes)
Playout buffer underruns/overruns: This attribute counts the number of packets that were
discarded because they arrived too late or too early to be played out. Both
payload and signalling packets, if any, contribute to this count. (R)
Malformed packets: This attribute counts the number of malformed packets, for example,
because the packet length was not as expected or because of an unexpected
RTP payload type. Both payload and signalling packets, if any, contribute to
this count. (R) (mandatory) (4 bytes)
Stray packets: This attribute counts the number of packets whose ECID or RTP SSRC
failed to match the expected value, or which are otherwise known to have
been misdelivered. Stray packets are discarded without affecting any of the
other PM counters. Both payload and signalling packets, if any, contribute to
this count. (R) (mandatory) (4 bytes)
Remote packet loss: This attribute counts received packets whose R bit is set, indicating the
loss of packets at the far end. Both payload and signalling packets, if any,
contribute to this count. (R) (mandatory) (4 bytes)
TDM L-bit packets transmitted: This attribute counts the number of packets transmitted
with the L bit set, indicating a near-end TDM fault. Both payload and
signalling packets, if any, contribute to this count. (R) (mandatory) (4 bytes)
ES:
This attribute counts errored seconds. Any discarded, lost, malformed or

unusable packet received from the PSN during a given second causes this
counter to increment. Both payload and signalling packets, if any, contribute
to this count. (R) (mandatory) (4 bytes)
SES:
This attribute counts severely errored seconds. The criterion for an SES may
be configured through the pseudowire maintenance profile managed entity.
Both payload and signalling packets, if any, contribute to this count. (R)
UAS:
This attribute counts unavailable seconds. An unavailable second begins at

the onset of ten consecutive SES and ends at the onset of ten consecutive
seconds that are not severely errored. A service is unavailable if either its
payload or its signalling, if any, are unavailable. During unavailable time,
only UAS should be counted; other anomalies should not be counted. (R)
Actions
Rec. ITU-T G.988 (10/2012)
291
Notifications
Alarm
number
Missing packets
Misordered packets, usable
Misordered packets dropped
Playout buffer underruns/overruns
Malformed packets
Stray packets
Remote packet loss
ES
SES
UAS
10
9.8.9
The Ethernet flow termination point contains the attributes necessary to originate and terminate
Ethernet frames in the ONU. It is appropriate when transporting pseudowire services via layer 2.
Relationships
One Ethernet flow termination point ME exists for each distinct pseudowire service that is
transported via layer 2.
Attributes
Through an identical ID, this managed entity is implicitly linked to a
pseudowire termination point managed entity. (R, Set-by-create) (mandatory)
(2 bytes)
Destination MAC: This attribute specifies the destination MAC address of upstream
Ethernet frames. (R, W, Set-by-create) (mandatory) (6 bytes)
Source MAC: This attribute specifies the near-end MAC address. It is established by
non-OMCI means (e.g., factory programmed into ONU flash memory) and is
included here for information only. (R) (mandatory) (6 bytes)
Tag policy:
This attribute specifies the tagging policy to be applied to upstream Ethernet

frames.
0 untagged frame
1 tagged frame
TCI:
292
If the tag policy calls for tagging of upstream Ethernet frames, this attribute
specifies the tag control information, which includes the VLAN tag, P bits
and CFI bit. (R, W) (optional) (2 bytes)
Rec. ITU-T G.988 (10/2012)
Loopback:
This attribute sets the loopback configuration:

0 No loopback
1 Loopback of downstream traffic at MAC client
Actions
Notifications
None.
9.8.10 This clause is intentionally left blank
9.8.12 CES physical interface performance monitoring history data 2
This managed entity collects far-end statistics for a CES physical interface. It is specifically
directed at DS1 interfaces ([b-ATIS-0300231], [b-ATIS-0600403]), but may be useful in other
cases as well.
Relationships
Attributes
managed entities that contain PM threshold values. (R, W, Set-by-create)
Each of the following attributes is (R) (optional) (2 bytes).
Attribute name
Common acronym
Errored seconds, line far-end
ES-LFE
Code violations, path far-end
CV-PFE
Errored seconds, path far-end
ES-PFE
Errored seconds type A, path far-end
ESA-PFE
Errored seconds type B, path far-end
ESB-PFE
Severely errored seconds, path far-end
SES-PFE
Severely errored framing seconds, path far-end
SEFS-PFE
Unavailable seconds, path far-end
UAS-PFE
Rec. ITU-T G.988 (10/2012)
293
Attribute name
Common acronym
Controlled slip seconds, path far-end
CSS-PFE
Failure count, path far-end
FC-PFE
Actions
Notifications
Alarm
number
ES-LFE
CV-PFE
ES-PFE
ESA-PFE
ESB-PFE
SES-PFE
SEFS-PFE
UAS-PFE
CSS-PFE
9.8.13 CES physical interface performance monitoring history data 3

This managed entity collects auxiliary statistics for a CES physical interface. It is specifically
directed at DS1 interfaces ([b-ATIS-0300231], [b-ATIS-0600403]), but may be useful in other
cases as well.
Relationships
Attributes
294
Rec. ITU-T G.988 (10/2012)
Each of the following attributes is (R) (optional) (2 bytes).

Attribute name
Common acronym
AIS-CI seconds
AISSCI-P
Errored seconds, network performance
ES-NP
Severely errored seconds, network performance
SES-NP
Unavailable seconds, network performance
UAS-NP
Errored seconds, network performance, far-end
ES-NPFE
Severely errored seconds, NP far-end
SES-NPFE
Unavailable seconds, NP far-end
UAS-NPFE
Failure count
FC
Protection switch count
PSC
Protection switch duration
PSD
Actions
Notifications
Alarm
number
AISSCI-P
ES-NP
SES-NP
UAS-NP
ES-NPFE
SES-NPFE
UAS-NPFE
9.8.14 MPLS pseudowire termination point

This managed entity contains the configuration data of a pseudowire whose underlying transport
method is MPLS. Instances of this managed entity are created and deleted by the OLT.
Relationships
Zero or one instance of this managed entity is associated with each instance of the
pseudowire termination point managed entity.
Attributes
TP type:
This attribute specifies the type of ANI-side termination point associated with
this managed entity.
Rec. ITU-T G.988 (10/2012)
295

2 GEM interworking TP
3 TCP/UDP config data
NOTE If this instance of the MPLS PW TP is pointed to by another instance of the
MPLS PW TP (i.e., whose TP type = 4), this instance represents a tunnelled MPLS
flow, and the following attributes are not meaningful: MPLS PW direction, MPLS
PW uplink label, MPLS PW downlink label, and MPLS PW TC. These attributes
should be set to the proper number of 0x00 bytes by the OLT and ignored by the
ONU.

TP pointer:
This attribute points to the instance of the TP associated with this MPLS PW
TP. The type of the associated TP is determined by the TP type attribute. (R,
W, Set-by-create) (mandatory) (2 bytes)
MPLS label indicator: This attribute specifies the MPLS label stacking situation.
0 Single MPLS labelled
1 Double MPLS labelled
MPLS PW direction: This attribute specifies the inner MPLS direction.
0 Upstream only
1 Downstream only
2 Bidirectional
MPLS PW uplink label: This attribute specifies the label of the inner MPLS pseudowire
upstream. The attribute is not meaningful for unidirectional downstream
PWs. (R, W, Set-by-create) (mandatory) (4 bytes)
MPLS PW downlink label: This attribute specifies the label of the inner MPLS pseudowire
downstream. The attribute is not meaningful for unidirectional upstream
PWs. (R, W, Set-by-create) (mandatory) (4 bytes)
MPLS PW TC: This attribute specifies the inner MPLS TC value in the upstream direction.
The attribute is not meaningful for unidirectional downstream PWs. (R, W,
NOTE 1 The TC field was previously known as EXP. Refer to
[b-IETF RFC 5462].
MPLS tunnel direction: This attribute specifies the direction of the (outer) MPLS tunnel.
0 Upstream only
1 Downstream only
2 Bidirectional
(R, W, Set-by-create) (mandatory for double-labelled case) (1 byte)
MPLS tunnel uplink label: This attribute specifies the (outer) label for the upstream MPLS
tunnel. If the MPLS tunnel is downstream only, this attribute should be set to
0. (R, W, Set-by-create) (mandatory for double-labelled case) (4 bytes)
MPLS tunnel downlink label: This attribute specifies the (outer) label for the downstream
MPLS tunnel. If the MPLS tunnel is upstream only, this attribute should be
set to 0. (R, W, Set-by-create) (mandatory for double-labelled case) (4 bytes)
296
Rec. ITU-T G.988 (10/2012)
MPLS tunnel TC: This attribute specifies the TC value of the upstream MPLS tunnel. If the
MPLS tunnel is downstream only, this attribute should be set to 0. (R, W,
Set-by-create) (mandatory for double MPLS labelled case) (1 byte)
NOTE 2 The TC field was previously known as EXP. Refer to
[b-IETF RFC 5462].
Pseudowire type: This attribute specifies the emulated service to be carried over this PW.
The values are from [IETF RFC 4446].
2
ATM AAL5 SDU VCC transport
3
ATM transparent cell transport
5
Ethernet
9
ATM n-to-one VCC cell transport
10
ATM n-to-one VPC cell transport
12
ATM one-to-one VCC cell mode
13
ATM one-to-one VPC cell mode
14
ATM AAL5 PDU VCC transport
All other values are reserved.
Pseudowire control word preference: When set to true, this Boolean attribute specifies
that a control word is to be sent with each packet. Some PW types mandate
the use of a control word in any event. In such cases, the value configured for
this attribute has no effect on the presence of the control word. (R, W,
the MPLS pseudowire TP. Administrative state is further described in clause
A.1.6. (R, W) (optional) (1 byte)
Operational state: This attribute reports whether the managed entity is currently capable of
(optional) (1 byte)
Actions
Notifications
Number
1..14
Description
N/A
15
Op state
16
Reserved
Operational state
9.8.15 PW ATM configuration data

This managed entity contains generic configuration data for an ATM pseudowire. Definitions of
attributes are from PW-ATM-MIB [IETF RFC 5605]. Instances of this managed entity are created
and deleted by the OLT.
Rec. ITU-T G.988 (10/2012)
297
Relationships
An instance of this managed entity is associated with an instance of the MPLS pseudowire
termination point managed entity with a pseudowire type attribute equal to one of the
following:
2
ATM AAL5 SDU VCC transport
ATM transparent cell transport
10 ATM n-to-one VPC cell transport

12 ATM one-to-one VCC cell mode
13 ATM one-to-one VPC cell mode
14 ATM AAL5 PDU VCC transport
Alternatively, an instance of this managed entity may be associated with an Ethernet flow
TP or a TCP/UDP config data ME, depending on the transport layer of the pseudowire.
Attributes
TP type:
This attribute specifies the type of the underlying transport layer. (R, W,
2 TCP/UDP config data
Transport TP pointer: This attribute points to an associated instance of the transport layer
termination point, whose type is specified by the TP type attribute. (R, W,
PPTP ATM UNI pointer: This attribute points to an associated instance of the ITU-T
G.983.2 PPTP ATM UNI. Refer to [ITU-T G.983.2] for the definition of the
target ME. (R, W, Set-by-create) (mandatory) (2 bytes)
Max cell concatenation: This attribute specifies the maximum number of ATM cells that
can be concatenated into one PW packet in the upstream direction. (R, W,
Far-end max cell concatenation: This attribute specifies the maximum number of ATM
cells that can be concatenated into one PW packet as provisioned at the far
end. This attribute may be used for error checking of downstream traffic. The
ATM CLP QoS mapping: This attribute specifies whether the cell loss priority (CLP) bits
should be considered when setting the value in the quality of service fields of
the encapsulating protocol (e.g., TC fields of the MPLS label stack).
1
ATM CLP bits mapping to quality of service fields of the
encapsulating protocol
2 Not applicable
The value 0 specifies that the ONU use its internal default. (R, W,
298
Rec. ITU-T G.988 (10/2012)
Timeout mode: This attribute specifies whether or not a packet is transmitted in the
upstream direction based on timeout expiration for collecting cells. The
actual handling of the timeout is implementation specific; as such, this
attribute may be changed at any time with proper consideration of the traffic
disruption effect.
1 Disabled. The ONU does not generate packets based on timeout cells.
2 Enabled. The ONU generates packets based on timeout cells.
The value 0 specifies that the ONU use its internal default. (R, W,
PW ATM mapping table: This attribute lists ATM VPI/VCI mapping entries in both the
upstream and downstream directions. In the upstream direction, ATM cells
that match no entry's upstream VPI (and conditionally VCI) values are
discarded; conversely in the downstream direction. Upon ME instantiation,
the ONU sets this attribute to an empty table, which discards all cells in both
directions.
The table can contain up to N entries when the pseudowire type is equal to
one of the following:
9 ATM n-to-one VCC cell transport
10 ATM n-to-one VPC cell transport
The table contains only one entry when the pseudowire type is equal to one
of the following:
2 ATM AAL5 SDU VCC transport
3 ATM transparent cell transport
12 ATM one-to-one VCC cell mode
13 ATM one-to-one VPC cell mode
14 ATM AAL5 PDU VCC transport
Each entry contains:
Entry number: (1 byte), the index of this row. A set operation with all
fields zero has the effect of clearing the table. A set operation with a
non-zero entry number and all other fields zero, has the effect of
deleting one row.
Upstream VPI: (2 bytes)
The VPI value of this ATM PW at the UNI. When
pseudowire type = ATM transparent cell transport (3), this
field is ignored.
Upstream VCI: (2 bytes)
The VCI value of this ATM PW at the UNI. When
pseudowire type = ATM transparent cell transport (3), or in
VP cases, this field is ignored.
Upstream traffic descriptor profile pointer: (2 bytes)
A pointer to an instance of an ITU-T G.983.2 traffic
descriptor profile managed entity that contains the traffic
parameters used for the ATM upstream traffic. Refer to
clause 7.5.2 of [ITU-T G.983.2] for the definition of this
class of MEs. A null pointer indicates best effort.
Upstream mapped VPI: (2 bytes)
The VPI value of the upstream MPLS ATM PW. This field
is valid when the pseudowire type is:
Rec. ITU-T G.988 (10/2012)
299
10
12
13
This field is not used for other pseudowire types.

Upstream mapped VCI: (2 bytes)
The VCI value of the upstream MPLS ATM PW. This field
is valid when the pseudowire type is:
9
10
12
13

Downstream VPI: (2 bytes)
The downstream VPI value of this MPLS ATM PW. When
pseudowire type = ATM transparent cell transport (3), this
field is ignored.
Downstream VCI: (2 bytes)
The downstream VCI value of this MPLS ATM PW. When
pseudowire type = ATM transparent cell transport (3), or in
the VP case, this field is ignored.
Downstream traffic descriptor profile pointer: (2 bytes)
A pointer to an instance of an ITU-T G.983.2 traffic
descriptor profile managed entity that contains the traffic
parameters used for the ATM downstream traffic. Refer to
clause 7.5.2 of [ITU-T G.983.2] for definition of this class
of MEs. A null pointer indicates best effort.
Downstream mapped VPI: (2 bytes)
The VPI value of this ATM PW at the UNI. This field is
valid when the pseudowire type is:
9
10
12
13

Downstream mapped VCI: (2 bytes)
The VCI value of this ATM PW at the UNI. This field is
valid when the pseudowire type is:
300
Rec. ITU-T G.988 (10/2012)
10
12
13

(R, W) (mandatory) (21N bytes, where N is the number of entries in the list)
Actions
Notifications
None.
9.8.16 PW ATM performance monitoring history data
This managed entity collects performance monitoring data associated with an ATM pseudowire.
Relationships
An instance of this managed entity is associated with an instance of the PW ATM
Attributes
Through an identical ID, this managed entity is implicitly linked to the
instance of the PW ATM configuration data managed entity. (R,
Downstream missing packets counter: This attribute counts missing packets, as detected
via control word sequence number gaps. (R) (mandatory) (4 bytes)
Downstream reordered packets counter: This attribute counts packets detected out of
sequence via the control word sequence number, but successfully reordered.
Some implementations may not support this feature. (R) (optional) (4 bytes)
Downstream misordered packets counter: This attribute counts packets detected out of
order via the control word sequence numbers. (R) (mandatory) (4 bytes)
Upstream timeout packets counter: This attribute counts packets transmitted due to
timeout expiration while attempting to collect cells. (R) (mandatory)
(4 bytes)
Upstream transmitted cells counter: This attribute counts transmitted cells. (R)
Upstream dropped cells counter: This attribute counts dropped cells. (R) (mandatory)
(4 bytes)
Upstream received cells counter: This attribute counts received cells. (R) (mandatory)
(4 bytes)
Rec. ITU-T G.988 (10/2012)
301
Actions
Notifications
Alarm
number
Downstream missing packets
Downstream reordered packets
Downstream timeout packets
Upstream dropped cells
9.8.17 PW Ethernet configuration data

This managed entity contains the Ethernet pseudowire configuration data. Instances of this managed
Relationships
An instance of this managed entity is associated with an instance of the MPLS pseudowire
termination point managed entity with a pseudowire type attribute equal to the following:
5 Ethernet
Attributes
MPLS pseudowire TP pointer: This attribute points to an instance of the MPLS
pseudowire termination point ME associated with this ME. (R, W,
TP type:
This attribute identifies the type of UNI associated with this Ethernet PW.
Valid values are:
7 Physical path termination point xDSL UNI part 1
13 MAC bridge port configuration data
Other values are reserved
UNI pointer: This attribute points to the associated instance of a UNI-side ME. The type of
UNI is determined by the TP type attribute. (R, W, Set-by-create)
Actions
302
Rec. ITU-T G.988 (10/2012)
Notifications
None.
9.8.18 Ethernet pseudowire parameters
This managed entity contains the Ethernet pseudowire parameters. Instances of this managed entity
are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an instance of the PW Ethernet
Attributes
instance of the PW Ethernet configuration data managed entity. (R, Set-bycreate) (mandatory) (2 bytes)
MTU:
This attribute identifies the maximum transmission unit (bytes) that can be
received from the CPE in the upstream direction. Larger frames are
discarded. (R, W, Set-by-create) (mandatory) (2 bytes)
Actions
Notifications
None.
Rec. ITU-T G.988 (10/2012)
303
9.9
Voice services
This clause defines managed entities associated with a POTS (VoIP service), as shown in
Figure 9.9-1.
Call control
PM history
data
RTP PM
history data
9.9.12
9.9.13
PPTP POTS
UNI
VoIP line
status
9.9.1
9.9.11
9.9.4
9.9.2
VoIP media
profile
9.9.5
MGC PM
history data
9.9.17
Points to:
(3x) Network address
9.9.8
N
Points to:
(3x) Large string
Network address
TCP/UDP configuration
data
SIP agent
configuration
data
9.9.3
9.9.7
SIP call
initiation
PM history data
Voice
service profile
9.9.6
VoIP
application
service profile
9.9.9
VoIP feature
access codes
RTP
profile
data
Points to:
Authentication security
method
Large string (AoR)
Network address
SIP user
data
VoIP voice
CTP
Network
dial plan
table 9.9.10
SIP agent
PM history
data 9.9.14
9.9.15
N
MGC
configuration
data
9.9.16
SIP
configuration
portal
Points to:
(2x) Network address
TCP/UDP configuration
data
VoIP config
data
9.9.19
MGC
configuration
portal
Points to:
Network address
9.9.18
G.988(12)_F9.9-1
9.9.20
Figure 9.9-1 Managed entities associated with a POTS (VoIP service)

9.9.1
Physical path termination point POTS UNI
This managed entity represents a POTS UNI in the ONU, where a physical path terminates and
physical path level functions (analogue telephony) are performed.
304
when the ONU has POTS ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the POTS type;
POTS type. Note that the installation of a plug-and-play card may indicate the presence of
POTS ports via equipment ID as well as type, and indeed may cause the ONU to instantiate
a port mapping package that specifies POTS ports.
Rec. ITU-T G.988 (10/2012)
provisioned to expect a POTS circuit pack, nor is it equipped with a POTS circuit pack.
Relationships
An instance of this managed entity is associated with each real or pre-provisioned POTS
port. Either a SIP or a VoIP voice CTP links to the POTS UNI. Status is available from a
VoIP line status ME, and RTP and call control PM may be collected on this point.
Attributes
Administrative state: This attribute shuts down (2), locks (1) and unlocks (0) the functions
performed by this managed entity. In case the administrative state is set to
shut down while the POTS UNI line state is non-idle, no action is taken until
the POTS UNI line state changes to idle, whereupon the administrative state
changes to locked. In case the administrative state is set to shut down and the
POTS UNI line state is already idle, the administrative state is immediately
set to locked. In both cases, the transition from shutting down to locked state
is signalled with an AVC.
When the administrative state is set to lock, all user functions of this UNI are
blocked, and alarms, TCAs and AVCs for this managed entity and all
dependent managed entities are no longer generated. Selection of a default
value for this attribute is outside the scope of this Recommendation. (R, W)
Deprecated: This attribute is not used and should not be supported. (R, W) (optional)
(2 bytes)
ARC:

Impedance:
This attribute specifies the impedance for the POTS UNI. Valid values
include:
0 600 Ohms
1 900 Ohms
The following parameter sets from Annex C of [ETSI TS 101 270-1] are also
defined:
2 C1=150 nF, R1=750 Ohm, R2=270 Ohm
3 C1=115 nF, R1=820 Ohm, R2=220 Ohm
4 C1=230 nF, R1=1050 Ohm, R2=320 Ohm
where C1, R1, and R2 are related as shown in Figure 9.9.1-1. Upon ME
instantiation, the ONU sets this attribute to 0. (R, W) (optional) (1 byte)
G.988(12)_F9.9.1-1
Figure 9.9.1-1 Impedance model for POTS UNI

Rec. ITU-T G.988 (10/2012)
305
Transmission path: This attribute allows setting the POTS UNI either to full-time on-hook
transmission (0) or part-time on-hook transmission (1). Upon ME
instantiation, the ONU sets this attribute to 0. (R, W) (optional) (1 byte)
Rx gain:
This attribute specifies a gain value for the received signal in the form of a 2s
complement number. Valid values are 120 (12.0 dB) to 60 (+6.0 dB). The
direction of the affected signal is in the D to A direction, towards the
telephone set. Upon ME instantiation, the ONU sets this attribute to 0. (R, W)
(optional) (1 byte)
Tx gain:
This attribute specifies a gain value for the transmit signal in the form of a 2s
complement number. Valid values are 120 (12.0 dB) to 60 (+6.0 dB). The
direction of the affected signal is in the A to D direction, away from the
telephone set. Upon ME instantiation, the ONU sets this attribute to 0. (R, W)
(optional) (1 byte)
(optional) (1 byte)
Hook state:
This attribute indicates the current state of the subscriber line: 0 = on hook,
1 = off hook (R) (optional) (1 byte)
POTS holdover time: This attribute determines the time during which the POTS loop
voltage is held up when the ONU is not ranged on the PON. After the
specified time elapses, the ONU drops the loop voltage, and may thereby
cause premises intrusion alarm circuits to go active. When the ONU ranges
successfully on the PON, it restores the POTS loop voltage immediately and
resets the timer to zero. The attribute is expressed in seconds. The default
value 0 selects the vendor's factory policy. (R, W) (optional) (2 bytes)
Nominal feed voltage: This attribute indicates the designed nominal feed voltage of the
POTS loop. It is an absolute value with resolution 1 Volt. This attribute does
not represent the actual voltage measured on the loop, which is available
through the test command. (R, W) (optional) (1 byte)
Actions
Get, set
Request that the ONU perform one or more MLT tests or a dial tone
make/break test. Vendor-specific tests are also supported by the test and test
result message layouts in Annex A.
Test:
Notifications
Number
1
Administrative state
N/A
ARC
4..8
N/A
306
Op state
10..11
N/A
12..16
Reserved
Rec. ITU-T G.988 (10/2012)
Description
The only change that is signalled with an AVC
is the transition from shutting down to locked.
Operational state
9.9.2
SIP user data
The SIP user data defines the user specific configuration attributes associated with a specific VoIP
CTP. This entity is conditionally required for ONUs that offer VoIP SIP services. If a non-OMCI
interface is used to manage SIP for VoIP, this ME is unnecessary. The non-OMCI interface supplies
the necessary data, which may be read back to the OLT via the SIP config portal ME.
An instance of this managed entity is created and deleted by the OLT. A SIP user data instance is
required for each POTS UNI port using SIP protocol and configured by the OMCI.
Relationships
An instance of this managed entity is associated with one VoIP voice CTP managed entity
and a PPTP POTS UNI.
Attributes
SIP agent pointer: This attribute points to the SIP agent config data ME to be used for
signalling. (R, W, Set-by-create) (mandatory) (2 bytes)
User part AOR: This attribute points to a large string that contains the user identification
part of the address of record. This can take the form of an alphanumeric
string or the subscriber's directory number. A null pointer indicates the
absence of an AOR. (R, W, Set-by-create) (mandatory) (2 bytes)
SIP display name: This ASCII string attribute defines the customer ID used for the display
attribute in outgoing SIP messages. The default value is null (all zero bytes)
Username/password: This attribute points to an authentication security method ME that
contains the SIP user name and password used for authentication. A null
pointer indicates no username/password. (R, W, Set-by-create) (mandatory)
(2)
Voicemail server SIP URI: This attribute points to a network address ME that contains the
name (IP address or URI) of the SIP voicemail server for SIP signalling
messages. A null pointer indicates the absence of a SIP voicemail server.
Voicemail subscription expiration time: This attribute defines the voicemail subscription
expiration time in seconds. If this value is 0, the SIP agent uses an
implementation-specific value. This attribute is recommended to be set to
3600 seconds by default. (R, W, Set-by-create) (mandatory) (4 bytes)
Network dial plan pointer: This attribute points to a network dial plan table. A null pointer
indicates the absence of a network dial plan. (R, W, Set-by-create)
Application services profile pointer: This attribute points to a VoIP application services
profile. (R, W, Set-by-create) (mandatory) (2 bytes)
Feature code pointer: This attribute points to the VoIP feature access codes ME for this
subscriber. A null pointer indicates the absence of a VoIP feature access
codes ME. (R, W, Set-by-create) (mandatory) (2 bytes)
PPTP pointer: This attribute points to the PPTP POTS UNI managed entity that provides
the analogue telephony adaptor (ATA) function. (R, W, Set-by-create)
Rec. ITU-T G.988 (10/2012)
307
Release timer: This attribute contains a release timer defined in seconds. The value 0
specifies that the ONU is to use its internal default. The default value of this
attribute is 10 seconds. (R, W) (optional) (1 byte)
ROH timer: This attribute defines the time in seconds for the receiver off hook condition
before ROH tone is applied. The value 0 disables ROH timing. The value
0xFF specifies that the ONU is to use its internal default, which may or may
not be the same as the 15 second OMCI default value. (R, W) (optional)
(1 byte)
Actions
Notifications
Alarm
Alarm
number
Description
SIPUA register auth
Cannot authenticate a registration session (e.g., missing

credentials)
SIPUA register timeout
Timeout waiting for response from a registration server
SIPUA register fail
Failure response received from a registration server
3..207
208..223
9.9.3
Alarm
Reserved
The SIP agent config data managed entity models a SIP signalling agent. It defines the
configuration necessary to establish communication for signalling between the SIP user agent and a
SIP server.
NOTE 1 If a non-OMCI interface is used to manage SIP for VoIP, this ME is unnecessary. The non-OMCI
interface supplies the necessary data, which may be read back to the OLT via the SIP config portal ME.
Relationships
An instance of this managed entity serves one or more SIP user data managed entities and
points to a TCP/UDP config data that carries signalling messages. Other pointers establish
additional agent parameters such as proxy servers.
Attributes
Proxy server address pointer: This attribute points to a large string ME that contains the
name (IP address or URI) of the SIP proxy server for SIP signalling
messages. (R, W, Set-by-create) (mandatory) (2 bytes)
Outbound proxy address pointer: An outbound SIP proxy may or may not be required
within a given network. If an outbound SIP proxy is used, the outbound
proxy address pointer attribute must be set to point to a valid large string ME
that contains the name (IP address or URI) of the outbound proxy server for
SIP signalling messages. If an outbound SIP proxy is not used, the outbound
proxy address pointer attribute must be set to a null pointer. (R, W,
308
Rec. ITU-T G.988 (10/2012)
Primary SIP DNS: This attribute specifies the primary SIP DNS IP address. If the value of
this attribute is 0, the primary DNS server is defined in the corresponding IP
host config data or IPv6 host config data ME. If the value is non-zero, it takes
precedence over the primary DNS server defined in the IP host config data or
IPv6 host config data ME. (R, W, Set-by-create) (mandatory) (4 bytes)
Secondary SIP DNS: This attribute specifies the secondary SIP DNS IP address. If the
value of this attribute is 0, the secondary DNS server is defined in the
corresponding IP host config data or IPv6 host config data ME. If the value is
non-zero, it takes precedence over the secondary DNS server defined in the
IP host config data or IPv6 host config data ME. (R, W, Set-by-create)
TCP/UDP pointer: This pointer associates the SIP agent with the TCP/UDP config data
ME to be used for communication with the SIP server. The default value is
0xFFFF, a null pointer. (R, W) (mandatory) (2 bytes)
SIP reg exp time: This attribute specifies the SIP registration expiration time in seconds. If
its value is 0, the SIP agent does not add an expiration time to the registration
requests and does not perform re-registration. The default value is
3600 seconds. (R, W) (mandatory) (4 bytes)
SIP rereg head start time: This attribute specifies the time in seconds prior to timeout that
causes the SIP agent to start the re-registration process. The default value is
360 seconds. (R, W) (mandatory) (4 bytes)
Host part URI: This attribute points to a large string ME that contains the host or domain
part of the SIP address of record for users connected to this ONU. A null
pointer indicates that the current address in the IP host config ME is to be
used. (R, W, Set-by-create) (mandatory) (2 bytes)
SIP status:
This attribute shows the current status of the SIP agent. Values are as
follows:
0 Ok/initial
1 Connected
2 Failed ICMP error
3 Failed Malformed response
4 Failed Inadequate info response
5 Failed Timeout
6 Redundant, offline: this instance of the SIP agent config data occupies
the role of a redundant server, and is not presently in use.
SIP registrar: This attribute points to a network address ME that contains the name (IP
address or resolved name) of the registrar server for SIP signalling messages.
Examples: "10.10.10.10" and "proxy.voip.net". (R, W, Set-by-create)
Softswitch:
This attribute identifies the SIP gateway softswitch vendor. The format is
four ASCII coded alphabetic characters [A..Z] as defined in [ATIS-0300220].
A value of four null bytes indicates an unknown or unspecified vendor.
Rec. ITU-T G.988 (10/2012)
309
SIP response table: This attribute specifies the tone and text to be presented to the
subscriber upon receipt of various SIP messages (normally 4xx, 5xx, 6xx
message codes). The table is a sequence of entries, each of which is defined
as follows:
SIP response code (2 bytes): This field is the value of the SIP message code.
It also serves as the index into the SIP response table. When a set
operation is performed with the value 0 in this field, the table is cleared.
Tone (1 byte): This field specifies one of the tones in the tone pattern table of
the associated voice service profile. The specified tone is played to the
subscriber.
Text message (2 bytes): This field is a pointer to a large string that contains a
message to be displayed to the subscriber. If the value of this field is a
null pointer, text pre-associated with the tone may be displayed, or no text
at all.
(R, W) (optional) (N * 5 bytes)
NOTE 2 This model assumes that SIP response tones and text are common to all
POTS lines that share a given SIP agent.
SIP option transmit control: This Boolean attribute specifies that the ONU is (true) or is
not (false) enabled to transmit SIP options. The default value is
recommended to be false. (R, W, Set-by-create) (optional) (1 byte)
SIP URI format: This attribute specifies the format of the URI in outgoing SIP messages.
The recommended default value 0 specifies TEL URIs; the value 1 specifies
SIP URIs. Other values are reserved. (R, W, Set-by-create) (optional) (1
byte)
Redundant SIP agent pointer: This attribute points to another SIP agent config data ME,
which is understood to provide redundancy. The initial SIP agent is
determined by the pointer from the SIP user data ME. It is the manager's
responsibility to provision a group of redundant SIP agents with mutually
consistent attributes. (R, W, Set-by-create) (optional) (2 bytes)
Actions
Notifications
Number
1..8
9
310
Description
N/A
SIP status
10..11
N/A
12..16
Reserved
Rec. ITU-T G.988 (10/2012)
Status change
Alarm
Alarm
number
Alarm
Description
SIPUA register name
Failed to resolve the registration server name
SIPUA register reach
Cannot reach a registration server (the port cannot be

reached, ICMP errors)
SIPUA register connect
Cannot connect to a registration server (due to bad

credentials or other faults after the port has responded)
SIPUA register validate
Cannot validate a registration server
4 (Note)
SIPUA register auth
Cannot authenticate a registration session (e.g., missing

credentials)
5 (Note)
SIPUA register timeout
Timeout waiting for response from a registration server
6 (Note)
SIPUA register fail
Failure response received from a registration server
7..207
208..223
Reserved
NOTE These alarms are deprecated, and retained for backward compatibility. It is recommended
that the SIP agent config data not declare these alarms, but that they be declared by the SIP user
data ME instead. In any event, only one ME should declare the alarm, not both.
9.9.4
VoIP voice CTP
The VoIP voice CTP defines the attributes necessary to associate a specified VoIP service (SIP,
ITU-T H.248) with a POTS UNI. This entity is conditionally required for ONUs that offer VoIP
services. If a non-OMCI interface is used to manage VoIP signalling, this ME is unnecessary.
An instance of this managed entity is created and deleted by the OLT. A VoIP voice CTP managed
entity is needed for each PPTP POTS UNI served by VoIP.
Relationships
An instance of this managed entity links a PPTP POTS UNI managed entity with a VoIP
media profile and a SIP user data or MGC config data ME.
Attributes
User protocol pointer: This attribute points to signalling protocol data. If the signalling
protocol used attribute of the VoIP config data managed entity specifies that
the ONU's signalling protocol is SIP, this attribute points to a SIP user data
ME, which in turn points to a SIP agent config data. If the signalling protocol
is ITU-T H.248, this attribute points directly to an MGC config data ME.
PPTP pointer: This attribute points to the PPTP POTS UNI managed entity that serves the
analogue telephone port. (R, W, Set-by-create) (mandatory) (2 bytes)
VOIP media profile pointer: This attribute points to an associated VoIP media profile.
Rec. ITU-T G.988 (10/2012)
311
Signalling code: This attribute specifies the POTS-side signalling:

1 Loop start
2 Ground start
3 Loop reverse battery
4 Coin first
5 Dial tone first
6 Multi-party
Actions
Notifications
None.
9.9.5
VoIP media profile
The VoIP media profile managed entity contains settings that apply to VoIP voice encoding. This
entity is conditionally required for ONUs that offer VoIP services. If a non-OMCI interface is used
to manage VoIP signalling, this ME is unnecessary.
An instance of this managed entity is created and deleted by the OLT. A VoIP media profile is
needed for each unique set of profile attributes.
Relationships
An instance of this managed entity may be associated with one or more VoIP voice CTP
managed entities.
Attributes
Fax mode:
Selects the fax mode; values are:

0 Passthru
1 ITU-T T.38
Voice service profile pointer: Pointer to a voice service profile, which defines parameters
such as jitter buffering and echo cancellation. (R, W, Set-by-create)
Codec selection (1st order): This attribute specifies codec selection as defined by
[IETF RFC 3551].
Value
312
Encoding name
Clock
rate (Hz)
PCMU
reserved
reserved
GSM
8,000
ITU-T G.723
8,000
DVI4
8,000
Rec. ITU-T G.988 (10/2012)
8,000
Value
Encoding name
Clock
rate (Hz)
DVI4
16,000
LPC
8,000
PCMA
8,000
ITU-T G.722
8,000
10
L16, 2 channels
44,100
11
L16, 1 channel
44,100
12
QCELP
8,000
13
CN
8,000
14
MPA
15
ITU-T G.728
16
DVI4
11,025
17
DVI4
22,050
18
ITU-T G.729
90,000
8,000
8,000

Packet period selection (1st order): This attribute specifies the packet period selection
interval in milliseconds. The recommended default value is 10. Valid values
are 10..30 ms. (R, W, Set-by-create) (mandatory) (1 byte)
Silence suppression (1st order): This attribute specifies whether silence suppression is on
or off. Valid values are 0 = off and 1 = on. (R, W, Set-by-create) (mandatory)
(1 byte)
Three more groups of three attributes are defined, with definitions identical to the preceding three:
Codec selection (2nd order):
nd
Packet period selection (2 order):

nd
Silence suppression (2 order):
Codec selection (3rd order):
rd
Packet period selection (3 order):

rd
Silence suppression (3 order):
Codec selection (4th order):
Packet period selection (4th order):
Silence suppression (4th order):
OOB DTMF: This attribute specifies out-of-band DMTF carriage. When enabled (1),
DTMF signals are carried out of band via RTP or the associated signalling
protocol. When disabled (0), DTMF tones are carried in the PCM stream.
RTP profile pointer: This attribute points to the associated RTP profile data ME. (R, W,
Rec. ITU-T G.988 (10/2012)
313
Actions
Notifications
None.
9.9.6
This managed entity organizes data that describe the voice service functions of the ONU. Instances
Relationships
An instance of this managed entity may be associated with zero or more instances of a VoIP
voice CTP by way of a VoIP media profile.
Attributes
Announcement type: This attribute specifies the treatment when a subscriber goes off hook
but does not attempt a call within the dial-tone timeout interval. Valid values
include:
0x01
Silence
0x02
Reorder tone
0x03
Fast busy
0x04
Voice announcement
0xFF
Not specified; ONU is free to make its own choice.
Jitter target: This attribute specifies the target value of the jitter buffer in milliseconds.
The system tries to maintain the jitter buffer at the target value. The value 0
specifies dynamic jitter buffer sizing. (R, W, Set-by-create) (optional)
(2 bytes)
Jitter buffer max: This attribute specifies the maximum depth of the jitter buffer associated
with this service in milliseconds. The value 0 specifies that the ONU use its
internal default. (R, W, Set-by-create) (optional) (2 bytes)
Echo cancel ind: The Boolean value true specifies that echo cancellation is on; false
specifies off. (R, W, Set-by-create) (mandatory) (1 byte)
PSTN protocol variant: This attribute controls which variant of POTS signalling is used on
the associated UNIs. Its value is equal to the [ITU-T E.164] country code.
The value 0 specifies that the ONU use its internal default. (R, W, Set-bycreate) (optional) (2 bytes)
DTMF digit levels: This attribute specifies the power level of DTMF digits that may be
generated by the ONU towards the subscriber set. It is a 2s complement value
referred to 1 mW at the 0 TLP (dBm0), with resolution 1 dB. The default
value 0x8000 selects the ONU's internal policy. (R, W, Set-by-create)
DTMF digit duration: This attribute specifies the duration of DTMF digits that may be
generated by the ONU towards the subscriber set. It is specified in
milliseconds. The default value 0 selects the ONU's internal policy. (R, W,
314
Rec. ITU-T G.988 (10/2012)
Hook flash minimum time: This attribute defines the minimum duration recognized by the
ONU as a switchhook flash. It is expressed in milliseconds; the default value
0 selects the ONU's internal policy. (R, W, Set-by-create) (optional) (2 bytes)
Hook flash maximum time: This attribute defines the maximum duration recognized by the
ONU as a switchhook flash. It is expressed in milliseconds; the default value
0 selects the ONU's internal policy. (R, W, Set-by-create) (optional) (2 bytes)
Tone pattern table: This attribute is a table, each of whose entries specifies a complex tone
(or silence) and a duration. By linking tones and silence together, possibly
cyclically, continuous, varying or interrupted tone sequences, repetitive or
not, may be defined. A tone sequence is initiated by pointing to the first tone
pattern table entry that defines its parameters. Each entry is a vector
comprising the following components:
Index (1 byte): This component is simply an index into the table. It ranges
from 1..255. In a set operation, the value 0 in this field clears the table.
Tone on (1 byte): This Boolean component controls whether the tone is on
(true) or off. If the tone is off, the frequency and power fields are not
meaningful.
Frequency 1 (2 bytes): This component specifies the frequency of one of the
tone components in Hz.
Power 1 (1 byte): This component specifies the power level of the
corresponding frequency component. It ranges from 0 (coded as 0) to
25.5 (coded as 255) dBm0 with 0.1 dB resolution.
Three additional pairs of frequency-power components may be specified to
define a complex tone. If a pair of possibilities is not to be used, its frequency
field should be set to 0.
Frequency 2 (2 bytes)
Power 2 (1 byte)
Power 3 (1 byte)
Power 4 (1 byte)
The following pair of frequency-power components allows the composite
tone to be modulated (warble effect). If this effect is not to be used, the
frequency should be set to 0.
Modulation frequency (2 bytes), Hz
Modulation power (1 byte), 0..25.5 dBm0
Duration (2 bytes): This component specifies the duration of the phase, in
milliseconds. The value 0 specifies that the phase endures indefinitely,
that is, until terminated by other events such as call abandonment.
Next entry (1 byte): This component is a pointer to another entry in this
same table, which permits sequences of tones to be defined, possibly
cyclically. A reference to a non-existent table entry, or the value 0,
indicates that the sequence should be terminated.
(R, W) (optional) (N * 20 bytes)
Tone event table: This attribute is a table, each of whose entries specifies an event for
which a tone is defined. If the tone can be synthesized by a sequence of
complex tones and silence, the event refers to an entry in the tone pattern
Rec. ITU-T G.988 (10/2012)
315
table. Otherwise, the event refers to a file name that is expected to be

recognized by the ONU environment. Each entry in the tone event table is a
vector comprising the following components:
Event (1 byte): This component is an enumeration of the events for which a
tone may be defined. The event component also serves as the index for
the table. A set operation to event 0 causes the table to be cleared.
Value
Tone event
Not used for get operation; clears table under set operation
Busy
Confirmation
Dial
Message waiting
Off hook warning (receiver off hook)
Ringback (audible ring)
Reorder
Stutter dial
Call waiting 1
10
Call waiting 2
11
Call waiting 3
12
Call waiting 4
13
Alerting signal
14
Special dial
15
Special info
16
Release
17
Congestion
18
User defined 1
19
User defined 2
20
User defined 3
21
User defined 4
22..32
Reserved
33
Intrusion
34
Dead tone
35..223
Reserved
224..255
Vendor-specific codes, not to be standardized
Tone pattern (1 byte): This component specifies an entry point into the tone
pattern table attribute, to be invoked when the specified event occurs. The
value 0 indicates that no tone from the tone pattern table is to be played.
Tone file (2 bytes): This component points to a large string managed entity
that contains the path and name of a file containing a codec sequence to
be played out. If no file is found after traversing these links, no tone is
played. The behaviour is unspecified if both tone pattern and tone file are
specified.
316
Rec. ITU-T G.988 (10/2012)
Tone file repetitions (1 byte): This component specifies the number of times
the tone file is to be repeated. The value 0 means that the file is to be
repeated indefinitely until terminated by some external event such as call
abandonment.
Reserved (2 bytes)
(R, W) (optional) (N * 7 bytes).
Ringing pattern table: This attribute is a table, each of whose entries specifies a ringing
pattern and a duration. By linking ringing and silence together, possibly
cyclically, continuous or interrupted ringing sequences, repetitive or not, may
be defined. A ringing sequence is initiated by pointing to the first ringing
pattern table entry that defines its parameters. Each entry is a vector
comprising the following components:
Index (1 byte): This component is simply an index into the table. It ranges
from 1..255. In a set operation, the value 0 in this field clears the table.
Ringing on (1 byte): This Boolean component controls whether ringing is on
(true) or off during this interval.
Duration (2 bytes): This component specifies the duration of the ringing
phase, in milliseconds. The value 0 specifies that the phase endures
indefinitely, that is, until terminated by other events such as call
abandonment.
Next entry (1 byte): This component is a pointer to another entry in this
same table, which permits sequences of ringing bursts to be defined,
possibly cyclically. A reference to a non-existent table entry, or the value
0, indicates that the sequence should be terminated.
Ringing event table: This attribute is a table, each of whose entries specifies an event for
which a ringing sequence is defined. If the ringing sequence can be generated
as a sequence of power ringing and silent intervals, the event refers to an
entry in the ringing pattern table. Otherwise, the event refers to a file name
that is expected to be recognized by the ONU environment. Each entry is a
vector comprising the following components:
Event (1 byte): This component is an enumeration of the events for which a
ringing sequence may be defined. The event component also serves as the
index for the table. A set operation with the value 0 in this field causes
the table to be cleared.
Value
Tone event
Not used for get operation; clears table under set operation
Default
Splash
3..223
224..255
Reserved
Vendor-specific codes, not to be standardized
Ringing pattern (1 byte): This component specifies an entry point into the
ringing pattern table attribute, to be invoked when the specified event
Rec. ITU-T G.988 (10/2012)
317
occurs. The value 0 indicates that no ringing sequence is defined in the

ringing pattern table.
Ringing file (2 bytes): This component points to a large string managed
entity that contains the path and name of a file containing a ring tone to
be played out. If no file is found after traversing these links, no ringing is
played. The behaviour is unspecified if both ringing pattern and ringing
file fields are specified.
Ringing file repetitions (1 byte): This component specifies the number of
times the ringing file is to be repeated. The value 0 means that the file is
to be repeated indefinitely until terminated by some external event such
as call abandonment.
Ringing text (2 bytes): This component points to a large string managed
entity that contains a text string to be displayed on the CPE device in
conjunction with this event. A null pointer indicates that no text is to be
displayed.
Network specific extensions pointer: This attribute points to a network address managed
entity that contains the path and name of a file containing network specific
parameters for the associated UNIs. The default value for this attribute is
0xFFFF, a null pointer. (R, W, Set-by-create) (optional) (2 bytes)
Actions
Notifications
Alarm
Number
1
2..207
9.9.7
Alarm
File not found
Description
The voice service profile attempted to access a network
specific extensions file that is not available.
Reserved
RTP profile data
This managed entity configures RTP. It is conditionally required for ONUs that offer VoIP service.
If a non-OMCI interface is used to manage VoIP, this ME is unnecessary.
An instance of this managed entity is created and deleted by the OLT. An RTP profile is needed for
each unique set of attributes.
Relationships
An instance of this managed entity may be associated with one or more VoIP media profile
managed entities.
Attributes
Local port min: This attribute defines the base UDP port that should be used by RTP for
voice traffic. The recommended default is 50 000 (R, W, Set-by-create)
318
Rec. ITU-T G.988 (10/2012)
Local port max: This attribute defines the highest UDP port used by RTP for voice traffic.
The value must be greater than local port min. The value 0 specifies that the
local port max be equal to the local port min. (R, W, Set-by-create) (optional)
(2 bytes)
DSCP mark: Diffserv code point to be used for outgoing RTP packets for this profile. The
recommended default value is expedited forwarding (EF) = 0x2E. (R, W,
Piggyback events: Enables or disables RTP piggyback events.
0 Disabled (recommended default)
1 Enabled
Tone events: Enables or disables the handling of tones via RTP tone events per [IETF RFC
4733], (see also [IETF RFC 4734]).
0 Disabled (recommended default)
1 Enabled
DTMF events: Enables or disables the handling of DTMF via RTP DTMF events per [IETF
RFC 4733], (see also [IETF RFC 4734]). This attribute is ignored unless the
OOB DTMF attribute in the VoIP media profile is enabled.
0 Disabled
1 Enabled
CAS events: Enables or disables the handling of CAS via RTP CAS events per [IETF RFC
4733], (see also [IETF RFC 4734]).
0 Disabled
1 Enabled
IP host config pointer: This optional pointer associates the bearer (voice) flow with an IP
host config data or IPv6 host config data ME. If this attribute is not present or
is not populated with a valid pointer value, the bearer flow uses the same IP
stack that is used for signalling, indicated by the TCP/UDP pointer in the
associated SIP agent or MGC config data. The default value is 0xFFFF, a
null pointer. (R, W) (optional) (2 bytes)
Actions
Notifications
None.
9.9.8
The VoIP application service profile defines attributes of calling features used in conjunction with a
VoIP line service. It is optional for ONUs that support VoIP services. If a non-OMCI interface is
used to manage SIP for VoIP, this ME is unnecessary.
An instance of this managed entity is created and deleted by the OLT. A VoIP application service
profile instance is needed for each unique set of profile attributes.
Rec. ITU-T G.988 (10/2012)
319
Relationships
An instance of this managed entity is associated with zero or more SIP user data MEs.
Attributes
CID features: This attribute contains a bit map of caller ID features. Except as noted, the bit
value 0 disables the feature; 1 enables it.
0x01
Calling number
0x02
Calling name
0x04
CID blocking (both number and name)
0x08
CID number Permanent presentation status for
number (0 = public, 1 = private)
0x10
CID name Permanent presentation status for name
(0 = public, 1 = private)
0x20
Anonymous CID blocking (ACR). It may not be
possible to support this in the ONU.
0x40..0x80
Not used
The recommended default value is 0x00. (R, W, Set-by-create) (mandatory)
(1 byte)
Call waiting features: This attribute contains a bit map of call waiting features. The bit
0x01
Call waiting
0x02
Caller ID announcement
0x04..0x80
Not used
(1 byte)
Call progress or transfer features: This attribute is a bit map of call processing features.
The bit value 0 disables the feature; 1 enables it.
0x0001
3way
0x0002
Call transfer
0x0004
Call hold
0x0008
Call park
0x0010
Do not disturb
0x0020
Flash on emergency service call (flash is to be
processed during an emergency service call)
0x0040
Emergency service originating hold (determines
whether call clearing is to be performed on on-hook
during an emergency service call)
0x0080
6way
0x0100..0x8000 Not used
The recommended default value is 0x0000. (R, W, Set-by-create)
Call presentation features: This attribute is a bit map of call presentation features. The bit
0x0001
Message waiting indication splash ring
0x0002
Message waiting indication special dial tone
0x0004
Message waiting indication visual indication
0x0008
Call forwarding indication
320
Rec. ITU-T G.988 (10/2012)
0x0010..0x8000
Not used
The recommended default value is 0x0000. (R, W, Set-by-create)

Direct connect feature: This attribute is a bit map of characteristics associated with the
direct connect feature. The bit value 0 disables the feature; 1 enables it.
0x01
Direct connect feature enabled
0x02
Dial tone feature delay option
(1 byte)
Direct connect URI pointer: This attribute points to a network address managed entity that
specifies the URI of the direct connect. If this attribute is set to a null pointer,
no URI is defined. (R, W, Set-by-create) (mandatory) (2 bytes)
Bridged line agent URI pointer: This attribute points to a network address managed entity
that specifies the URI of the bridged line agent. If this attribute is set to a null
pointer, no URI is defined. (R, W, Set-by-create) (mandatory) (2 bytes)
Conference factory URI pointer: This attribute points to a network address managed entity
that specifies the URI of the conference factory. If this attribute is set to a
null pointer, no URI is defined. (R, W, Set-by-create) (mandatory) (2 bytes)
Actions
Notifications
None.
9.9.9
The VoIP feature access codes managed entity defines administrable feature access codes for the
VoIP subscriber. It is optional for ONUs that support VoIP services. If a non-OMCI interface is
used to manage VoIP signalling, this ME is unnecessary.
Instances of this managed entity are created and deleted by the OLT. A VoIP feature access codes
instance is needed for each unique set of feature access code attributes.
Relationships
An instance of this managed entity may be associated with one or more SIP user data
managed entities.
Attributes
The remaining attributes are access codes for the features mentioned in their names. Each attribute
is a string of characters from the set {0..9, *, #}, with trailing nulls in any unused bytes.
Cancel call waiting:
Call hold:
Call park:
Caller ID activate:
Caller ID deactivate:
Rec. ITU-T G.988 (10/2012)
321
Do not disturb activation:
Do not disturb deactivation:
Do not disturb PIN change:
Emergency service number:
Intercom service:
Unattended/blind call transfer: (R, W) (optional) (5 bytes)

Attended call transfer:
Actions
Notifications
None.
9.9.10 Network dial plan table
The network dial plan table ME is optional for ONUs providing VoIP services. This ME is used to
provision dial plans from the OLT. Instances of this managed entity are created and deleted by the
OLT. If a non-OMCI interface is used to manage SIP for VoIP, this ME is unnecessary.
Relationships
An instance of this managed entity may be associated with one or more instances of the SIP
user data managed entity.
Attributes
Dial plan number: This attribute indicates the current number of dial plans in the dial plan
table. (R) (mandatory) (2 bytes)
Dial plan table max size: This attribute defines the maximum number of dial plans that can
be stored in the dial plan table. (R, Set-by-create) (mandatory) (2 bytes)
Critical dial timeout: This attribute defines the critical dial timeout for digit map
processing, in milliseconds. The recommended default value is 4'000 ms.
Partial dial timeout: This attribute defines the partial dial timeout for digit map processing,
in milliseconds. The recommended default value is 16'000 ms. (R, W,
Dial plan format: This attribute defines the dial plan format standard that is supported in
the ONU for VoIP. Valid values include:
0 Not defined
1 ITU-T H.248 format with a specific plan (table entries define the
dialling plan)
2 NCS format [b-PKT-SP-EC-MGCP]
3 Vendor-specific format
322
Rec. ITU-T G.988 (10/2012)
Dial plan table: The table is the digit map that describes the dial plans used by the VoIP
service, along with fields to manage the table. An example digit map is the
string,
(0T|00T|[1-7]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x.T)
Each row of the table comprises the following fields:

Dial plan ID: The row number, a unique identifier of a dial plan within
the dial plan table (1 byte).
Action: Remove (0) or add (1) this plan (set action). When a dial plan is
being removed, the dial plan token field is not used. (1 byte).
Dial plan token: The definition of the dial plan itself. In the previous
example, tokens include the strings "0T" and "*xx". Unused trailing
bytes may be padded with nulls or ASCII spaces. (28 bytes)
NOTE Due to previously ambiguous documentation, implementations may vary.
For interoperability, the OLT should write table entries as documented above, while
it is encouraged for the ONU to accept any characters outside the formal grammar as
delimiters, and to accept the concatenation of rows as a single string that defines a
digit map.
(R, W) (mandatory) (30 * N bytes, where N is the number of dial plans)

Actions
Notifications
None.
9.9.11 VoIP line status
The VoIP line status managed entity contains line status information for POTS ports using VoIP
services. An ONU that supports VoIP automatically creates or deletes an instance of this managed
entity upon creation or deletion of a PPTP POTS UNI.
Relationships
An instance of this managed entity is associated with a PPTP POTS UNI.
Attributes
instance of the physical path termination point POTS UNI. (R) (mandatory)
(2 bytes)
Voip codec used: Reports the current codec used for a VoIP POTS port. Valid values are
taken from [IETF RFC 3551], and are the same as specified in the codec
selection attribute of the VoIP media profile. This attribute is meaningful
only if the VoIP port session type attribute is not idle.
0 PCMU
1 reserved
2 reserved
3 GSM
4 ITU-T G.723
5 DVI4, 8 kHz
6 DVI4, 16 kHz
Rec. ITU-T G.988 (10/2012)
323
7
8
9
10
11
12
13
14
15
16
17
18
LPC
PCMA
ITU-T G.722
L16, 2 channels
L16, 1 channel
QCELP
CN
MPA
ITU-T G.728
DVI4, 11.025 kHz
DVI4, 22.050 kHz
ITU-T G.729

Voip voice server status: Status of the VoIP session for this POTS port:
0 None/initial
1 Registered
2 In session
3 Failed registration icmp error
4 Failed registration failed tcp
5 Failed registration failed authentication
6 Failed registration timeout
7 Failed registration server fail code
8 Failed invite icmp error
9 Failed invite failed tcp
10 Failed invite failed authentication
11 Failed invite timeout
12 Failed invite server fail code
13 Port not configured
14 Config done
15 Disabled by switch
Voip port session type: This attribute reports the current state of a VoIP POTS port session:
0 Idle/none
1 2way
2 3way
3 Fax/modem
4 Telemetry
5 Conference
Voip call 1 packet period: This attribute reports the packet period for the first call on the
VoIP POTS port. The value is defined in milliseconds. (R) (mandatory)
(2 bytes)
Voip call 2 packet period: This attribute reports the packet period for the second call on the
VoIP POTS port. The value is defined in milliseconds. (R) (mandatory)
(2 bytes)
Voip call 1 dest addr: This attribute reports the destination address for the first call on the
VoIP POTS port. The value is an ASCII string. (R) (mandatory) (25 bytes)
324
Rec. ITU-T G.988 (10/2012)
Voip call 2 dest addr: This attribute reports the destination address for the second call on
the VoIP POTS port. The value is an ASCII string. (R) (mandatory)
(25 bytes)
Voip line state: This attribute reports the state of the POTS line. This attribute may not be
meaningful if the POTS port is administratively locked, is operationally
disabled, or is being tested. Code points are assigned as follows:
0 Idle, on-hook
1 Off-hook dial tone
2 Dialling
3 Ringing or FSK alerting/data
4 Audible ringback
5 Connecting
6 Connected
7 Disconnecting, audible indication
8 Receiver off hook (ROH), no tone
9 ROH with tone
10 Unknown or undefined
Emergency call status: This attribute reports the current state of an emergency call session
(when the ONU is the call originator) on the VoIP POTS port. The ONU
determines the presence of an originating emergency call on the basis of the
Emergency service number attribute of the VoIP feature access codes ME.
0 No emergency call in progress
1 Emergency call in progress
NOTE The ONU may also be able to determine the presence of an emergency call
on the basis of other, unspecified information.
(R) (Optional) (1 byte)

Actions
Get
Notifications
Number
1..8
9
10..16
Description
N/A
Emergency call status
Indicates an update to the Emergency call status attribute
Reserved
9.9.12 Call control performance monitoring history data

This managed entity collects performance monitoring data related to the call control channel.
Relationships
An instance of this managed entity is associated with an instance of the PPTP POTS UNI
managed entity.
Rec. ITU-T G.988 (10/2012)
325
Attributes
instance of the PPTP POTS UNI. (R, Set-by-create) (mandatory) (2 bytes)
Call setup failures: This attribute counts call set-up failures. (R) (mandatory) (4 bytes)
Call setup timer: This attribute is a high water-mark that records the longest duration of a
single call set-up detected during this interval. Time is measured in
milliseconds from the time an initial set-up was requested by the subscriber
until the time at which a response was provided to the subscriber in the form
of busy tone, audible ring tone, etc. (R) (mandatory) (4 bytes)
Call terminate failures: This attribute counts the number of calls that were terminated with
cause. (R) (mandatory) (4 bytes)
Analog port releases: This attribute counts the number of analogue port releases without
dialling detected (abandoned calls). (R) (mandatory) (4 bytes)
Analog port off-hook timer: This attribute is a high water-mark that records the longest
period of a single off-hook detected on the analogue port. Time is measured
in milliseconds. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
CCPM call set-up fail
CCPM set-up timeout
CCPM call terminate
CCPM port release with no

dialling
CCPM port offhook timeout
9.9.13 RTP performance monitoring history data

This managed entity collects performance monitoring data related to an RTP session. Instances of
this managed entity are created and deleted by the OLT.
326
Rec. ITU-T G.988 (10/2012)
Relationships
An instance of this managed entity is associated with an instance of the PPTP POTS UNI
managed entity.
Attributes
instance of the PPTP POTS UNI ME. (R, Set-by-create) (mandatory)
(2 bytes)
RTP errors: This attribute counts RTP packet errors. (R) (mandatory) (4 bytes)
Packet loss:
This attribute represents the fraction of packets lost. This attribute is

calculated at the end of the 15-minute interval, and is undefined under the get
current data action. The value 0 indicates no packet loss, scaling linearly to
0xFFFF FFFF to indicate 100% packet loss (zero divided by zero is defined
to be zero). (R) (mandatory) (4 bytes)
Maximum jitter: This attribute is a high water-mark that represents the maximum jitter
identified during the measured interval, expressed in RTP timestamp units.
Maximum time between RTCP packets: This attribute is a high water-mark that
represents the maximum time between RTCP packets during the measured
interval, in milliseconds. (R) (mandatory) (4 bytes)
Buffer underflows: This attribute counts the number of times the reassembly buffer
underflows. In case of continuous underflow caused by a loss of IP packets, a
single buffer underflow should be counted. If the interworking function is
implemented with multiple buffers, such as a packet level buffer and a bit
level buffer, then the underflow of either buffer increments this counter. (R)
Buffer overflows: This attribute counts the number of times the reassembly buffer
overflows. If the interworking function is implemented with multiple buffers,
such as a packet level buffer and a bit level buffer, then the overflow of either
buffer increments this counter. (R) (mandatory) (4 bytes)
Actions
Rec. ITU-T G.988 (10/2012)
327
Notifications
Alarm
number
Threshold value attribute # (Note 2)
RTP errors
Packet loss(Note 1)
Maximum jitter
Max time between RTCP packets
Buffer underflows
Buffer overflows
NOTE 1 Since packet loss is undefined until the end of the interval, this TCA may only be issued
at the interval boundary, whereupon it is then immediately cleared.
NOTE 2 This number associates the TCA with the specified threshold value attribute of the
9.9.14 SIP agent performance monitoring history data

This managed entity collects performance monitoring data for the associated VoIP SIP agent.
Relationships
An instance of this managed entity is associated with a SIP agent config data or SIP config
portal object.
Attributes
instance of the corresponding SIP agent config data or to the SIP config
portal. If a non-OMCI configuration method is used for VoIP, there can be
only one live managed entity instance, associated with the SIP config portal,
and with managed entity ID 0. (R, Set-by-create) (mandatory) (2 bytes)
Transactions: This attribute counts the number of new transactions that were initiated. (R)
Rx invite reqs: This attribute counts received invite messages, including retransmissions.
Rx invite retrans: This attribute counts received invite retransmission messages. (R)
Rx noninvite reqs: This attribute counts received non-invite messages, including
retransmissions. (R) (optional) (4 bytes)
328
Rec. ITU-T G.988 (10/2012)
Rx noninvite retrans: This attribute counts received non-invite retransmission messages.

Rx response: This attribute counts total responses received. (R) (optional) (4 bytes)
Rx response retransmissions: This attribute counts total response retransmissions received.
Tx invite reqs: This attribute counts transmitted invite messages, including retransmissions.
Tx invite retrans: This attribute counts transmitted invite retransmission messages. (R)
Tx noninvite reqs: This attribute counts transmitted non-invite messages, including
retransmissions. (R) (optional) (4 bytes)
Tx noninvite retrans: This attribute counts transmitted non-invite retransmission messages.
Tx response: This attribute counts the total responses sent. (R) (optional) (4 bytes)
Tx response retransmissions: This attribute counts total response retransmissions sent. (R)
Actions
Notifications
Alarm
number
SIPAMD rx invite req
SIPAMD rx invite req retransmission
SIPAMD rx noninvite req
SIPAMD rx noninvite req

retransmission
SIPAMD rx response
SIPAMD rx response retransmission
9.9.15 SIP call initiation performance monitoring history data

This managed entity collects performance monitoring data related to call initiations of a VoIP SIP
agent. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an instance of the SIP agent config
data or SIP config portal ME.
Rec. ITU-T G.988 (10/2012)
329
Attributes
instance of the SIP agent config data or the SIP config portal ME. If a
non-OMCI configuration method is used for VoIP, there can be only one live
managed entity instance, associated with the SIP config portal, and with
managed entity ID 0. (R, Set-by-create) (mandatory) (2 bytes)
Failed to connect counter: This attribute counts the number of times that the SIP UA failed
to reach/connect its TCP/UDP peer during SIP call initiations. (R)
Failed to validate counter: This attribute counts the number of times that the SIP UA failed
to validate its peer during SIP call initiations. (R) (mandatory) (4 bytes)
Timeout counter: This attribute counts the number of times that the SIP UA timed out
during SIP call initiations. (R) (mandatory) (4 bytes)
Failure received counter: This attribute counts the number of times that the SIP UA
received a failure error code during SIP call initiations. (R) (mandatory)
(4 bytes)
Failed to authenticate counter: This attribute counts the number of times that the SIP UA
failed to authenticate itself during SIP call initiations. (R) (mandatory)
(4 bytes)
Actions
Notifications
Alarm
number
SIP call PM failed connect
SIP call PM failed to validate
SIP call PM timeout
SIP call PM failure error code received
SIP call PM failed to authenticate
330
Rec. ITU-T G.988 (10/2012)
9.9.16 MGC config data

The MGC config data ME defines the media gateway controller configuration associated with an
MG subscriber. It is conditionally required for ONUs that support ITU-T H.248 VoIP services. If a
non-OMCI interface is used to manage VoIP signalling, this ME is unnecessary.
Relationships
An instance of this managed entity may be associated with one or more VoIP voice CTP
managed entities.
Attributes
Primary MGC: This attribute points to a network address ME that contains the name (IP
address or resolved name) of the primary MGC that controls the signalling
messages. The port is optional and defaults to 2944 for text message formats
and 2955 for binary message formats. (R, W, Set-by-create) (mandatory)
(2 bytes)
Secondary MGC: This attribute points to a network address ME that contains the name (IP
address or resolved name) of the secondary or backup MGC that controls the
signalling messages. The port is optional and defaults to 2944 for text
message formats and 2955 for binary message formats. (R, W, Set-by-create)
TCP/UDP pointer: This attribute points to the TCP/UDP config data ME to be used for
communication with the MGC. (R, W, Set-by-create) (mandatory) (2 bytes)
Version:
This integer attribute reports the version of the Megaco protocol in use. The
ONU should deny an attempt by the OLT to set or create a value that it does
not support. The value 0 indicates that no particular version is specified.
Message format: This attribute defines the message format. Valid values are:
0 Text long
1 Text short
2 Binary
The default value is recommended to be 0. (R, W, Set-by-create) (mandatory)
(1 byte)
Maximum retry time: This attribute specifies the maximum retry time for MGC
transactions, in seconds. The default value 0 specifies vendor-specific
implementation. (R, W) (optional) (2 bytes)
Maximum retry attempts: This attribute specifies the maximum number of times a
message is retransmitted to the MGC. The recommended default value 0
specifies vendor-specific implementation. (R, W, Set-by-create) (optional)
(2 bytes)
Service change delay: This attribute specifies the service status delay time for changes in
line service status. This attribute is specified in seconds. The default value 0
specifies no delay. (R, W) (optional) (2 bytes)
Termination ID base: This attribute specifies the base string for the ITU-T H.248 physical
termination id(s) for this ONU. This string is intended to uniquely identify an
Rec. ITU-T G.988 (10/2012)
331
ONU. Vendor-specific termination identifiers (port IDs) are optionally added

to this string to uniquely identify a termination on a specific ONU. (R, W)
Softswitch:
This attribute identifies the gateway softswitch vendor. The format is four
ASCII coded alphabetic characters [A..Z] as defined in [ATIS-0300220]. A
value of four null bytes indicates an unknown or unspecified vendor. (R, W,
Message ID pointer: This attribute points to a large string whose value specifies the
message identifier string for ITU-T H.248 messages originated by the ONU.
Actions
Notifications
Alarm
Alarm
number
Alarm
Timeout
1..207
Reserved
208..223
Description
Timeout of association with MG
9.9.17 MGC performance monitoring history data

The MGC monitoring data managed entity provides run-time statistics for an active MGC
association. Instances of this managed entity are created and deleted by the OLT.
Relationships
An instance of this managed entity is associated with an instance of the MGC config data or
MGC config portal ME.
Attributes
instance of the associated MGC config data or to the MGC config portal ME.
If a non-OMCI configuration method is used for VoIP, there can be only one
live managed entity instance, associated with the MGC config portal, and
with managed entity ID 0. (R, Set-by-create) (mandatory) (2 bytes)
Received messages: This attribute counts the number of received Megaco messages on this
association, as defined by [ITU-T H.341]. (R) (mandatory) (4 bytes)
Received octets: This attribute counts the total number of octets received on this
332
Rec. ITU-T G.988 (10/2012)
Sent messages: This attribute counts the total number of Megaco messages sent over this
Sent octets:
This attribute counts the total number of octets sent over this association, as
defined by [ITU-T H.341]. (R) (mandatory) (4 bytes)
Protocol errors: This attribute counts the total number of errors detected on this
association, as defined by [ITU-T H.341]. This includes:
syntax errors detected in a given received message;
outgoing transactions that failed for protocol reasons.

Transport losses: This attribute counts the total number of transport losses (for example,
socket problems) detected on this association. A link loss is defined as loss of
communication with the remote entity due to hardware/transient problems, or
problems in related software. (R) (mandatory) (4 bytes)
Last detected event: This attribute reports the last event detected on this association. This
includes events such as the link failing or being set up. Under normal
circumstances, a get action on this attribute would return 0 to indicate no
abnormal activity. This field is an enumeration:
0
No event No event has yet been detected during this PM interval.
1
Link up The transport link underpinning the association came up.
2
Link down The transport link underpinning the association went
down.
3
Persistent error A persistent error was detected on the link (such
as the socket/TCP connection to the remote node could not be set
up).
4
Local shutdown The association was brought down intentionally
by the local application.
5
Failover down The association was brought down as part of
failover processing.
255 Other event The latest event does not match any in the list.
Last detected event time: This attribute reports the time in seconds since the last event on
this association was detected, as defined by [ITU-T H.341]. (R) (mandatory)
(4 bytes)
Last detected reset time: This attribute reports the time in seconds since these statistics
were last reset, as defined by [ITU-T H.341]. Under normal circumstances, a
get action on this attribute would return 900 seconds to indicate a completed
15-minute interval. (R) (mandatory) (4 bytes)
Actions
Rec. ITU-T G.988 (10/2012)
333
Notifications
Alarm
number
Threshold crossing
alert
MGCP protocol errors
MGCP transport
losses
9.9.18 VoIP config data

The VoIP configuration data managed entity defines the configuration for VoIP in the ONU. The
OLT uses this ME to discover the VoIP signalling protocols and configuration methods supported
by this ONU. The OLT then uses this ME to select the desired signalling protocol and configuration
method. The entity is conditionally required for ONUs that offer VoIP services.
An ONU that supports VoIP services automatically creates an instance of this managed entity.
Relationships
One instance of this managed entity is associated with the ONU.
Attributes
Available signalling protocols: This attribute is a bit map that defines the VoIP signalling
protocols supported in the ONU. The bit value 1 specifies that the ONU
supports the associated protocol.
1 (LSB) SIP
2
ITU-T H.248
3
MGCP
Signalling protocol used: This attribute specifies the VoIP signalling protocol to use. Only
one type of protocol is allowed at a time. Valid values are:
0
None
1
SIP
2
ITU-T H.248
3
MGCP
0xFF Selected by non-OMCI management interface
Available VoIP configuration methods: This attribute is a bit map that indicates the
capabilities of the ONU with regard to VoIP service configuration. The bit
value 1 specifies that the ONU supports the associated capability.
1 (LSB) ONU capable of using the OMCI to configure its VoIP services.
2
ONU capable of working with configuration file retrieval to
configure its VoIP services.
3
ONU capable of working with [BBF TR-069] to configure its
VoIP services.
4
ONU capable of working with IETF sipping config framework
to configure its VoIP services.
334
Rec. ITU-T G.988 (10/2012)
Bits 5..24 are reserved by ITU-T. Bits 25..32 are reserved for proprietary
vendor configuration capabilities. (R) (mandatory) (4 bytes)
VoIP configuration method used: Specifies which method is used to configure the ONU's
VoIP service.
0
Do not configure ONU default
1
OMCI
2
Configuration file retrieval
3
Broadband Forum TR-069
4
IETF sipping config framework
5..240
Reserved by ITU-T
241..255 Reserved for proprietary vendor configuration methods
VoIP configuration address pointer: If this attribute is set to any value other than a null
pointer, it points to a network address managed entity, which indicates the
address of the server to contact using the method indicated in the VoIP
configuration method used attribute. This attribute is only relevant for nonOMCI configuration methods.
If this attribute is set to a null pointer, no address is defined by this attribute.
However, the address may be defined by other methods, such as deriving it
from the ONU identifier attribute of the IP host config data ME and using a
well-known URI schema.
The default value is 0xFFFF (R, W) (mandatory) (2 bytes)
VoIP configuration state: Indicates the status of the ONU VoIP service.
0 Inactive: configuration retrieval has not been attempted
1 Active: configuration was retrieved
2 Initializing: configuration is now being retrieved
3 Fault: configuration retrieval process failed
Other values are reserved. At ME instantiation, the ONU sets this attribute to
0. (R) (mandatory) (1 byte)
Retrieve profile: This attribute provides a means by which the ONU may be notified that a
new VoIP profile should be retrieved. By setting this attribute, the OLT
triggers the ONU to retrieve a new profile. The actual value in the set action
is ignored because it is the action of setting that is important. (W)
Profile version: This attribute is a character string that identifies the version of the last
retrieved profile. (R) (mandatory) (25 bytes)
Actions
Get, set
Notifications
Number
1..7
8
9..16
Description
N/A
Profile version
Version of last retrieved profile
Reserved
Rec. ITU-T G.988 (10/2012)
335
Alarm
Alarm
number
Alarm
Description
VCD config server name
Failed to resolve the configuration server name.
VCD config server reach
Cannot reach configuration server (the port cannot be

VCD config server connect
Cannot connect to the configuration server (due to bad

VCD config server validate
Cannot validate the configuration server
VCD config server auth
Cannot authenticate the configuration session (e.g.,

missing credentials)
VCD config server timeout
Timeout waiting for response from configuration server
VCD config server fail
Failure response received from configuration server
VCD config file error
Configuration file received has an error
VCD subscription name
Failed to resolve the subscription server name
VCD subscription reach
Cannot reach subscription server (the port cannot be

10
VCD subscription connect
Cannot connect to subscription server (due to bad

11
VCD subscription validate
Cannot validate subscription server
12
VCD subscription auth
Cannot authenticate subscription session (e.g., missing

credentials)
13
VCD subscription timeout
Timeout waiting for response from subscription server
14
VCD subscription fail
Failure response received from subscription server
15
VCD reboot request
A non-OMCI management interface has requested a

reboot of the ONU.
NOTE This alarm is used only to indicate the request
and not to indicate that a reboot has actually taken place.
16..207
Reserved
208..223
9.9.19 SIP config portal

The SIP config portal managed entity provides a way for the OLT to discover the configuration text
delivered to an ONU by a non-OMCI SIP VoIP configuration method ([BBF TR-069], sipping
framework, etc.). Text retrieved from this ME is not required to be understood by the OLT or EMS,
but it may be useful for human or vendor-specific analysis tools. See also the MGC config portal
ME.
An instance of this managed entity may be created by an ONU that supports non-OMCI SIP
configuration. It is not reported during a MIB upload.
Relationships
Attributes
There is one instance, number 0. (R) (mandatory) (2 bytes)
336
Rec. ITU-T G.988 (10/2012)
Configuration text table: This attribute is used to pass a textual representation of the VoIP
configuration back to the OLT. The contents are vendor-specific. The get, get
next sequence must be used with this attribute since its size is unspecified.
(x bytes)
Actions
Get, get next
Notifications
Attribute value
change
Number
1
2..16
Configuration text
Description
Indicates an update to the VoIP configuration from a nonOMCI interface. Because the attribute is a table, the AVC
does not contain information about its value. The OLT must
use the get, get next action sequence if it wishes to obtain the
updated attribute content.
Reserved
9.9.20 MGC config portal

The MGC (media gateway controller) config portal managed entity provides a way for the OLT to
discover the configuration text delivered to an ONU by a non-OMCI ITU-T H.248 VoIP
configuration method. Text retrieved from this ME is not required to be understood by the OLT or
EMS, but it may be useful for human or vendor-specific analysis tools. See also the SIP config
portal ME.
An instance of this managed entity may be created by an ONU that supports non-OMCI
ITU-T H.248 configuration. It is not reported during a MIB upload.
Relationships
Attributes
There is one instance, number 0. (R, Set-by-create) (mandatory) (2 bytes)
Configuration text table: This attribute is used to pass a textual representation of the VoIP
Upon ME instantiation, the ONU sets this attribute to 0. (R) (mandatory) (x
bytes)
Actions
Get, get next
Rec. ITU-T G.988 (10/2012)
337
Notifications
Number
1
2..16
9.10

Configuration text
Description
Indicates an update to the VoIP configuration from a nonOMCI interface. Because the attribute is a table, the AVC
does not contain information about its value. The OLT must
use the get, get next action sequence if it wishes to obtain the
updated attribute content.
Reserved
Premises networks
This clause defines managed entities associated with home networking UNIs, as shown in
Figure 9.10-1.
MoCA
Ethernet PM
history data
Pointed to by:
(Extended)VLAN tagging operation config data
PPTP
MoCA UNI
9.10.2
9.10.1
MoCA
interface PM
history data
9.10.3
G.988(12)_F9.10-1
Figure 9.10-1 Managed entities associated with home networking

9.10.1 Physical path termination point MoCA UNI
This managed entity represents an MoCA UNI, where physical paths terminate and physical path
level functions are performed.
when the ONU has MoCA ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the MoCA type;
MoCA type. Note that the installation of a plug-and-play card may indicate the presence of
MoCA ports via equipment ID as well as its type, and indeed may cause the ONU to
instantiate a port mapping package that specifies MoCA ports.
provisioned to expect an MoCA circuit pack, nor is it equipped with an MoCA circuit pack.
Relationships
An instance of this managed entity is associated with each real or pre-provisioned MoCA
port.
Attributes
This two-byte number is directly associated with the physical position of the
UNI. The first byte is the slot ID (defined in clause 9.1.5). The second byte is
the port ID, with the range 1..255. (R) (mandatory) (2 bytes)
338
Rec. ITU-T G.988 (10/2012)
Loopback configuration: This attribute sets the MoCA loopback configuration. Note that
normal bridge behaviour may defeat the loopback signal unless broadcast
MAC addresses are used.
0 No loopback
3 Loopback3, loopback of downstream traffic after PHY transceiver,
depicted in Figure 9.10.1-1.
Upon ME instantiation, the ONU sets this attribute to 0. (R, W) (optional)
(1 byte)
ONU
MoCA UNI
PHY
transceiver
PON
Loopback 3
G.988(12)_F9.10.1-1
Figure 9.10.1-1 MoCA loopback configuration

(optional) (1 byte)
Max frame size: This attribute denotes the maximum frame size allowed across this
interface. Upon ME instantiation, the ONU sets this attribute to 1518. (R, W)
ARC:

PPPoE filter: This attribute controls filtering of PPPoE packets on this MoCA port. When
its value is 1, all packets other than PPPoE packets are discarded. The default
0 accepts packets of all types. (R, W) (optional) (1 byte)
Network status: This attribute indicates the networking state of the MoCA interface.
0 The interface has not joined an MoCA network.
1 The interface has joined an MoCA network.
2 The interface has joined an MoCA network and is currently the
network coordinator.
Password:
This attribute specifies the MoCA encryption key. It is an ASCII string of 17

decimal digits. Upon ME instantiation, the ONU sets this attribute to 17 null
bytes. (R, W) (mandatory) (17 bytes)
Privacy enabled: This attribute activates (1) link-layer security. The default value 0
deactivates it. (R, W) (mandatory) (1 byte)
Minimum bandwidth alarm threshold: This attribute specifies the minimum desired PHY
link bandwidth between two nodes. If the actual bandwidth is lower, a limited
link alarm is declared. Valid values are 0 to 0x0410 (260 Mbit/s) in
0.25-Mbit/s increments. The default value is 0x02D0 (180 Mbit/s). The value
0 disables the threshold. (R, W) (optional) (2 bytes)
Rec. ITU-T G.988 (10/2012)
339
Frequency mask: This attribute is a bit map of the centre frequencies that the interface is
permitted to use, where each bit represents a centre frequency. The least
significant bit (b[1]) corresponds to centre frequency 800 MHz. The next
significant bit (b[2]) corresponds to centre frequency 825 MHz. The 28th bit
(b[28]) corresponds to centre frequency 1500 MHz. The 4 most significant
bits are not used. (R, W) (optional) (4 bytes)
RF channel: This attribute reports the frequency to which the MoCA interface is currently
tuned, in MHz. (R) (mandatory) (2 bytes)
Last operational frequency: This attribute reports the frequency to which the MoCA
interface was tuned when last operational, in MHz. (R) (mandatory) (2 bytes)
Actions
Get, set
Notifications
Number
1..2
Description
N/A
Op state
N/A
ARC
6..14
N/A
15..16
Reserved
Operational state
Alarm
Alarm number
Alarm
Description
MoCA loss of link (LOL)
Loss of link at the MoCA interface
MoCA limited link (LL)
Bandwidth of link between two nodes on the

MoCA network is less than the specified value
2..207
208..223
Reserved
9.10.2 MoCA Ethernet performance monitoring history data

This managed entity collects performance monitoring data for an MoCA Ethernet interface.
Relationships
An instance of this managed entity is associated with an instance of the PPTP MoCA UNI
managed entity.
Attributes
instance of the physical path termination point MoCA UNI. (R,
340
Rec. ITU-T G.988 (10/2012)
Incoming PM refers to upstream traffic received on the UNI; outgoing PM refers to downstream
traffic transmitted on the UNI.
Incoming unicast packets:
Incoming discarded packets:
Incoming errored packets:
Incoming unknown packets:
Incoming multicast packets:
Incoming broadcast packets:
Incoming octets:
Outgoing unicast packets:
Outgoing discarded packets:
Outgoing errored packets:
Outgoing unknown packets:
Outgoing multicast packets:
Outgoing broadcast packets:
Outgoing octets:

Actions
Notifications
Alarm
number
Incoming unicast packets
Incoming discarded packets
Incoming errored packets
Incoming unknown packets
Incoming multicast packets
Incoming broadcast packets
Incoming octets
Outgoing unicast packets
Outgoing discarded packets
Outgoing errored packets
10
10
Outgoing unknown packets
11
11
Outgoing multicast packets
12
12
Outgoing broadcast packets
13
13
Outgoing octets
14
Rec. ITU-T G.988 (10/2012)
341
9.10.3 MoCA interface performance monitoring history data

This managed entity collects performance monitoring data for an MoCA interface. Instances of this
NOTE The structure of this ME is an exception to the normal definition of PM MEs and normal PM
behaviour (clause I.4). It should not be used as a guide for the definition of future MEs. Among other
exceptions, this managed entity contains only current values, which are retrievable by get and get next
operations; no history is retained.
Relationships
An instance of this managed entity is associated with an instance of the PPTP MoCA UNI
managed entity.
Attributes
instance of the physical path termination point MoCA UNI. (R,
PHY tx broadcast rate: This attribute indicates the MoCA PHY broadcast transmit rate
from the ONU MoCA interface to all the nodes in bit/s. (R) (optional)
(4 bytes)
Node table:
342
This attribute lists current nodes in the node table. The table contains MAC
addresses and statistics for those nodes. These table attributes are further
described below. Space for non-supported optional fields must be allocated in
table records, and filled with zero bytes.
MAC address: A unique identifier of a node within the table. (6 bytes)
PHY tx rate: MoCA PHY unicast transmit rate from the ONU MoCA
interface to the node identified by the MAC address, in bit/s. (4 bytes)
Tx power control reduction: The reduction in transmitter level due to
power control, in dB. Valid values range from 0 (full power) to 60.
(1 byte)
PHY rx rate: MoCA PHY unicast receive rate to the ONU MoCA
interface from the node identified by the MAC address, in bit/s.
Rx power level: The power level received at the ONU MoCA interface
from the node identified by the MAC address, in dBm, represented as
a 2s complement integer. Valid values range from +10 (0x0A) to
80 (0xB0). (1 byte)
PHY rx broadcast rate: MoCA PHY broadcast receive rate to the ONU
MoCA interface from the node identified by MAC address, in bits/s.
Rec. ITU-T G.988 (10/2012)
Rx broadcast power level: The power level received at the ONU MoCA
interface from the node identified by the MAC address, in dBm,
represented as a 2s complement integer. Valid values range from
+10 (0x0A) to 80 (0xB0). (1 byte)
Tx packet: Number of packets transmitted to the node. (4 bytes)
Rx packet: Number of packets received from the node. (4 bytes)
Rx errored and missed: Number of errored and missed packets received
from the node. The sum of this field across all entries in the node
table contributes to the rx errored and missed TCA. This field is reset
to 0 on 15-minute boundaries. (4 bytes)
Rx errored: Number of errored packets received from the node. The sum
of this field across all entries in the node table contributes to the rx
errored TCA. This field is reset to 0 on 15-minute boundaries.
(R) (mandatory) (37 * N bytes, where N is the number of nodes in the node
table)
Actions
Notifications
Alarm
number
Total rx errored and missed
Total rx errored
9.11
9.12
General purpose MEs
9.12.1 UNI-G
This managed entity organizes data associated with user network interfaces (UNIs) supported by
GEM. One instance of the UNI-G managed entity exists for each UNI supported by the ONU.
The ONU automatically creates or deletes instances of this managed entity upon the creation or
deletion of a real or virtual circuit pack managed entity, one per port.
Relationships
An instance of the UNI-G managed entity exists for each instance of a physical path
termination point managed entity.
Attributes
instance of a physical path termination point. (R) (mandatory) (2 bytes)
Deprecated: This attribute is not used. It should be set to 0 by the OLT and ignored by the
ONU. (R, W) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
343
NOTE PPTP MEs also have an administrative state attribute. The user port is
unlocked only if both administrative state attributes are set to unlocked. It is
recommended that this attribute not be used: that the OLT set it to 0 and that the
ONU ignore it.
Management capability: An ONU may support the ability for some or all of its PPTPs to
be managed either directly by the OMCI or from a non-OMCI management
environment such as [BBF TR-069]. This attribute advertises the ONU's
capabilities for each PPTP.
This attribute is an enumeration with the following code points:
0 OMCI only
1 Non-OMCI only. In this case, the PPTP may be visible to the OMCI,
but only in a read-only sense, e.g., for PM collection.
2 Both OMCI and non-OMCI
Non-OMCI management identifier: If a PPTP can be managed either directly by the
OMCI or a non-OMCI management environment, this attribute specifies how
it is in fact to be managed. This attribute is either 0 (default = OMCI
management), or it is a pointer to a virtual Ethernet interface point, which in
turn links to a non-OMCI management environment. (R, W) (optional)
(2 bytes)
(2 bytes)
The contents of the large string are parsed by the ONU and converted into
text strings. Variable substitution is based on defined three-character groups,
each of which begins with the '%' character. The string '%%' is an escape
mechanism whose output is a single '%' character. When the ONU cannot
perform variable substitution on a substring of the large string, it generates
the specified option as an exact quotation of the provisioned substring value.
Provisioning of the large string is separate from the operation of setting the
pointer in this attribute. It is the responsibility of the OLT to ensure that the
large string contents are correct and meaningful.
Three-character variable definitions are as follows. The first variable in the
large string must specify one of the option types. Both options for a given IP
version may be present if desired, each introduced by its option identifier.
Terminology is taken from [b-BBF TR-101] clause 3.9.3.
%01,
%18
agent circuit-ID (IPv4) or option 18, interface-ID (IPv6). The
equivalence permits the same large string to be used in both IP
environments.
%02,
%37
relay agent remote-ID (IPv4) or option 37, relay agent
remote-ID (IPv6). The equivalence permits the same large string
to be used in both IP environments.
344
Rec. ITU-T G.988 (10/2012)
%SL
%SU
%PO
%AE
%SV
%CV
In TR-101, this is called a slot. In an ONU, this variable refers

to a shelf. It would be meaningful if the ONU has multiple
shelves internally or is daisy-chained to multiple equipment
modules. The range of this variable is "0".. "99"
In TR-101, this is called a sub-slot. In fact, it represents a
cardholder. The range of this variable is "0".. "99"
UNI port number. The range of this variable is "0".. "999"
ATM or Ethernet. This variable can take on the values "atm" or
"eth".
S-VID for Ethernet UNI, or ATM VPI for ATM UNI, as it
exists on the DHCP request received upstream across the UNI.
Range "0".. "4096" for S-VID; range "0".. "255" for VPI. The
value "4096" indicates no S-VID tag.
C-VID (Q-VID) for Ethernet UNI, or ATM VCI for ATM UNI,
as it exists on the DHCP request received upstream across the
UNI. Range "0".. "4096" for C-VID; range "0".."65535" for
VCI. The value "4096" indicates no C-VID tag.
Spaces in the provisioned string are significant.

Example: if the large string were provisioned with the value
%01%SL/%SU/%PO:%AE/%SV.%CV<null>,
then the ONU would generate the following DHCP option 82 agent
circuit-ID string for an Ethernet UNI that sent a DHCP request with no S tag
and C tag = 3210 on shelf 2, slot 3, port 4.
2/3/4:eth/4096.3210
With the same provisioning, the ONU would generate the following DHCP
option 82 agent circuit-ID string for an ATM UNI that sent a DHCP request
on VPI = 123 and VCI = 4567 on shelf 2, slot 3, port 4.
2/3/4:atm/123.4567
Actions
Get, set
Notifications
None.
9.12.2 OLT-G
This optional managed entity identifies the OLT to which an ONU is connected. This ME provides
a way for the ONU to configure itself for operability with a particular OLT. It also provides a way
for the OLT to communicate the time of day to the ONU.
An ONU that supports this managed entity automatically creates an instance of it. Immediately
following the start-up phase, the OLT should set the ONU to the desired configuration.
Interpretation of the OLT vendor ID, equipment ID and version attributes is a matter for negotiation
between the two vendors involved.
Relationships
The single instance of this managed entity is associated with the ONU managed entity.
Rec. ITU-T G.988 (10/2012)
345
Attributes
OLT vendor ID: This attribute identifies the OLT vendor. It is the same as the four most
significant bytes of an ONU serial number specified in [ITU-T G.984.3] and
[ITU-T G.987.3]. Upon instantiation, this attribute comprises all spaces.
Equipment ID: This attribute may be used to identify the specific type of OLT. The default
value of all spaces indicates that equipment ID information is not available or
applicable to the OLT being represented. (R, W) (mandatory) (20 bytes)
Version:
This attribute identifies the version of the OLT as defined by the vendor. The
default left-justified ASCII string "0" (padded with trailing nulls) indicates
that version information is not available or applicable to the OLT being
represented. (R, W) (mandatory) (14 bytes)
Time of day information: This attribute provides the information required to achieve time
of day synchronization between a reference clock at the OLT and a local
clock at the ONU. This attribute comprises two fields: the first field (4 bytes)
is the sequence number of the specified GEM superframe. The second field
(10 bytes) is TstampN as defined in clause 10.4.6 of [ITU-T G.984.3] and
clause 13.2 of [ITU-T G.987.3], using the timestamp format of [IEEE 1588],
clause 5.3.3. The value 0 in all bytes is reserved as a null value. (R, W)
NOTE In ITU-T G.987 systems, the superframe count field of the time of day
information attribute contains the 32 least significant bits of the actual counter.
Actions
Get, set
Notifications
None.
9.12.3 Network address
The network address managed entity associates a network address with security methods required to
access a server. It is conditionally required for ONUs that support VoIP services. The address may
take the form of a URL, a fully-qualified path or IP address represented as an ACII string.
If a non-OMCI interface is used to manage VoIP signalling, this ME is unnecessary.
Instances of this managed entity are created and deleted by the OLT or the ONU, depending on the
method used and case.
Relationships
Any managed entity that requires a network address may link to an instance of this ME.
Attributes
Instances of this managed entity created autonomously by the ONU have IDs
in the range 0..0x7FFF. Instances created by the OLT have IDs in the range
0x8000..0xFFFE. The value 0xFFFF is reserved. (R, Set-by-create)
346
Rec. ITU-T G.988 (10/2012)
Security pointer: This attribute points to an authentication security method managed entity.
The authentication security method indicates the username and password to
be used when retrieving the network address indicated by this ME. A null
pointer indicates that security attributes are not defined for this network
address. (R, W, Set-by-create) (mandatory) (2 bytes)
Address pointer: This attribute points to the large string ME that contains the network
address. It may contain a fully-qualified domain name, URI or IP address.
The URI may also contain a port identifier (e.g., "x.y.z.com:5060"). A null
pointer indicates that no network address is defined. (R, W, Set-by-create)
Actions
Notifications
None.
9.12.4 Authentication security method
The authentication security method defines the user id/password configuration to establish a session
between a client and a server. This object may be used in the role of the client or server. An instance
of this managed entity is created by the OLT if authenticated communication is necessary.
Relationships
One instance of this management entity may be associated with a network address ME. This
ME may also be cited by other MEs that require authentication parameter management.
Attributes
The value 0xFFFF is reserved. (R, Set-by-create) (mandatory) (2 bytes)
Validation scheme: This attribute specifies the validation scheme used when the ONU
validates a challenge. Validation schemes are defined as follows:
0 Validation disabled
1 Validate using MD5 digest authentication as defined in
[IETF RFC 2617] (recommended)
3 Validate using basic authentication as defined in [IETF RFC 2617]
Username 1: This string attribute is the user name. If the string is shorter than 25 bytes, it
must be null terminated (Note). (R, W) (mandatory) (25 bytes)
Password:
This string attribute is the password. If the string is shorter than 25 bytes, it
must be null terminated. (R, W) (mandatory) (25 bytes)
Realm:
This string attribute specifies the realm used in digest authentication. If the
string is shorter than 25 bytes, it must be null terminated. (R, W) (mandatory)
(25 bytes)
Username 2: This string attribute allows for continuation of the user name beyond
25 characters (Note). Its default value is a null string. (R, W) (optional)
(25 bytes)
NOTE The total username is the concatenation of the username 1 and username 2 attributes if and
only if a) username 1 comprises 25 non-null characters, b) username 2 is supported by the ONU, and
Rec. ITU-T G.988 (10/2012)
347
c) username 2 contains a leading non-null character string. Otherwise, the total username is simply
the value of the username 1 attribute.
Actions
Notifications
None.
9.12.5 Large string
The large string managed entity holds character strings longer than 25 bytes, up to 375 bytes. It is
maintained in up to 15 parts, each part containing 25 bytes. If the final part contains fewer than
25 bytes, it is terminated by at least one null byte. For example:
Number of parts
Part 1
3
sftp://myusername:mypassw
Part 2
[email protected]:12
Part 3
34/path/to/filename<null>
Number of parts
Part 1
3
sftp://myusername:mypassw
Part 2
[email protected]:12
Part 3
34/path/to/longfilename<null>
Or
Instances of this managed entity are created and deleted by the OLT. Under some circumstances,
they may also be created by the ONU. To use this managed entity, the OLT or ONU instantiates the
large string ME and then points to the created ME from other ME instances. Systems that maintain
the large string should ensure that the large string ME is not deleted while it is still linked.
Relationships
An instance of this ME may be cited by any ME that requires a text string longer than
25 bytes.
Attributes
The value 0xFFFF is reserved. When the large string is to be used as an IPv6
address, the value 0 is also reserved. The OLT should create large string MEs
starting at 1 (or 0), and numbering upwards. The ONU should create large
string MEs starting at 65534 (0xFFFE) and numbering downwards. (R,
Number of parts: This attribute specifies the number of non-empty parts that form the large
string. This attribute defaults to 0 to indicate no large string content is
defined.(R, W) (mandatory) (1 byte)
Fifteen additional attributes are defined below; they are identical. The large string is simply divided
into as many parts as necessary, starting at part 1. If the end of the string does not lie at a part
boundary, it is marked with a null byte.
Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9,
Part 10, Part 11, Part 12, Part 13, Part 14, Part 15: (R, W) (mandatory)
(25 bytes * 15 attributes)
348
Rec. ITU-T G.988 (10/2012)
Actions
Notifications
Number
Number of parts
Part 1
Part 2
Part 3
Part 4
Part 5
Part 6
Part 7
Part 8
10
Part 9
11
Part 10
12
Part 11
13
Part 12
14
Part 13
15
Part 14
16
Part 15
Description
NOTE Older implementations of the OMCI may not support this notification, which has been
9.12.6 Threshold data 1

Threshold data is partitioned into two MEs for historical reasons. An instance of this managed
entity, together with an optional instance of the threshold data 2 ME, contains threshold values for
counters in performance monitoring history data managed entities.
Relationships
An instance of this managed entity may be related to multiple instances of performance
monitoring history data type managed entities.
Paired instances of threshold data 1 ME and threshold data 2 ME are implicitly linked
together through a common ME ID.
Attributes
The following seven attributes specify threshold values for seven thresholded counters in associated
PM history data MEs. The definition of each PM history ME includes a table that links each
thresholded counter to one of these threshold value attributes.
Threshold value 1: (R, W, Set-by-create) (mandatory) (4 bytes)
Rec. ITU-T G.988 (10/2012)
349

Actions
Notifications
None.
9.12.7 Threshold data 2
Together with an instance of the threshold data 1 ME, an instance of this managed entity contains
threshold values for counters maintained in one or more instances of performance monitoring
history data managed entities.
Relationships
Refer to the relationships of the threshold data 1 ME.
Attributes
Its value is the same as that of the paired threshold data 1 instance. (R,
The following seven attributes specify threshold values for seven thresholded counters in associated
PM history data MEs. The definition of each PM history ME includes a table that links each
thresholded counter to one of these threshold value attributes.
Actions
Notifications
None.
350
Rec. ITU-T G.988 (10/2012)
9.12.8 OMCI
This managed entity describes the ONU's general level of support for OMCI managed entities and
messages. This ME is not included in a MIB upload.
Relationships
One instance exists in the ONU. The ME entities are related to the OMCI entity.
Attributes
ME type table: This attribute lists the ME classes supported by the ONU. Each entry
contains the managed entity class value (see Table 11.2.4-1) of a managed
entity type. (R) (mandatory) (2 * N bytes, where N is the number of entries in
the list.)
Message type table: This attribute is a list of message types supported by the ONU. Each
entry contains the message type of an OMCI message (see Table 11.2.2-1).
(R) (mandatory) (M bytes, where M is the number of entries in the list.)
Actions
Get, get next
Notifications
None.
9.12.9 Managed entity
The managed entity ME describes the details of each managed entity that is supported by the ONU.
This ME is not included in a MIB upload.
Relationships
One or more managed entity entities are related to the OMCI object entity.
Attributes
Its value is equal to the managed entity type value, and is the same as the
code found in the ME type table attribute of the OMCI ME and
Table 11.2.4-1. (R) (mandatory) (2 bytes)
Name:
This attribute contains a 25-byte ASCII coded mnemonic tag for the ME
type. Strings shorter than 25 bytes are padded with null characters. (R)
Attributes table: This table contains pointers to the attribute MEs that describe each of this
ME's attributes. (R) (mandatory) (2 * X bytes, where X is the number of
entries in the table.)
NOTE The managed entity ID attribute is not included in the list, since the type of
this attribute is fixed.
Access:
This attribute represents who creates this ME. The following code points are
defined:
1 Created by the ONU
2 Created by the OLT
3 Created by both the ONU and OLT
Rec. ITU-T G.988 (10/2012)
351

Alarms table: This attribute lists the alarm codes that are supported. (R) (mandatory) (Y
bytes, where Y is the number of entries in the table.)
AVCs table: This attribute lists the AVCs that are supported. (R) (mandatory) (Z bytes,
where Z is the number of entries in the table.)
Actions:
This attribute lists the action codes supported on this object, formatted as a
bit map. The action codes are the message types from Table 11.2.2-1. The
least significant bit represents action 0, and so on. (R) (mandatory) (4 bytes)
Instances table: This attribute is a list of pointers to all instances of this ME. (R)
(mandatory) (2 * V bytes, where V is the number of entries in the table.)
Support:
This attribute represents the support capability of this ME in the ONU's

implementation. This attribute does not declare whether the OMCI
implementation complies with the Recommendations, but whether it
complies with the OMCI declaration itself. The following code points are
defined:
1 Supported (supported as defined in this object)
2 Unsupported (OMCI returns error code if accessed)
3 Partially supported (some aspects of ME supported)
4 Ignored (OMCI supported, but underlying function is not)
Actions
Get, get next
Notifications
None.
9.12.10 Attribute
This managed entity describes a particular attribute type that is supported by the ONU. This ME is
not included in a MIB upload.
Relationships
One or more attribute entities are related to each ME entity. More than one ME entity can
refer to a given attribute entity.
Attributes
This number is the same as the one that appears in the attributes table in the
managed entity ME. Only one instance of each unique attribute need be
created. The ONU can assign attribute numbering as it pleases, out of the
pool of 64K ids; however, it is suggested that the numbering follow a rational
scheme to aid human readability. (R) (mandatory) (2 bytes)
352
Name:
This attribute contains a 25-byte mnemonic tag for the attribute. Strings
shorter than 25 bytes are padded with null characters. (R) (mandatory)
(25 bytes)
Size:
This attribute contains the size of the attribute, in bytes. The value 0 indicates
that the attribute can have a variable/unknown size. (R) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
Access:
This attribute represents the OMCI access characteristics of the attribute. The
following code points are defined:
1 Read
2 Write
3 Read, write
5 Read, Set-by-create
6 Write, Set-by-create
7 Read, write, Set-by-create
Format:
This attribute represents the format of the attribute. The following code
points are defined:
1 Pointer
2 Bit field
3 Signed integer
4 Unsigned integer
5 String
6 Enumeration (that is, a set of defined code points)
7 Table
Lower limit: This attribute provides the lowest value for the attribute. Valid for numeric
types (pointer, signed integer, unsigned integer) only. For attributes smaller
than four bytes, the desired numeric value is expressed in 4-byte
representation (for example, the 2s complement 1-byte integer 0xFE is
expressed as 0xFFFF FFFE; the unsigned 1-byte integer 0xFE is expressed as
0x0000 00FE). (R) (mandatory) (4 bytes)
Upper limit: This attribute provides the highest value for the attribute. It has the same
validity and format as the lower limit attribute. (R) (mandatory) (4 bytes)
Bit field:
This attribute is a mask of the supported bits in a bit field attribute, valid for
bit field type only. A 1 in any position signifies that its code point is
supported, while 0 indicates that it is not supported. For bit fields smaller
than four bytes, the attribute is aligned at the least significant end of the
mask. (R) (mandatory) (4 bytes)
Code points table: This attribute lists the code points supported by an enumerated attribute.
(R) (mandatory) (2 * Q bytes, where Q is the number of entries in the table.)
Support:
This attribute represents the level of support of the attribute (same notation as
the attribute of the same name in the managed entity ME). The following
code points are defined:
1 Fully supported (supported as defined in this object)
2 Unsupported (OMCI returns an error code if accessed)
3 Partially supported (some aspects of attribute supported)
4 Ignored (OMCI supported, but underlying function is not)
Actions
Get, get next
Notifications
None.
Rec. ITU-T G.988 (10/2012)
353
9.12.11 Octet string

The octet string is modelled on the large string managed entity. The large string is constrained to
printable characters because it uses null as a trailing delimiter. The octet string has a length attribute
and is therefore suitable for arbitrary sequences of bytes.
Instances of this managed entity are created and deleted by the OLT. To use this managed entity,
the OLT instantiates the octet string ME and then points to the created ME from other ME
instances. Systems that maintain the octet string should ensure that the octet string ME is not
deleted while it is still linked.
Relationships
An instance of this ME may be cited by any ME that requires an octet string that can exceed
25 bytes in length.
Attributes
(2 bytes)
Length:
This attribute specifies the number of octets that comprise the sequence of
octets. This attribute defaults to 0 to indicate no octet string is defined. The
maximum value of this attribute is 375 (15 parts, 25 bytes each). (R, W)
Fifteen additional attributes are defined below; they are identical. The octet string is simply divided
into as many parts as necessary, starting at part 1 and left justified.
Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9,
Part 10, Part 11, Part 12, Part 13, Part 14, Part 15:
(R, W) (part 1 mandatory, others optional) (25 bytes * 15 attributes)
Actions
Notifications
None.
9.12.12 General purpose buffer
This managed entity is created by the OLT when needed to store the results of an operation, such as
a test command, that needs to return a block of data of indeterminate size. The buffer is retrieved
with get next operations, since its size is not known a priori. An instance of this ME is created and
deleted by the OLT, and typically made known to an ONU ME or to an action through a pointer.
The ME is defined as generically as possible, such that it can be used for other applications that
may not initially be apparent, such as logging. The format of its content is specific to each
application, and is documented there.
The general purpose buffer is neither captured in a MIB upload, nor retained in a non-volatile ONU
memory.
Relationships
Through a pointer, the OLT may associate a general purpose buffer with an ME and/or an
operation that has a need to create large or indeterminate blocks of data for subsequent
upload.
354
Rec. ITU-T G.988 (10/2012)
Attributes
Maximum size: The ONU determines the actual size of the buffer table in the process of
capturing the data directed to it. The maximum size attribute permits the OLT
to restrict the maximum size of the buffer table. The value 0 indicates that the
OLT imposes no limit on the size; it is recognized that ONU implementations
will impose their own limits. The ONU will not create a buffer table larger
than the value of this attribute. If the ONU cannot allocate enough memory to
accommodate this size, it should deny the ME create action or a write
operation that attempts to expand an existing ME. (R, W, Set-by-create)
Buffer table: This attribute is an octet string that contains the result of some operation
performed on the ONU. The exact content depends on the operation, and is
documented with the definition of each operation. (R) (mandatory) (N bytes)
Actions
Create, delete, get, get next
Notifications
Number
Attribute value
change
N/A
Buffer table
3..16
Description
This AVC indicates that the ONU has completed writing the
buffer, and thereby signals to the OLT that the operation is
complete and the buffer is available for upload.
Reserved
9.12.13 File transfer controller

This optional managed entity allows file transfers to be conducted out of band. It is intended to
facilitate software image download, but may be used for other file transfer applications as well.
Relationships
One instance of this managed entity exists in an ONU that supports out-of-band file transfer.
Attributes
There is one instance, whose value is 0. (R) (mandatory) (2 bytes)
Supported transfer protocols: This attribute is a bit map. Each bit indicates that the
corresponding protocol is (1) or is not (0) supported for file transfers. TFTP
is mandatory; the other protocols are optional. (R) (mandatory) (2 bytes)
Bit
Protocol
1 (LSB) FTP
2
TFTP
SFTP
HTTP
Rec. ITU-T G.988 (10/2012)
355
File type:
HTTPS
FLUTE ([b-IETF RFC 3926]; multicast, download only)
DSM-CC (multicast, download only)
8..12
Reserved
13..16
Vendor-specific use; not to be standardized
This attribute specifies the owner managed entity type of the file to be
transferred. It is a value from Table 11.2.4-1. For example, for software
image download, this attribute has the value 7. File systems on circuit packs
are identified with the value 6, and on the ONU-G as a whole with the value
256. (R, W) (mandatory) (2 bytes)
File instance: This attribute specifies the instance of the file to be transferred. This attribute
is the same as the ME ID attribute of the owner ME. (R, W) (mandatory)
(2 bytes)
Local file name pointer: This attribute designates a large string ME that specifies a local
file name. Since naming is not specified for any OMCI files, this attribute
should be a null pointer in standard OMCI usage, for example, in the
software image case. The use of this attribute for named files is vendorspecific. (R, W) (mandatory) (2 bytes)
Network address pointer: This attribute is a pointer to a network address ME that specifies
optional authentication information, along with the URI to be used for the file
transfer. The URI should specify the protocol, one from the list of protocols
supported by the ONU, an IP address or a string that can be resolved into an
IP address, and optionally a port. For unidirectional multicast download (e.g.,
DSM-CC), the URI should specify a multicast IP source address. (R, W)
File transfer trigger: This attribute causes the file transfer to begin. If a given set operation
writes values to several attributes of this managed entity, the ONU should
apply the file transfer trigger after updating all other attributes. Some
operations may not be applicable to some files; the ONU should deny
commands that request unsupported actions. (R, W) (mandatory) (1 byte)
Value
0
1
2
3
4
5
Meaning
Reserved
Initiate file download (to the ONU)
Initiate file upload (from the ONU)
Abort current file transfer
Delete target file (on the ONU)
Perform a directory listing operation. The scope of the directory is
not specified; at the vendor's option, the listing may be filtered by
matching some or all of file type, file instance and local file name
attributes.
6..255
Reserved
File transfer status: This attribute reports the status of a file transfer. (R) (mandatory)
(1 byte)
Value
0
1
2
356
Meaning
File transfer completed successfully
File transfer aborted successfully
File deleted
Rec. ITU-T G.988 (10/2012)
3
URL undefined or unreachable
4
Failure to authenticate
5
File transfer in progress
6
Remote failure
7
Local failure
8..255
Reserved
GEM IWTP pointer: This attribute is a pointer that specifies a unicast or multicast GEM
interworking termination point, depending on whether the transfer protocol to
be used is unicast or multicast. (R, W) (optional) (2 bytes)
VLAN:
This attribute specifies the VLAN to be used for the transfer, assuming
multicast protocol. The default value 0 indicates that no VLAN is specified.
File size:
This attribute allows the OLT to specify the size of a file to be downloaded,
in bytes. The ONU may use this value to reserve memory or to deny the
download command if it has insufficient space. The default value 0 does not
specify a file size. (R, W) (optional) (4 bytes)
Directory listing table: When a directory listing is complete, this attribute contains the
result of a directory listing operation. The content and format of the table is
not specified. (R) (optional) (N bytes)
Actions
Get, set
Notifications
Number
1..6
7
8..10
11
12..16
Description
N/A
File transfer status
N/A
Directory listing table
This AVC signals to the OLT that a directory listing

operation is complete and may be retrieved with a get, get
next sequence.
Reserved
9.12.14 Generic status portal

The generic status portal managed entity provides a way for the OLT to discover the status and
configuration information of a non-OMCI management domain within an ONU. The non-OMCI
management domain is indicated by the virtual Ethernet interface point associated with this generic
status portal.
The generic status portal ME uses two table attributes to convey status and configuration from a
non-OMCI managed domain to the OMCI. Each of these attributes uses an XML document to
present this information. These XML documents are not required to be understood by the OLT or
EMS. The schema for the documents may be used in the creation of tools that parse and interpret
the contents of the document.
Relationships
One instance of this ME is created by the OLT for each separate non-OMCI management
domain whose information is desired to be visible.
Rec. ITU-T G.988 (10/2012)
357
Attributes
Through an identical ID, the generic status portal ME is implicitly linked to
an instance of the virtual Ethernet interface point ME. (R, Set-by-create)
(mandatory) (2 bytes). (R)
Status document table: This attribute is used to pass a textual representation of the nonOMCI managed domain status back to the OLT. The contents are
vendor-specific and formatted as an XML document. The first element of the
document must contain an XML declaration indicating the version of XML
and encoding used in the remainder of the document. The second element of
the document must contain a schema reference to the vendor-supplied
schema used by the remainder of the document. The get, get next sequence
must be used with this attribute since its size is unspecified. (R) (mandatory)
(N bytes)
Configuration document table: This attribute is used to pass a textual representation of the
non-OMCI managed domain configuration back to the OLT. The contents are
vendor-specific and formatted as an XML document. The first element of the
document must contain an XML declaration indicating the version of XML
and encoding used in the remainder of the document. The second element of
the document must contain a schema reference to the vendor-supplied
schema used by the remainder of the document. The get, get next sequence
must be used with this attribute since its size is unspecified. (R) (mandatory)
(M bytes)
AVC report rate: This attribute governs the rate at which the generic status portal generates
attribute value change notifications. The default value 0 disables AVCs,
while the highest value 3, which may be useful for debugging, generates an
AVC on every change seen in the non-OMCI management domain. As a
guideline, the value 1 should collect changes into not more than one
notification in ten minutes, while value 2 should generate an AVC not more
than once per second. (R, W, Set-by-create) (optional) (1 byte)
Actions
Create, delete, Get, get next
Notifications
Number
Description
Status document table
Indicates an update to the status document table from a

non-OMCI interface. Because the attribute is a table, the
AVC does not contain information about its value. The OLT
must use the get, get next action sequence if it wishes to
obtain the updated attribute content.
Configuration
document table
Indicates an update to the configuration document table from

a non-OMCI interface. Because the attribute is a table, the
AVC does not contain information about its value. The OLT
must use the get, get next action sequence if it wishes to
obtain the updated attribute content.
3..16
358
Attribute value
change
Reserved
Rec. ITU-T G.988 (10/2012)
9.12.15 SNMP configuration data

The SNMP configuration data managed entity provides a way for the OLT to provision an IP path
for an SNMP management agent.
The SNMP configuration data managed entity is created and deleted by the OLT.
Relationships
One instance of this ME is created by the OLT for each SNMP management path
termination.
Attributes
The ME IDs 0 and 0xFFFF are reserved. (R, Set-by-create) (mandatory)
(2 bytes)
SNMP version: This integer attribute is the SNMP protocol version to be supported.
SNMP agent address: This attribute is a pointer to a TCP/UDP config data managed entity,
which provides the SNMP agent. (R, W, Set-by-create) (mandatory) (2 bytes)
SNMP server address: This attribute is the IP address of the SNMP server. (R, W,
SNMP server port: This attribute is the UDP port number of the SNMP server. (R, W,
Security name pointer: This attribute points to a large string whose content represents the
SNMP security name in a human-readable format that is independent of the
security model. SecurityName is defined in [b-IETF RFC 2571]. (R, W,
Community for read: This attribute is a pointer to a large string that contains the name of
the read community. (R, W, Set-by-create) (mandatory) (2 bytes)
Community for write: This attribute is a pointer to a large string that contains the name of
the write community. (R, W, Set-by-create) (mandatory) (2 bytes)
Sys name pointer: This attribute points to a large string whose content identifies the SNMP
system name. SysName is defined in [b-IETF RFC 3418]. (R, W,
Actions
Create, delete, Set, get
Notifications
None.
9.12.16 BBF TR-069 management server
If functions within the ONU are managed by [BBF TR-069], this ME allows OMCI configuration
of the autoconfiguration server (ACS) URL and related authentication information for an ACS
connection initiated by the ONU. [BBF TR-069] supports other means to discover its ACS, so not
all BBF TR-069-compatible ONUs necessarily support this ME. Furthermore, even if the ONU
does support this ME, some operators may choose not to use it.
An ONU that supports OMCI configuration of ACS information automatically creates instances of
this managed entity.
Rec. ITU-T G.988 (10/2012)
359
Relationships
An instance of the BBF TR-069 management server managed entity exists for each instance
of a BBF TR-069 management domain within the ONU.
Attributes
instance of a virtual Ethernet interface point that links to the BBF TR-069
management domain. (R) (mandatory) (2 bytes)
this managed entity. When the administrative state is locked, the functions of
this ME are disabled. BBF TR-069 connectivity to an ACS may be possible
through means that do not depend on this ME. The default value of this
attribute is locked. (R,W) (mandatory) (1 byte)
ACS network address: This attribute points to an instance of a network address managed
entity that contains URL and authentication information associated with the
ACS URL. (R, W) (mandatory) (2 bytes)
Associated tag: This attribute is a TCI value for BBF TR-069 management traffic passing
through the virtual Ethernet interface point. A TCI, comprising user priority,
CFI and VID, is represented by 2 bytes. The value 0xFFFF specifies that
BBF TR-069 management traffic passes through the virtual Ethernet
interface point with neither a VLAN nor a priority tag. (R, W) (mandatory)
(2 bytes)
Actions
Get, set
9.13
Miscellaneous services
9.13.1 Physical path termination point video UNI

This managed entity represents an RF video UNI in the ONU, where physical paths terminate and
physical path level functions are performed.
when the ONU has RF video UNI ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the video UNI type;
video UNI type. Note that the installation of a plug-and-play card may indicate the presence
of video ports via equipment ID as well as its type, and indeed may cause the ONU to
instantiate a port mapping package that specifies video ports.
provisioned to expect a video circuit pack, nor is it equipped with a video circuit pack.
Relationships
One or more instances of this managed entity are associated with an instance of a real or
virtual circuit pack classified as video type.
360
Rec. ITU-T G.988 (10/2012)
Attributes
(optional) (1 byte)
ARC:

Power control: This attribute controls whether power is provided from the ONU to an
external equipment over the video PPTP. Value 1 enables power over coaxial
cable. The default value 0 disables power feed. (R, W) (optional) (1 byte)
Actions
Get, set
Notifications
Number
Description
N/A
Op state
Operational state of video UNI
ARC
4..5
N/A
6..16
Reserved
Alarm
Alarm
number
Alarm
Description
Video-LOS
No signal at the video UNI
Video-OOR-low
RF output below rated value
Video-OOR-high
RF output above rated value
Reserved
Reserved for vendor-specific alarms
3..207
208..223
9.13.2 Physical path termination point video ANI

This managed entity represents an RF video ANI in the ONU, where physical paths terminate and
physical path level functions are performed.
when the ONU has video ANI ports built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the video ANI type;
Rec. ITU-T G.988 (10/2012)
361
When a cardholder provisioned for plug-and-play is equipped with a circuit pack of the
video ANI type. Note that the installation of a plug-and-play card may indicate the presence
of video ANI ports via equipment ID as well as its type, and indeed may cause the ONU to
instantiate a port mapping package that specifies video ANI ports.
provisioned to expect a video ANI circuit pack, nor is it equipped with a video ANI circuit pack.
Relationships
An instance of this managed entity is associated with each instance of a real or preprovisioned video ANI port.
Attributes
This two-byte number indicates the physical position of the ANI. The first
(optional) (1 byte)
ARC:

Frequency range low: This attribute indicates the lower of the two possible frequency
ranges supported. Different frequency ranges are indicated by code points:
0
No low band
1
50..550 MHz
2
50..750 MHz
3
50..870 MHz
4..255 Reserved
Frequency range high: This attribute indicates the higher of the two frequency ranges
supported. Different frequency ranges are indicated by code points:
0
No high band
1
550..750 MHz
2
550..870 MHz
3
950..2050 MHz
4
2150..3250 MHz
5
950..3250 MHz
6..255 Reserved
362
Rec. ITU-T G.988 (10/2012)
Signal capability: This attribute indicates the capability of the ONU to measure the video
signal level. Capabilities are indicated by code points:
0
No signal level measurement capability
1
Total optical power level
2
Fixed frequency pilot tone power level
3
Total optical power level and fixed frequency pilot tone power
level
4
Variable frequency pilot tone power level
5
Total optical power level and variable frequency pilot tone
power level
6
Broadband RF power level
7
Total optical power level and broadband RF power level
8..255 Reserved
Optical signal level: This attribute is an unsigned integer that returns the current
measurement of the total optical signal level. The unit of this attribute is
dBW optical.
If signal capability = 0, 2, 4 or 6, this attribute is undefined.
If signal capability =1, 3, 5 or 7, this attribute describes the total
optical power that is generating photocurrent on the receiver.
Pilot signal level: This attribute indicates the current measurement of the pilot signal level
or broadband RF level. The unit of this attribute is dBV at the RF video
service port.
If signal capability = 0 or 1, then this attribute is undefined.
If signal capability = 2, 3, 4 or 5, this attribute reports the pilot signal
level at the output of the video UNI.
If signal capability = 6 or 7, this attribute reports the total RF power
level at the output of the video UNI.
Signal level min: This attribute indicates the minimum optical RF power per channel that
results in a CNR of 47 dBc for a channel of 4.5 MHz bandwidth at a receive
optical power of 5 dBm. The unit of this attribute is dBW optical. (R)
Signal level max: This attribute indicates the maximum optical RF power per channel that
results in a CTB of 57 dBc for an 80-channel ensemble of carriers at a
per-channel optical modulation index of 3.5%. The unit of this attribute is
dBW optical. (R) (mandatory) (1 byte)
Pilot frequency: This attribute specifies the frequency of the pilot channel receiver. The
unit of this attribute is Hz.
If signal capability = 0, 1, 6 or 7, this attribute is undefined.
If signal capability = 2 or 3, this attribute is functionally read only.
If signal capability = 4 or 5, this attribute is read-write.
AGC mode: This attribute allows the discovery and configuration of the ONU's AGC
capabilities. The attribute contains a code point for several AGC types. The
ONU displays the currently used AGC mode. The OLT can discover new
Rec. ITU-T G.988 (10/2012)
363
modes via the set command; the ONU denies attempts to set an unsupported
mode. The code points are:
0
No AGC
1
Broadband RF AGC
2
Optical AGC
3..255 Reserved
AGC setting: This attribute indicates the measurement offset that the ONU should use in
AGC. The attribute has a step size of 0.1 dB, represented as a signed integer.
The theoretical nominal RF signal is 80 channels of NTSC video, each with a
per-channel optical modulation index of 3.5%. An ONU presented with such
a signal should produce its specified output when this attribute is set to zero.
If total optical power is used for AGC, this attribute provides the optical
modulation index (OMI) offset for any NTSC carriers present from the
theoretical 3.5% value. For example, if the actual signal uses an OMI of 7.0%
per channel (3 dB higher), then the ONU should be given an AGC setting of
30 (coded 0x1E).
If broadband RF power is used for AGC, this attribute provides the total
power offset for any NTSC carriers present from the theoretical 80-channel
value. For example, if an actual signal contains 40 NTSC channels (3 dB
lower), then the ONU should be given an AGC setting of
30 (coded 0xE2).
Video lower optical threshold: This attribute specifies the optical level used to declare the
video OOR low alarm. Valid values are 12 to +6 dBm in 0.1 dB increments,
represented as a 2s complement integer. (Coding 120 to +60, where
0x00 = 0 dBm, 0x88 = 12.0 dBm, etc.) Upon ME instantiation, the ONU
sets this attribute to 0xA1 (9.5 dBm). (R, W) (optional) (1 byte)
NOTE Because the power measurement returned in the optical signal level
attribute has a resolution of 1 dB, it is possible that the measured value could appear
to be in-range, even though an out-of-range alarm has been declared against a
threshold with 0.1 dB resolution.
Video upper optical threshold: This attribute specifies the optical level used to declare the
video OOR high alarm. Valid values are 12 to +6 dBm in 0.1 dB
increments, represented as a 2s complement integer. (Coding 120 to +60,
0x00 = 0 dBm, 0x88 = 12.0 dBm, etc.) Upon ME instantiation, the ONU
sets this attribute to 0x19 (+2.5 dBm). (R, W) (optional) (1 byte)
Actions
Get, set
Notifications
Number
364
Description
N/A
Op state
Operational state of video ANI
ARC
Rec. ITU-T G.988 (10/2012)
4..16
N/A
Alarm
Alarm
number
Alarm
Description
Video LOS
No signal at the video ANI
Video OOR low
Signal strength below lower optical threshold (optional)
Video OOR high
Signal strength above upper optical threshold (optional)
3..207
208..223
Reserved
9.13.3 Physical path termination point LCT UNI

This managed entity models debug access to the ONU from any physical or logical port, for
example, via a dedicated local craft terminal UNI, via ordinary subscriber UNIs, or via the IP host
config ME.
when the ONU has an LCT port built into its factory configuration;
when a cardholder is provisioned to expect a circuit pack of the LCT type;
when a cardholder provisioned for plug-and-play is equipped with a circuit pack of the LCT
type;
NOTE The installation of a plug-and-play card may indicate the presence of LCT ports via
equipment ID as well as its type, and indeed may cause the ONU to instantiate a port mapping
package that specifies LCT ports.
when the ONU supports debug access through some other physical or logical means.
The ONU automatically deletes an instance of this managed entity when a cardholder is neither
provisioned to expect an LCT circuit pack, nor is it equipped with an LCT circuit pack, or if the
ONU is reconfigured in such a way that it no longer supports debug access.
LCT instances are not reported during a MIB upload.
Relationships
An instance of this managed entity is associated with an instance of a real or virtual circuit
pack managed entity classified as an LCT type. An instance of this managed entity may also
be associated with the ONU as a whole, if the ONU supports debug access through means
other than a dedicated physical LCT port.
Attributes
with the range 1..255. If the LCT UNI is associated with the ONU as a
whole, its managed entity ID should be 0. (R) (mandatory) (2 bytes)
this managed entity. Administrative state is described generically in
clause A.1.6. The LCT has additional administrative state behaviour. When
the administrative state is set to lock, debug access through all physical or
logical means is blocked, except that the operation of a possible ONU remote
Rec. ITU-T G.988 (10/2012)
365
debug ME is not affected. Administrative lock of ME instance 0 overrides

administrative lock of any other PPTP LCT UNIs that may exist. (R, W)
Actions
Get, set
Notifications
None.
9.13.4 Interworking VCC termination point
service or underlying physical infrastructure (e.g., ADSL) to an ATM layer takes place. At this
point, ATM cells are generated from a bit stream (e.g., Ethernet) or a bit stream is reconstructed
from ATM cells.
Relationships
One instance of this managed entity exists for each occurrence of transformation of a data
stream into ATM cells and vice versa.
Attributes
VCI value:
This attribute identifies the VCI value associated with this interworking VCC
termination point. (R, W, Set-by-create) (mandatory) (2 bytes)
VP network CTP connectivity pointer: This attribute points to the VP network CTP
associated with this interworking VCC termination point. (R, W,
Deprecated 1: Not used; should be set to 0. (R, W, Set-by-create) (mandatory) (1 byte)
Deprecated 2: Not used; should be set to 0. (R, W, Set-by-create) (mandatory) (2 bytes)
AAL5 profile pointer: This attribute points to an instance of the AAL5 profile. (R, W,
AAL loopback configuration: This attribute sets the ATM loopback configuration. All
code points are retained for backward compatibility, but some are not
expected to be needed in current and future applications.
0 No loopback
1 Loopback 1, loopback of downstream traffic before FEC of AAL1
2 Loopback 2, loopback of downstream traffic after FEC of AAL1
3 Loopback after AAL, loopback of downstream traffic after any AAL.
Loopback after AAL is depicted in Figure 9.13.4-1.
366
Rec. ITU-T G.988 (10/2012)
ONU
PON
ATM
Ethernet over GEM
interworking
xDSL UNI
Loopback after AAL

G.988(12)_F9.13.4-1
Figure 9.13.4-1 AAL loopback configuration

The default value of this attribute is 0. (R, W) (mandatory) (1 byte)
PPTP counter: This value is the number of instances of PPTP managed entities associated
with this instance of the interworking VCC termination point. (R) (optional)
(1 byte)
(optional) (1 byte)
Actions
Notifications
Number
1..8
Description
N/A
Op state
10..16
Reserved
Alarm
Alarm
number
Alarm
Description
End-to-end VC AIS LMIR
End-to-end VC-AIS receiving indication (optional)
End-to-end VC RDI LMIR
End-to-end VC-RDI receiving indication (optional)
End-to-end VC AIS LMIG
End-to-end VC-AIS generation indication (optional)
End-to-end VC RDI LMIG
End-to-end VC-RDI generation indication (optional)
Segment loss of continuity
Loss of continuity detected when the interworking

VCC termination point is a segment end point
(optional)
End-to-end loss of continuity
Loss of continuity detected at the interworking VCC

termination point (optional)
CSA
Cell starvation alarm
7..207
208..223
Reserved
9.13.5 AAL5 profile

This managed entity organizes data that describe the AAL type 5 processing functions of the ONU.
It is used with the interworking VCC termination point managed entity.
This managed entity is created and deleted by the OLT.
Rec. ITU-T G.988 (10/2012)
367
Relationships
interworking VCC termination point.
Attributes
Max CPCS PDU size: This attribute specifies the maximum CPCS PDU size to be
transmitted over the connection in both upstream and downstream directions.
AAL mode:
This attribute specifies the AAL mode:

0 Message assured
1 Message unassured
2 Streaming assured
3 Streaming non assured
SSCS type:
This attribute specifies the SSCS type for the AAL. Valid values are:
0 Null
1 Data SSCS based on SSCOP, assured operation
2 Data SSCS based on SSCOP, non-assured operation
3 Frame relay SSCS
Actions
Notifications
None.
9.13.6 AAL5 performance monitoring history data
This managed entity collects performance monitoring data as a result of performing segmentation
and reassembly (SAR) and convergence sublayer (CS) level protocol monitoring. Instances of this
Relationships
An instance of this managed entity is associated with an instance of an interworking VCC
termination point that represents AAL5 functions.
Attributes
instance of the interworking VCC termination point. (R, Set-by-create)
368
Rec. ITU-T G.988 (10/2012)

Sum of invalid CS field errors: This attribute counts the sum of invalid convergence
sublayer (CS) field errors. For AAL type 5, this attribute is 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. (R) (mandatory) (4 bytes)
CRC violations: This attribute counts CRC violations detected on incoming SAR PDUs.
Reassembly timer expirations: This attribute counts reassembly timer expirations. (R)
(mandatory if reassembly timer is implemented) (4 bytes)
Buffer overflows: This attribute counts the number of times where there was not enough
buffer space for a reassembled packet. (R) (mandatory) (4 bytes)
Encap protocol errors: This attribute counts the number of times that [IETF RFC 2684]
encapsulation protocol detected a bad header. (R) (mandatory) (4 bytes)
Actions
Notifications
Alarm
number
Invalid fields
CRC violation
Reassembly timer
expirations
Buffer overflows
Encap protocol errors

9.13.9 VP network CTP
NOTE In [ITU-T G.984.4], this managed entity is called VP network CTP-G.
This managed entity represents the termination of VP links on an ONU. It aggregates connectivity
functionality from the network view and alarms from the network element view as well as artefacts
from trails. Instances of this managed entity are created and deleted by the OLT.
An instance of the VP network CTP managed entity can be deleted only when no ATM
interworking VCC termination point is associated with it. It is the responsibility of the OLT to
ensure that this condition is met.
Rec. ITU-T G.988 (10/2012)
369
Relationships
Zero or more instances of the VP network CTP managed entity may exist for each instance
of the interworking VCC termination point managed entity.
Attributes
VPI value:
This attribute identifies the VPI value associated with the VP link being
terminated. (R, W, Set-by-create) (mandatory) (2 bytes)
UNI pointer: This pointer indicates the xDSL physical path termination point UNI
associated with this VP termination point. The bearer channel may be
indicated by the two most significant bits of the pointer. (R, W,
Direction:
This attribute specifies whether the VP link is used for UNI-to-ANI (value 1),
ANI-to-UNI (value 2), or bidirectional (value 3) connection. (R, W,

Deprecated 3: Not used; should be set to 0. (R, W, Set-by-create) (optional) (2 bytes)
Deprecated 4: Not used; if present, should be set to 0. (R) (optional) (1 byte)
Actions
Notifications
Alarm
Alarm
number
Alarm
Description
VP AIS LMIR
VP-AIS receiving indication
VP RDI LMIR
VP-RDI receiving indication
VP AIS LMIG
VP-AIS generation indication
VP RDI LMIG
VP-RDI generation indication
Segment loss of
continuity
Loss of continuity is detected when the VP network CTP is a

segment end point
End-to-end loss of
continuity
Loss of continuity can be detected when the VP network CTP

supports an interworking VCC termination point
6..207
208..223
Reserved
Vendor-specific
alarms
9.13.10 VP performance monitoring history data

This managed entity collects performance monitoring data associated with a VP network CTP.
370
Rec. ITU-T G.988 (10/2012)
Relationships
An instance of this managed entity is associated with an instance of the VP network CTP
managed entity. The performance of upstream ATM flows is reported.
Attributes
instance of the VP network CTP. (R, Set-by-create) (mandatory) (2 bytes)
Lost C = 0 + 1 cells: This attribute counts all 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. (R) (mandatory) (2 bytes)
Lost C = 0 cells: This attribute counts loss of high priority cells. 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 high priority cells. (R)
Misinserted cells: This attribute counts cells that are misrouted to a monitored VP. (R)
Transmitted C = 0 + 1 cells: This attribute counts cells originated by the transmitting end
point (i.e., backward reporting is assumed). (R) (mandatory) (5 bytes)
Transmitted C = 0 cells: This attribute counts high priority cells originated by the
transmitting end point (i.e., backward reporting is assumed). (R) (mandatory)
(5 bytes)
Impaired blocks: This severely errored cell block counter is incremented whenever one of
the following events takes place: the number of misinserted cells reaches its
threshold, the number of bipolar violations reaches its threshold, or the
number of lost cells reaches its threshold. Threshold values are based on
vendor-operator negotiation. (R) (mandatory) (2 bytes)
Actions
Notifications
Alarm
number
Threshold crossing
alert
Lost CLP = 0 + 1 cells
Lost CLP = 0 cells
Misinserted cells
Rec. ITU-T G.988 (10/2012)
371
Impaired blocks
9.13.11 Enhanced security control

This managed entity contains the capabilities, parameters and controls of enhanced G-PON security
features when they are negotiated via the OMCI (Note). The attributes in this ME are intended to be
used to implement a symmetric-key-based three step authentication process as described in the
supplemental information section below.
NOTE If an ITU-T G.987 system uses 802.1X authentication as defined in [ITU-T G.987.3], the only
applicable attribute of this ME is the broadcast key table.
Relationships
Attributes
OLT crypto capabilities: This attribute specifies the cryptographic mechanisms available at
the OLT. It is written by the OLT during authentication step 1. It is formatted
as a bit map, where a 1 bit indicates that the particular algorithm is supported,
and a 0 bit indicates it is not supported.
Bit position
Algorithm
1 (LSB)
AES-CMAC-128 (support is mandatory)
2
HMAC-SHA-256
3
HMAC-SHA-512
4-128
Reserved
(W) (mandatory) (16 bytes)
OLT random challenge table: This attribute specifies the random challenge
OLT_challenge issued by the OLT during authentication step 1. It is
structured as a table, with each entry being 17 bytes. The first byte is the
table row number, starting at 1, and the remaining 16 bytes are the contents
of the entry. OLT_challenge is the concatenation of all 16-byte content fields.
In normal use, the OLT will write all the entries in the table, and then trigger
the ONU's processing of the entire table using the OLT challenge status
attribute. The table size is known by the maximum index set by the OLT. The
OLT can clear the table with a set operation to row 0. (R, W) (mandatory)
(17 * N bytes)
NOTE It is assumed that the length of OLT_challenge is always an integer
multiple of 16 bytes.
OLT challenge status: This Boolean attribute controls the completion of authentication step
1. This attribute behaves as follows:
When the OLT performs the first of possibly several set operations to the
OLT crypto capabilities or the OLT random challenge table attributes,
a side effect of the set operation is that the ONU sets the OLT
challenge status attribute to false.
When the OLT completes the set operation(s) to the OLT crypto
capabilities and the OLT random challenge table attributes, then it
sets the OLT challenge status attribute to true. This triggers the ONU
372
Rec. ITU-T G.988 (10/2012)
to process the OLT random challenge table, using its choice of the
OLT's candidate cryptographic hash algorithms.
The ONU initializes this attribute to the value false. (R, W) (mandatory)
(1 byte)
ONU selected crypto capabilities: This attribute specifies the cryptographic capability
selected by the ONU in authentication step 2. Its value specifies one of the bit
positions that has the value 1 in the OLT crypto capabilities attribute. (R)
ONU random challenge table: This attribute specifies the random challenge
ONU_challenge issued by the ONU during authentication step 2. It is
structured as a table, with each entry being 16 bytes of content.
ONU_challenge is the concatenation of all 16-byte content fields in the table.
Once the OLT triggers a response to be generated using the OLT challenge
status attribute, the ONU generates the response and writes the table (in a
single operation). The AVC generated by this attribute signals to the OLT
that the challenge is ready, so that the OLT can commence a get/get-next
sequence to obtain the table's contents. (R) (mandatory) (16 * P bytes)
ONU authentication result table: (authentication step 2). This attribute contains the result
of the authentication computation from the ONU (ONU_result), according to
the ONU's selected crypto capabilities attribute.
ONU_result = SelectedHashFunction (PSK, (ONU_selected_crypto
capabilities | OLT_challenge | ONU_challenge | 0x0000 0000 0000
0000)),
where "|" denotes concatenation.
This attribute is structured as a table, with each entry being 16 bytes of
content. The number of rows Q is implicit in the choice of hash algorithm.
Once the OLT triggers a response to be generated using the OLT challenge
status attribute, the ONU generates ONU_result and writes the table (in a
single operation). The AVC generated by this attribute signals to the OLT
that the response is ready, so that the OLT can commence a get/get-next
sequence to obtain the table's contents. (R) (mandatory) (16 * Q bytes)
OLT authentication result table: This attribute is used in authentication step 3. It contains
OLT_result, the result of the authentication computation from the OLT.
OLT_result = SelectedHashFunction (PSK, (ONU_selected_crypto
capabilities
|
ONU_challenge
|
OLT_challenge
|
ONU_serial_number)).
The ONU_serial_number is the serial number attribute of the ONU-G
managed entity, 8 bytes.
This attribute is structured as a table, with each entry being 17 bytes. The first
byte is the table row number, starting at 1; the remaining 16 bytes are
content. OLT_result is the concatenation of all 16-byte content fields. The
OLT writes all entries into the table, and then triggers the ONU's processing
of the table using the OLT result status attribute. The number of rows R is
implicit in the choice of hash algorithm. The OLT can clear the table with a
set operation to row 0. (W) (mandatory) (17 * R bytes)
Rec. ITU-T G.988 (10/2012)
373
OLT result status: (authentication step 3). This Boolean attribute controls and reports the
status of the OLT authentication result table attribute. This attribute behaves
as follows:
When the OLT performs the first of possibly several set operations to the
OLT authentication result table attribute, a side effect of the set
operation is that the ONU sets the OLT result status attribute to false.
When the OLT completes the set operation(s) to the OLT authentication
result table, then it sets the OLT result status attribute to true. This
triggers the ONU to process the OLT authentication result table.
ONU authentication status: This attribute indicates the status of the authentication
relationship from the perspective of the ONU. It has the following values:
0 Indeterminate. This initial value indicates that the OMCI
authentication process has not yet completed, and may not even have
been started.
1 Reserved.
2 Reserved.
3 Authentication success: the procedure has completed at least once and
in its most recent execution, the ONU has authenticated the OLT.
4 Authentication failure: the procedure has completed at least once, and
either its most recent execution resulted in an error, or the ONU has
failed to authenticate the OLT.
5 Reserved.
When the ONU authentication status has the value 3, encryption keys
exchanged in the TC layer will be encrypted using the master session key
(ITU-T G.984 systems) or the key encryption key (ITU-T G.987 systems).
The OLT should check the value of of this attribute before initiating a key
switch.
Master session key name: Following successful authentication, this register contains the
"name," or the hash signature, of the current master session key. The master
session key is defined as:
MSK = SelectedHashFunction (PSK, (OLT_challenge |
ONU_challenge)).
The master session key name is defined as:
MSKname = SelectedHashFunction (PSK, (ONU_challenge |
OLT_challenge | 0x 3141 5926 5358 9793 3141 5926 5358 9793)).
If the selected hash function generates more than 128 bits, the result is
truncated to the leftmost (most significant) 128 bits.
Upon the invalidation of a master session key (e.g., due to an ONU reset or
deactivation, or due to an ONU-local decision that the master session key has
expired), the ONU sets the master session key name to all zeros. (R)
Broadcast key table: This attribute is defined only in ITU-T G.987 systems. It contains the
broadcast key generated by the OLT. It is a table, each of whose rows is
structured as follows:
374
Rec. ITU-T G.988 (10/2012)
Row control (1 byte): The two least significant bits of this byte determine
the attribute's behaviour under the set action. They always read back
as 0 under the get next action.
00 Set the specified row.
01 Clear the specified row.
10 Clear the entire table.
11 Reserved.
The four most significant bits specify the length of the fragment,
which is left-justified in the key fragment field. The value 0 indicates
16 bytes of key fragment.
The other two bits are reserved.
Row identifier (1 byte): The two most significant bits of this field are the
key index, which appears in the header of encrypted multicast GEM
frames. Key index 0 always indicates cleartext, and should therefore
not appear in the identifier. The four least significant bits identify the
key fragment number, starting with 0. The other two bits are reserved.
Key fragment (16 bytes): This field contains the specified fragment of the
key (encrypted with AES-ECB using the KEK).
(R, W) (optional) (18N bytes)
Effective key length: This attribute specifies the maximum effective length, in bits, of keys
generated by the ONU. (R) (optional) (2 bytes)
Actions
Get, set, get next
Notifications
Number
1..4
Description
Reserved
ONU random challenge table
A new ONU challenge has been loaded into the

table for the OLT to retrieve
ONU authentication result table
A new ONU response has been loaded into the

table for the OLT to retrieve
7..8
9
10..16
Reserved
ONU authentication status
The ONU authentication status has changed
Reserved
Supplementary information
This managed entity contains the facilities to perform a conventional three step hash-based
authentication sequence found in [ISO/IEC 9798-4] (used in DSL systems that employ MSCHAPv2 and elsewhere) using get and set messages.
The logical structure of the conventional three step sequence is as follows. In the present situation,
peer 1 is the OLT and peer 2 is the ONU:
Message 1: (Peer 1 peer 2) my_cryptographic_capabilities | random_challenge_1
Rec. ITU-T G.988 (10/2012)
375
Message 2: (Peer 2 peer 1): selected_cryptographic_capabilities | random_challenge_2 |

MsgHash (PSK, (selected_cryptographic_capabilities | random_challenge_1 |
random_challenge_2, peer_1_identity))
Message 3: (Peer 1 peer 2): MsgHash (PSK, (selected_cryptographic_capabilities |
random_challenge_2 | random_challenge_1 | peer_2_identity))
Where:
MsgHash () is a keyed hash function of the message
PSK is the pre-shared key known to the peers of the session
Peer_1_identity is always "0x0000 0000 0000 0000"
Peer_2_identity is the ONU serial number
The prerequisite is the availability of a pre-shared secret PSK. A PSK of 128 bits simplifies the
application of security algorithms based on AES-128 (e.g., AES-CMAC-128). A PSK is associated
with a particular ONU and is stored at that ONU and at the operator infrastructure. On the operator
side, the PSK for a particular ONU might be stored in the physically-connected OLT, or at a central
server that the OLT accesses during authentication. Configuration of the PSK into the ONU and
into the operator infrastructure may be done in any manner that satisfies these requirements.
In the OMCI, the authentication message sequence follows the steps illustrated in Figure 9.13.11-1.
OLT
ONU
Notation: Set* indicates multiple set
operations, as needed to fill table
Set* [OLT crypto capabilities, OLT random challenge table]
Set [OLT challenge status = true]
OMCI
process
states
OLT
challenge
status
S0
AVC [ONU random challenge table]
AVC [ONU authentication result table]

Get [ONU selected crypto capabilities, ONU random challenge table,
ONU authentication result table]
S1
OLT
result
status
Get_response [ ]
Set* [OLT authentication result table]
Set [OLT result status = true]
AVC [ONU authentication state]
Get [Master session key name]
S0
Get_response [ ]
G.988(10)_F9.13.11-1
Figure 9.13.11-1 Authentication message exchange sequence

States of the OMCI authentication process
When an ONU is in operation state O5, as defined in [ITU-T G.984.3] and [ITU-T G.987.3], it
maintains an OMCI authentication process state machine that tracks the phase of the authenticationrelated OMCI message flow exchange. The OMCI authentication process state machine is driven by
the OLT challenge and result status indications, and generates output that indicates the ONU
authentication status.
376
Rec. ITU-T G.988 (10/2012)
S0 - complete
OLT sets OLT crypto
capabilities and/or OLT
random challenge table
OLT sets OLT
result status
S1 - OLT
challenge
pending
G.988(12)_F9.13.11-2
Figure 9.13.11-2 ONU state diagram

Synchronization with TC layer and security considerations (ITU-T G.984 systems only)
When the ONU is in authenticated state, it uses its master session key to encrypt the key transmitted
in the encryption_key PLOAM message.
The master session key is defined as:
MasterSessionKey = SelectedHashFunction (PSK, (OLT_challenge | ONU_challenge))
where SelectedHashFunction () is the hash function selected by the ONU in the ONU selected
crypto capabilities attribute from the list supplied by the OLT.
The encryption of the encryption key is performed using AES-128 in electronic codebook (ECB)
mode.
Since the encryption key carried in the encryption key PLOAM message is not protected against
forgery, there is the possibility that the key can be forged or replayed by an attacker. Both forged
and replayed keys can be detected with key synchronization mechanisms. A replay attack, however,
could force the OLT to use an old encryption key, which would violate the security requirements of
downstream data encryption. Consequently, an OLT designed to resist a replay attack should ensure
that the ONU does not send a previously used encryption key between authentication cycles.
9.14
Mid-span PON reach extender

ONU
R/S
UNI
ODN: optical
distribution
network
S'/R'
Mid-span
extender
OTL: optical
trunk line
R'/S'
S/R
OLT
SNI
ONU
UNI
G.988(12)_F9.14-1
R/S
Figure 9.14.1 Mid-span PON reach extender

[ITU-T G.984.6] defines a mid-span PON reach extender (RE). A reach extender may extend more
than one PON, using optical amplification or optical-electrical-optical regeneration technology. For
easy reference, Figure 9.14-1 illustrates the interface designations.
The RE model includes one built-in ONU, which serves for management of the RE itself, as well as
for optional subscriber or craft UNIs. The ONU embedded within the RE is therefore able to use
any of the managed entities defined elsewhere in this Recommendation, including the ANI-G and
T-CONT MEs, which represent the built-in ONU's individual uplink.
NOTE 1 Although the built-in management ONU is physically contained within a physical reach extender
equipment, the management model perspective is that the ONU software controls the entire equipment. In
Rec. ITU-T G.988 (10/2012)
377
terms of the model, therefore, the management ONU contains the reach extender equipment and
functionality.
This clause defines additional managed entities that pertain to the reach extender function
separately.
The current scope of the RE model includes the use of either regeneration (OEO) or optical
amplification (OA) in the upstream and in the downstream directions, independently. Split ratio
enhancement (more than one RE UNI for every RE ANI) is also included. This results in eight
possible arrangements, as follows.
NOTE 2 Each amplifier ME is associated with an RE common amplifier parameters ME.
Downstream
technology
Upstream
technology
Internal
optical
split
OEO
OEO
1:1
One PPTP RE UNI pointing to one RE ANI-G, all

attributes active
OEO
OEO
1:N
N PPTP RE UNIs pointing to one RE ANI-G, all

attributes active
OA
OA
1:1
One RE upstream amplifier pointing to one RE

downstream amplifier
OA
OA
1:N
N RE upstream amplifiers pointing to one RE

downstream amplifier
OA
OEO
1:1
One PPTP RE UNI pointing to one RE ANI-G.

Downstream transmit optical attributes of the RE ANI-G
not used. One downstream amplifier, likely sharing ME
ID with the RE ANI-G.
OA
OEO
1:N
N PPTP RE UNIs pointing to one RE ANI-G.

Downstream transmit optical attributes of the RE ANI-G
not used. One downstream amplifier, likely sharing ME
ID with the RE ANI-G.
OEO
OA
1:1
One PPTP RE UNI pointing to one RE ANI-G.

Upstream transmit optical attributes of the RE UNI not
used. One upstream amplifier, likely sharing ME ID
with the PPTP RE UNI.
OEO
OA
1:N
N PPTP RE UNIs pointing to one RE ANI-G. Upstream

transmit optical attributes of the RE UNI not used. N
upstream amplifiers, likely sharing ME IDs with the
PPTP RE UNIs.
Model
9.14.1 RE ANI-G
This managed entity organizes data associated with each R'/S' physical interface of a reach extender
if the RE supports OEO regeneration in either direction. The management ONU automatically
creates one instance of this managed entity for each R'/S' physical port (uni- or bidirectional):
when the RE has mid-span PON reach extender ANI interface ports built into its factory
configuration;
when a cardholder is provisioned to expect a circuit pack of the mid-span PON reach
extender ANI type;
mid-span PON reach extender ANI type. Note that the installation of a plug-and-play card
may indicate the presence of a mid-span PON reach extender ANI port via equipment ID as
378
Rec. ITU-T G.988 (10/2012)
well as its type attribute, and indeed may cause the management ONU to instantiate a port
mapping package to specify the ports precisely.
The management ONU automatically deletes instances of this managed entity when a cardholder is
neither provisioned to expect a mid-span PON reach extender ANI circuit pack, nor is it equipped
with a mid-span PON reach extender ANI circuit pack.
As illustrated in Figure 8.2.10-4, an RE ANI-G may share the physical port with an RE downstream
amplifier. The ONU declares a shared configuration through the port mapping package combined
port table, whose structure defines one ME as the master. It is recommended that the RE ANI-G be
the master, with the RE downstream amplifier as a secondary ME.
The administrative state, operational state and ARC attributes of the master ME override similar
attributes in secondary MEs associated with the same port. In the secondary ME, these attributes are
present, but cause no action when written and have undefined values when read. The RE
downstream amplifier should use its provisionable downstream alarm thresholds and should declare
downstream alarms as necessary; other isomorphic alarms should be declared by the RE ANI-G.
The test action should be addressed to the master ME.
Relationships
An instance of this managed entity is associated with each R'/S' physical interface of an RE
that includes OEO regeneration in either direction, and with one or more instances of the
PPTP RE UNI. It may also be associated with an RE downstream amplifier.
Attributes
Its value indicates the physical position of the R'/S' interface. The first byte is
the slot ID (defined in clause 9.1.5). The second byte is the port ID. (R)
NOTE 1 This ME ID may be identical to that of an RE downstream amplifier if it
shares the same physical slot and port.
NOTE 2 When an RE supports multiple PONs, or protected access to a single
PON, its primary ANI-G cannot be completely shut down, due to a loss of the
management communications capability. Complete blocking of service and removal
of power may nevertheless be appropriate for secondary RE ANI-Gs. Administrative
lock suppresses alarms and notifications for an RE ANI-G, be it either primary or
secondary.
(optional) (1 byte)
ARC:

Optical signal level: This attribute reports the current measurement of total downstream
optical power. Its value is a 2s complement integer referred to 1 mW (i.e.,
Lower optical threshold: This attribute specifies the optical level that the RE uses to
declare the downstream low received optical power alarm. Valid values are
Rec. ITU-T G.988 (10/2012)
379

default value 0xFF selects the RE's internal policy. (R, W) (optional) (1 byte)
Upper optical threshold: This attribute specifies the optical level that the RE uses to
declare the downstream high received optical power alarm. Valid values are
Transmit optical level: This attribute reports the current measurement of mean optical
launch power. Its value is a 2s complement integer referred to 1 mW (i.e.,
Lower transmit power threshold: This attribute specifies the minimum mean optical
launch power that the RE uses to declare the low transmit optical power
with 0.5 dB granularity. The default value 0x7F selects the RE's internal
policy. (R, W) (optional) (1 byte)
Upper transmit power threshold: This attribute specifies the maximum mean optical
launch power that the RE uses to declare the high transmit optical power
Usage mode: In a mid-span PON reach extender, an R'/S' interface may be used as the
PON interface for the embedded management ONU and/or the uplink
interface for an S'/R' interface. This attribute specifies the usage of the R'/S'
interface. (R, W) (mandatory) (1 byte)
0 Disable
1 This R'/S' interface is used as the uplink for the embedded
management ONU
2 This R'/S' interface is used as the uplink for one or more PPTP RE
UNI(s)
3 This R'/S' interface is used as the uplink for both the embedded
management ONU and one or more PPTP RE UNI(s) (in a time
division fashion).
Target upstream frequency: This attribute specifies the frequency of the converted
upstream signal on the OTL, in GHz. The converted frequency must conform
to the frequency plan specified in [ITU-T G.984.6]. The value 0 means that
the upstream signal frequency remains the same as the original frequency; no
frequency conversion is done. If the RE does not support provisionable
upstream frequency (wavelength), this attribute should take the fixed value
representing the RE's capability, and the RE should deny attempts to set the
value of the attribute. If the RE does support provisionable upstream
frequency conversion, the default value of this attribute is 0. (R, W)
(optional) (4 bytes).
Target downstream frequency: This attribute specifies the frequency of the downstream
signal received by the RE on the OTL, in GHz. The incoming frequency must
conform to the frequency plan specified in [ITU-T G.984.6]. The default
value 0 means that the downstream frequency remains the same as its original
frequency; no frequency conversion is done. If the RE does not support
provisionable downstream frequency selectivity, this attribute should take the
fixed value representing the RE's capability, and the RE should deny attempts
to set the value of the attribute. If the RE does support provisionable
380
Rec. ITU-T G.988 (10/2012)
downstream frequency selectivity, the default value of this attribute is 0. (R,

W) (optional) (4 bytes).
Upstream signal transmission mode: When true, this Boolean attribute enables conversion
from burst mode to continuous mode. The default value false specifies burst
mode upstream transmission. If the RE does not have the ability to convert
from burst to continuous mode transmission, it should deny attempts to set
this attribute true. (R, W) (optional) (1 byte)
Actions
Get, set
Test
Test the RE-ANI. The test action can be used to perform optical line
supervision tests; refer to the test and test result message definitions in
Annex A.
Notifications
Number
Description
N/A
Op state
Operational state of RE ANI-G
ARC
4..14
N/A
15..16
Reserved
Alarm
Alarm
number
Alarm
Description
Low received optical power Received downstream optical power below threshold
High received optical power Received downstream optical power above threshold
Low transmit optical power
High transmit optical power Transmitted upstream optical power above upper threshold
High laser bias current
5..207
Transmitted upstream optical power below lower threshold

Reserved
208..223 Vendor-specific alarms
Test result:
The RE may report a test result autonomously if it performs self-test

9.14.2 Physical path termination point RE UNI

This managed entity represents an S'/R' interface in a mid-span PON reach extender that supports
OEO regeneration in at least one direction, where physical paths terminate and physical path level
functions are performed (transmit and/or receive).
Such an RE automatically creates an instance of this managed entity for each S'/R' interface port:
when the RE has mid-span PON reach extender UNI interface ports built into its factory
configuration;
Rec. ITU-T G.988 (10/2012)
381
extender UNI type;
mid-span PON reach extender UNI type. Note that the installation of a plug-and-play card
may indicate the presence of a mid-span PON reach extender UNI port via equipment ID as
well as its type attribute, and indeed may cause the management ONU to instantiate a port
mapping package to specify the ports precisely.
neither provisioned to expect a mid-span PON reach extender UNI circuit pack, nor is it equipped
with a mid-span PON reach extender UNI circuit pack.
As illustrated in Figure 8.2.10-3, a PPTP RE UNI may share the physical port with an RE upstream
amplifier. The ONU declares a shared configuration through the port mapping package combined
port table, whose structure defines one ME as the master. It is recommended that the PPTP RE UNI
be the master, with the RE upstream amplifier as a secondary ME.
The administrative state, operational state and ARC attributes of the master ME override similar
attributes in secondary MEs associated with the same port. In the secondary ME, these attributes are
present, but cause no action when written and have undefined values when read. The RE upstream
amplifier should use its provisionable upstream alarm thresholds and should declare upstream
alarms as necessary; other isomorphic alarms should be declared by the PPTP RE UNI. The test
action should be addressed to the master ME.
Relationships
An instance of this managed entity is associated with each instance of a mid-span PON
reach extender S'/R' physical interface of an RE that includes OEO regeneration in either
direction, and it may also be associated with an RE upstream amplifier.
Attributes
NOTE 1 This ME ID may be identical to that of an RE upstream amplifier if it
shares the same physical slot and port.
NOTE 2 Administrative lock of a PPTP RE UNI results in loss of signal to any
downstream ONUs.
(optional) (1 byte)
ARC:

RE ANI-G pointer: This attribute points to an RE ANI-G instance. (R, W) (mandatory)
(2 bytes)
Total optical receive signal level table: This table attribute reports a series of
measurements of time averaged received upstream optical signal power. The
measurement circuit should have a temporal response similar to a simple
382
Rec. ITU-T G.988 (10/2012)
1 pole low pass filter, with an effective time constant on the order of a GTC
frame time. Each table entry has a two-byte frame counter field (most
significant end), and a two-byte power measurement field. The frame counter
field contains the least significant 16 bits of the superframe counter received
closest to the time of the measurement. The power measurement field is a 2s
complement integer referred to 1 mW (i.e., dBm), with 0.002 dB granularity.
The RE equipment should add entries to this table as frequently as is
reasonable. The RE should clear the table once it is read by the OLT. (R)
(optional) (4 * N bytes, where N is the number of measurements present.)
Per burst receive signal level table: This table attribute reports the most recent
measurement of received burst upstream optical signal power. Each table
entry has a two-byte ONU-ID field (most significant end), and a two-byte
power measurement field. The power measurement field is a 2s complement
integer referred to 1 mW (i.e., dBm), with 0.002 dB granularity. (R)
(optional) (4 * N bytes, where N is the number of distinct ONUs connected to
the S'/R' interface.)
Lower receive optical threshold: This attribute specifies the optical level that the RE uses
to declare the burst mode low received optical power alarm. Valid values are
Upper receive optical threshold: This attribute specifies the optical level that the RE uses
to declare the burst mode high optical power alarm. Valid values are
Transmit optical level: This attribute reports the current measurement of the downstream
mean optical launch power. Its value is a 2s complement integer referred to 1
mW (i.e., dBm), with 0.002 dB granularity. (R) (optional) (2 bytes)
Lower transmit power threshold: This attribute specifies the downstream minimum mean
optical launch power at the S'/R' interface that the RE uses to declare the low
transmit optical power alarm. Its value is a 2s complement integer referred to
1 mW (i.e., dBm), with 0.5 dB granularity. The default value 0x7F selects the
RE's internal policy. (R, W) (optional) (1 byte)
Upper transmit power threshold: This attribute specifies the downstream maximum mean
optical launch power at the S'/R' interface that the RE uses to declare the high
transmit optical power alarm. Its value is a 2s complement integer referred to
1 mW (i.e., dBm), with 0.5 dB granularity. The default value 0x7F selects the
RE's internal policy. (R, W) (optional) (1 byte)
Additional preamble: This attribute indicates the number of bytes of PLOu preamble that
are unavoidably consumed while passing the reach extender. (R) (mandatory)
(1 byte)
Additional guard time: This attribute indicates the number of bytes of extra guard time that
are needed to ensure correct operation with the reach extender. (R)
Actions
Get, get next, set
Rec. ITU-T G.988 (10/2012)
383
Test
Test the PPTP RE UNI. The test action can be used to perform optical line
supervision tests; refer to the test and test result message definitions in
Annex A.
Notifications
Number
Description
N/A
Op state
Operational state of PPTP RE UNI
ARC
4..14
N/A
15..16
Reserved
Alarm
Alarm
number
Alarm
Description
Low received optical power
Received upstream optical power of one or more

ONUs below threshold
High received optical power
Received upstream optical power of one or more

ONUs above threshold
Low transmit optical power
Transmit downstream optical power below lower

threshold
High transmit optical power
Transmit downstream optical power above upper

threshold
Laser bias current above threshold determined by

vendor; laser end of life pending
S'/R' LOS
S'/R' LOS detected. No optical signal received at

the S'/R' upstream interface in 500 s
6..207
Reserved
208..223
9.14.3 RE upstream amplifier

This managed entity organizes data associated with each upstream reach extender optical amplifier
supported by the RE. The management ONU automatically creates one instance of this managed
entity for each upstream optical amplifier:
when the RE has mid-span PON reach extender upstream optical amplifier ports built into
its factory configuration;
extender upstream optical amplifier type;
when a cardholder provisioned for plug-and-play is equipped with a circuit pack of the midspan PON reach extender upstream optical amplifier type. Note that the installation of a
plug-and-play card may indicate the presence of a mid-span PON reach extender upstream
optical amplifier via equipment ID as well as its type attribute, and indeed may cause the
management ONU to instantiate a port mapping package to specify the ports precisely.
neither provisioned to expect a mid-span PON reach extender upstream optical amplifier circuit
384
Rec. ITU-T G.988 (10/2012)
pack, nor is it equipped with a mid-span PON reach extender upstream optical amplifier circuit
pack.
Relationships
An instance of this managed entity is associated with an upstream optical amplifier, and
with an instance of a circuit pack. If the reach extender includes OEO regeneration in either
direction, the RE upstream amplifier is also associated with a PPTP RE UNI. Refer to
clause 9.14.2 for further discussion.
Attributes
Its value indicates the physical position of the upstream optical amplifier. The
first byte is the slot ID (defined in clause 9.1.5). The second byte is the port
NOTE 1 This ME ID may be identical to that of a PPTP RE UNI if it shares the
same physical slot and port.
NOTE 2 Administrative lock of an RE upstream amplifier results in loss of signal
from any downstream ONUs.
(optional) (1 byte)
Operational mode: This attribute indicates the operational mode.
0 Constant gain
1 Constant output power
2 Autonomous
ARC:

RE downstream amplifier pointer: This attribute points to an RE downstream amplifier
instance. The default value is 0xFFFF, a null pointer. (R, W) (mandatory)
(2 bytes)
Total optical receive signal level table: This table attribute reports a series of
measurements of time-averaged input upstream optical signal power. The
measurement circuit should have a temporal response similar to a simple 1
pole low pass filter, with an effective time constant on the order of a GTC
frame time. Each table entry has a two-byte frame counter field (most
significant end), and a two-byte power measurement field. The frame counter
field contains the least significant 16 bits of the superframe counter received
closest to the time of the measurement. The power measurement field is a
2s complement integer referred to 1 mW (i.e., dBm), with 0.002 dB
granularity. The RE equipment should add entries to this table as frequently
as is reasonable. The RE should clear the table once it is read by the OLT.
(R) (optional) (4 * N bytes, where N is the number of measurements present.)
Per burst receive signal level table: This table attribute reports the most recent
measurement of received burst upstream optical signal power. Each table
Rec. ITU-T G.988 (10/2012)
385
entry has a two-byte ONU-ID field (most significant end), and a two-byte
power measurement field. The power measurement field is a 2s complement
integer referred to 1 mW (i.e., dBm), with 0.002 dB granularity. (R)
(optional) (4 * N bytes, where N is the number of distinct ONUs connected to
the S'/R' interface.)
Lower receive optical threshold: This attribute specifies the optical level that the RE uses
to declare the low received optical power alarm. Valid values are 127 dBm
(coded as 254) to 0 dBm (coded as 0) in 0.5 dB increments. The default value
0xFF selects the RE's internal policy. (R, W) (optional) (1 byte)
Upper receive optical threshold: This attribute specifies the optical level that the RE uses
to declare the high received optical power alarm. Valid values are 127 dBm
Transmit optical signal level: This attribute reports the current measurement of the mean
optical launch power of the upstream optical amplifier. Its value is a
granularity. (R) (optional) (2 bytes)
Lower transmit optical threshold: This attribute specifies the minimum mean optical
launch power that the RE uses to declare the low transmit optical power
Upper transmit optical threshold: This attribute specifies the maximum mean optical
launch power that the RE uses to declare the high transmit optical power
Actions
Get, get next, set
Test
Test the upstream amplifier. The test action can be used to perform optical
line supervision tests; refer to the test and test result message descriptions in
Annex A.
Notifications
Number
386
N/A
Op state
N/A
ARC
5..13
N/A
14..16
Reserved
Rec. ITU-T G.988 (10/2012)
Description
Operational state of RE upstream amplifier
Alarm
Alarm
number
Alarm
Description
Low received optical power Received upstream optical power of one or more ONUs
below threshold
High received optical power Received upstream optical power of one or more ONUs
above threshold
Low transmit optical power Transmit upstream optical power below lower threshold
High transmit optical power Transmit upstream optical power above upper threshold

S'/R' LOS
S'/R' LOS detected. No optical signal received at the S'/R'

upstream interface in 500 s
6..207
Reserved
Test result:

9.14.4 RE downstream amplifier

This managed entity organizes data associated with each optical amplifier for downstream data
supported by the RE. The management ONU automatically creates one instance of this managed
entity for each downstream optical amplifier:
when the RE has mid-span PON reach extender downstream optical amplifier ports built
into its factory configuration;
extender downstream optical amplifier type;
mid-span PON reach extender downstream optical amplifier type. Note that the installation
of a plug-and-play card may indicate the presence of a mid-span PON reach extender
downstream optical amplifier via equipment ID as well as its type attribute, and indeed may
cause the management ONU to instantiate a port mapping package to specify the ports
precisely.
neither provisioned to expect a mid-span PON reach extender downstream optical amplifier circuit
pack, nor is it equipped with a mid-span PON reach extender downstream optical amplifier circuit
pack.
Relationships
An instance of this managed entity is associated with a downstream optical amplifier and
with an instance of a circuit pack. If the reach extender includes OEO regeneration in either
direction, the RE downstream amplifier is also associated with an RE ANI-G. Refer to
clause 9.14.1 for further discussion.
Attributes
Its value indicates the physical position of the downstream optical amplifier.
The first byte is the slot ID (defined in clause 9.1.5 of [ITU-T G.984.4]). The
second byte is the port ID. (R) (mandatory) (2 bytes)
Rec. ITU-T G.988 (10/2012)
387
NOTE 1 this ME ID may be identical to that of an RE ANI-G if it shares the same

physical slot-port.
NOTE 2 When an RE supports multiple PONs, or protected access to a single
PON, its primary ANI-G cannot be completely shut down, due to a loss of the
management communications capability. Complete blocking of service and removal
of power may nevertheless be appropriate for secondary RE ANI-Gs. Administrative
lock suppresses alarms and notifications for both primary and secondary RE ANIGs. Administrative lock suppresses alarms and notifications for an RE downstream
amplifier, be it either primary or secondary.
(optional) (1 byte)
ARC:

Operational mode: This attribute indicates the operational mode.
0 Constant gain
1 Constant output power
2 Autonomous
(R,W) (mandatory) (1 byte)
Input optical signal level: This attribute reports the current measurement of the input
optical signal power of the downstream optical amplifier. Its value is a
Lower input optical threshold: This attribute specifies the optical level the RE uses to
declare the low received optical power alarm. Valid values are 127 dBm
Upper input optical threshold: This attribute specifies the optical level the RE uses to
declare the high received optical power alarm. Valid values are 127 dBm
Output optical signal level: This attribute reports the current measurement of the mean
optical launch power of the downstream optical amplifier. Its value is a
Lower output optical threshold: This attribute specifies the minimum mean optical launch
power that the RE uses to declare the low transmit optical power alarm. Its
value is a 2s complement integer referred to 1 mW (i.e., dBm), with 0.5 dB
granularity. The default value 0x7F selects the RE's internal policy. (R, W)
(optional) (1 byte)
Upper output optical threshold: This attribute specifies the maximum mean optical launch
power that the RE uses to declare the high transmit optical power alarm. Its
value is a 2s complement integer referred to 1 mW (i.e., dBm), with 0.5 dB
granularity. The default value 0x7F selects the RE's internal policy. (R, W)
(optional) (1 byte)
388
Rec. ITU-T G.988 (10/2012)
R'S' splitter coupling ratio: This attribute reports the coupling ratio of the splitter at the
R'/S' interface that connects the embedded management ONU and the
amplifiers to the optical trunk line. Valid values are 99:1 (coded as
99 decimal) to 1:99 (coded as 1 decimal), where the first value is the value
encoded and is the percentage of the optical signal connected to the amplifier.
The default value 0xFF indicates that there is no splitter connected to this
upstream/downstream amplifier pair. (R) (optional) (1 byte)
Actions
Get, set
Test the RE downstream amplifier. The test action can be used to perform
optical line supervision tests; refer to the test and test result message
descriptions in Annex A.
Test
Notifications
Number
Description
N/A
Op state
Operational state of RE downstream amplifier
ARC
4..12
N/A
13..16
Reserved
Alarm
Alarm
number
Alarm
Description
Low received optical power Received downstream optical power below threshold
High received optical power Received downstream optical power above threshold
Low transmit optical power Transmit downstream optical power below lower threshold
High transmit optical power Transmit downstream optical power above upper threshold
5..207

Reserved
Test result:

9.14.5 RE config portal

The RE config portal managed entity provides a way for the OLT to discover the configuration
delivered to an RE by a non-OMCI configuration method (SNMP, etc.). Text retrieved from this
ME is not required to be understood by the OLT or EMS, but it may be useful for human or vendorspecific analysis tools.
An instance of this managed entity may be created by an RE that supports non-OMCI RE
configuration. It is not reported during a MIB upload.
Rec. ITU-T G.988 (10/2012)
389
Relationships
One instance of this managed entity is associated with an instance of a TCP/UDP config
Attributes
There is one instance, number 0. (R) (mandatory) (2 bytes)
Configuration text table: This attribute is used to pass a textual representation of the RE
Upon ME instantiation, the management ONU sets this attribute to 0. (R)
(mandatory) (x bytes)
TCP/UDP pointer: This pointer associates the RE config portal with the TCP/UDP config
data ME to be used for communication with any valid and necessary in-band
protocol server. The default value is 0xFFFF. (R, W) (mandatory) (2 bytes)
Actions
Get, get next
Notifications
Number
Attribute value
change
Configuration text
N/A
3..16
Description
Indicates an update to the RE configuration from a non-OMCI
interface. Because the attribute is a table, the AVC does not
contain information about its value. The OLT must use the
get, get next action sequence if it wishes to obtain the updated
attribute content.
Reserved
9.14.6 RE common amplifier parameters

This managed entity organizes data associated with each optical amplifier supported by the reach
extender. The management ONU automatically creates one instance of this managed entity for each
upstream or downstream optical amplifier.
Relationships
An instance of this managed entity is associated with an instance of the RE downstream
amplifier or RE upstream amplifier ME.
Attributes
instance of an upstream or downstream optical amplifier. The first byte is the
slot ID (defined in clause 9.1.5). The second byte is the port ID.
NOTE The type of the linked ME can be determined by uniqueness of slot and
port.
390
Rec. ITU-T G.988 (10/2012)
Gain:
This attribute reports the current measurement of the optical amplifier's gain,
in dB. Its value is a 2s complement integer with 0.25 dB granularity, and with
a range from 32 dB to 31.5 dB. The value 0x7F indicates that the current
measured gain is 0, i.e., negative infinity in dB terms. (R) (optional) (1 byte)
Lower gain threshold: This attribute specifies the gain the RE uses to declare the low gain
alarm. Valid values are 0 dB (coded as 0x00) to 63.5 dB (coded as 0xFE).
The default value 0xFF selects the RE's internal policy. (R, W) (optional)
(1 byte)
Upper gain threshold: This attribute specifies the gain the RE uses to declare the high gain
alarm. Valid values are 0 dB (coded as 0x00) to 63.5 dB (coded as 0xFE).
The default value 0xFF selects the RE's internal policy. (R, W) (optional)
(1 byte)
Target gain: This attribute specifies the target gain, when the operational mode of the
parent RE downstream or upstream amplifier is set to constant gain mode.
Valid values are 0 dB (coded as 0x00) to 63.5 dB (coded as 0xFE). The
Device temperature: This attribute reports the temperature in C of the active device (SOA
or pump) in the optical amplifier. Its value is a 2s complement integer with
granularity 1/256 C. (R) (optional) (2 bytes)
Lower device temperature threshold: This attribute is a 2s complement integer that
specifies the temperature the RE uses to declare the low temperature alarm.
Valid values are 64 to +63 C in 0.5 C increments. The default value 0x7F
selects the RE's internal policy. (R, W) (optional) (1 byte)
Upper device temperature threshold: This attribute is a 2s complement integer that
specifies the temperature the RE uses to declare the high temperature alarm.
Valid values are 64 to +63 C in 0.5C increments. The default value 0x7F
selects the RE's internal policy. (R, W) (optional) (1 byte)
Device bias current: This attribute contains the measured bias current applied to the SOA
or pump laser. Its value is an unsigned integer with granularity 2 mA. Valid
values are 0 mA to 512 mA. (R) (optional) (1 byte)
Amplifier saturation output power: This attribute reports the saturation output power of
the amplifier as specified by the manufacturer. Its value is an unsigned
integer referred to 1 mW (i.e., dBm), with 0.1 dB granularity. (R) (optional)
(2 bytes)
Amplifier noise figure: This attribute reports the intrinsic noise figure of the amplifier, as
specified by the manufacturer. Its value is an unsigned integer with 0.1 dB
granularity (R) (optional) (1 byte)
Amplifier saturation gain: This attribute reports the gain of the amplifier at saturation, as
specified by the manufacturer. Its value is an unsigned integer with 0.25 dB
granularity, and with a range from 0 dB to 63.75 dB. (R) (optional) (1 byte)
Actions
Get, set
Rec. ITU-T G.988 (10/2012)
391
Notifications
Alarm
Alarm
number
Alarm
Description
Low gain
Gain below lower threshold
High gain
Gain above upper threshold
Low temperature
Device temperature below lower threshold
High temperature
Device temperature above upper threshold
High bias current
Device bias current above threshold determined by vendor;

device end of life pending
High temperature shutdown Device has shut down due to temperature exceeding
manufacturer's specifications
High current shutdown
7..207
Device has shut down due to bias current exceeding

manufacturer's specifications
Reserved
10
11
ONU management and control protocol
11.1
Baseline and extended messages
This clause defines two formats for OMCI messages, baseline and extended.
G-PON and XG-PON systems are free to use either the baseline or the extended OMCI message
format. The baseline format is the default at initialization. Use of the extended format is then
negotiated between the OLT and ONU.
The conventions for the use of baseline and extended messages by systems complying with other
Recommendations are for further study.
Baseline messages have 48-byte fixed length PDUs, while extended messages have variable length
PDUs. A receiver that does not support extended messages may therefore reject an extended
message based on nothing more than their length.
Both baseline and extended messages carry a message integrity check (MIC) in their final four
bytes. This facilitates ad hoc recovery of both message types by a receiver. In ITU-T G.984
systems, the MIC is an ITU-T I.363.5 CRC; in ITU-T G.987 systems, the MIC is a cryptographic
hash as specified in [ITU-T G.987.3].
Baseline and extended messages are distinguished from one another by the device identifier field,
which is in the same byte location in both message types. Baseline messages contain device
identifier 0x0A, while extended messages employ device identifier 0x0B.
All G-PON ONUs and OLTs are required to support the baseline format. During initialization, and
whenever the ONU is re-ranged onto the PON, both entities use the baseline format to establish
communications and to negotiate their capabilities. If both endpoints support extended messages,
they may or may not choose to conduct all or some subsequent communications in the extended
message set. Baseline messages may be used for any transaction, that is, any exchange of one or
more related messages such as a get/get-next sequence.
392
Rec. ITU-T G.988 (10/2012)
Figure 11.1-1 illustrates the negotiation and the exchange of messages in one or the other message
format.
OLT
ONU
Alarm A (ME, parameters)

Subscript A designates a baseline
message set. B designates
an extended message set.
The OLT queries ONU capabilities before it
is allowed to use extended messages.
The ONU must use message set A in

autonomous notifications unless it has
received a message set B command from
the OLT during current session.
GetA (ONU2-G, OMCC version)

Get response A(ONU2-G, OMCC version supports the extended message set)
If an extended message set is not supported by the ONU,
the OLT may not use the extended
message set.
If the extended message set is supported by the ONU,
the OLT may use either message set at will.
OMCI message B ( parameters )
OMCI responseB ( parameters )
The ONU uses message set B in response
to message set B command.
The ONU is allowed to use message set B in
autonomous notifications only if it has
received a message set B command from
the OLT during current session.
Alarm B (ME, parameters)
OMCI message A ( parameters )
OMCI responseA ( parameters )
Even though an extended message set has been negotiated,
the OLT may use a baseline message set.
The ONU responds with baseline messages.
G.988(12)_F11.1-1
Figure 11.1-1 G-PON OMCI message set negotiation

If a G-PON OLT has a priori knowledge that the ONU supports the extended message set, it may
choose to omit the query step. However, a G-PON ONU may not transmit extended messages,
including autonomous notifications, until it has received at least one extended message from the
OLT during the current session (since initialization or re-activation on the PON).
11.2
Common message characteristics
Each OMCI protocol packet is encapsulated directly in one GEM frame, or several GEM frames if
necessary to satisfy the normal fragmentation rules. The GEM frame header contains the OMCC
port-ID.
Table 11.2-1 shows the baseline message format. The packet has a fixed length of 48 bytes.
Rec. ITU-T G.988 (10/2012)
393
Table 11.2-1 Baseline OMCI message format

Byte number
Size
Use
1..2
Transaction correlation identifier
Message type
Device identifier
5..8
Managed entity identifier
9..40
32
Message contents
41..48
OMCI trailer
Table 11.2-2 shows the extended message format. The packet has variable length N, up to 1980
bytes.
Table 11.2-2 Extended OMCI message format
Byte number
Size
Use
1..2
Transaction correlation identifier
Message type
Device identifier
5..8
Managed entity identifier
9..10
Message contents length
11..(N-4)
Message contents
(N-3)..N
Message integrity check (MIC)
The following clauses specify each field of these messages.

11.2.1 Transaction correlation identifier
The transaction correlation identifier is used to associate a request message with its response
message. For request messages, the OLT selects a transaction identifier, an arbitrary value that
should be chosen to avoid the possibility of ambiguous responses from ONUs. A response message
carries the transaction identifier of the message to which it is responding. The transaction identifier
of messages generated autonomously by an ONU is 0.
As explained in clause B.2.2, and for the baseline message format only, the most significant bit of
the transaction correlation identifier indicates the priority of the message. The following coding is
used: 0 = low priority, 1 = high priority. The OLT decides whether a command should be executed
with low or high priority. The extended message format does not recognize priorities.
11.2.2 Message type
The message type field is subdivided into four parts. These are shown in Figure 11.2.2-1.
Bit
8
0
7
AR
6
AK
1
MT
Figure 11.2.2-1 Message type field subdivision

Bit 8, the most significant bit, is reserved for future use, and is always 0.
394
Rec. ITU-T G.988 (10/2012)
Bit 7, acknowledge request (AR), indicates whether or not the message requires an
acknowledgement. An acknowledgement is a response to an action request, not a link layer
handshake. If an acknowledgement is expected, this bit is set to 1. If no acknowledgement is
expected, this bit is 0. In messages sent by the ONU, this bit is always 0.
Bit 6, acknowledgement (AK), indicates 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 to a command, this bit is set to 0. In messages sent by the OLT, this bit is always 0.
Bits 5..1, message type (MT), indicate the message type, as defined in Table 11.2.2-1. Values not
shown in the table are reserved.
Table 11.2.2-1 OMCI message types
MT
Type
Purpose
AK
Increment
MIB data
sync
Create
Create a managed entity instance with its

attributes
Yes
Yes
Delete
Delete a managed entity instance
Yes
Yes
Set
Set one or more attributes of a managed entity
Yes
(Note 1)
Get
Get one or more attributes of a managed entity.

When directed to a table attribute, get causes the
ONU to latch a copy of the table for retrieval
with a sequence of get next commands.
Yes
No
11
Get all alarms
Latch the alarm statuses of all managed entities

and reset the alarm message counter
Yes
No
12
Get all alarms next
Get the active alarm status of the next managed

entity or entities from the latched alarm status
copy
Yes
No
13
MIB upload
Latch a copy of the MIB. Some MEs and some

attributes are not included in a MIB upload.
Yes
No
14
MIB upload next
Get the next set of attributes of the managed

entity instances included in the latched MIB copy
Yes
No
15
MIB reset
Clear the MIB, re-initialize it to its default, and

reset the MIB data sync counter to 0
Yes
No
16
Alarm
Notification of an alarm or a threshold crossing

alert
No
No
17
Attribute value
change
Autonomous notification of an attribute value

change
No
No
18
Test
Request a test on a specific managed entity
Yes
No
19
Start software
download
Start a software download action
Yes
Yes
20
Download section
Download a section of a software image
(Note 2)
No
21
End software
download
End of a software download action
Yes
Yes
22
Activate software
Activate the downloaded software image
Yes
Yes
23
Commit software
Commit the downloaded software image
Yes
Yes
24
Synchronize time
Synchronize PM interval time between OLT and

ONU
Yes
No
Rec. ITU-T G.988 (10/2012)
395
Table 11.2.2-1 OMCI message types

MT
Type
Purpose
AK
Increment
MIB data
sync
25
Reboot
Reboot ONU or circuit pack
Yes
No
26
Get next
Get the latched attribute values of the managed

entity within the current snapshot
Yes
No
27
Test result
Notification of result initiated by a test command
No
No
28
Get current data
Get current counter value associated with one or

more attributes of a performance monitoring
managed entity
Yes
No
29
Set table (Note 3)
Set one or more rows of a table
Yes
Yes
NOTE 1 MIB sync is incremented if a set action successfully updates any of the attributes specified,
even if some other attributes of the same set action were to fail.
NOTE 2 The download section action is acknowledged only for the last section within a window. See
clause I.3.
NOTE 3 Set table is defined only in the extended message set.
11.2.3 Device identifier

In baseline OMCI messages, this field is defined to be 0x0A.
In extended OMCI messages, this field is defined to be 0x0B.
All other values are reserved.
11.2.4 Managed entity identifier
The managed entity identifier comprises four bytes. The most significant two bytes of the managed
entity identifier field designate the managed entity class value of the target managed entity. The
maximum number of possible managed entity classes is thus 65535 (0 is not used). The least
significant two bytes of the managed entity identifier field identify the managed entity instance.
Depending on the managed entity class, there may be none, one (e.g., ONU-G) or several (e.g.,
MAC bridge port config data) instances in an ONU.
Table 11.2.4-1 specifies the managed entities and their class values in the OMCI.
NOTE This table contains all managed entity classes ever standardized for the OMCI, including
[ITU-T G.983.2] and [ITU-T G.984.4], as well as features now deprecated. These class values remain
assigned to their original values.
Table 11.2.4-1 Managed entity identifiers

Managed entity
class value
396
Managed entity
ONTB-PON
ONU data
PON IF line cardholder
PON IF line card
Cardholder
Circuit pack
Rec. ITU-T G.988 (10/2012)

Managed entity
class value
Managed entity
Software image
UNIB-PON
TC AdapterB-PON
10
Physical path termination point ATM UNI
11
12
13
Logical N x 64 kbit/s sub-port connection termination point
14
Interworking VCC termination point
15
AAL1 profileB-PON
16
AAL5 profile
17
AAL1 protocol monitoring history dataB-PON
18
AAL5 performance monitoring history data
19
AAL2 profile
20
(Intentionally left blank)
21
CES service profile
22
(Reserved)
23
CES physical interface performance monitoring history data
24
Ethernet performance monitoring history data
25
VP network CTPBPON
26
ATM VP cross-connection
27
Priority queueB-PON
28
DBR/CBR traffic descriptor
29
UBR traffic descriptor
30
SBR1/VBR1 traffic descriptor
31
32
33
ABR traffic descriptor
34
GFR traffic descriptor
35
ABT/DT/IT traffic descriptor
36
UPC disagreement monitoring history dataB-PON
37
(Intentionally left blank)
38
ANI (B-PON)
39
PON TC adapter
40
PON physical path termination point
41
TC adapter protocol monitoring history data
42
Threshold dataB-PON
43
Operator specific
Rec. ITU-T G.988 (10/2012)
397

Managed entity
class value
398
Managed entity
44
Vendor specific
45
46
47
48
49
50
51
MAC bridge performance monitoring history data
52
MAC bridge port performance monitoring history data
53
Physical path termination point POTS UNI
54
Voice CTP
55
Voice PM history data
56
AAL2 PVC profileB-PON
57
AAL2 CPS protocol monitoring history dataB-PON
58
59
LES service profile
60
AAL2 SSCS parameter profile1
61
AAL2 SSCS parameter profile2
62
VP performance monitoring history data
63
Traffic schedulerB-PON
64
T-CONT buffer
65
UBR+ traffic descriptor
66
AAL2 SSCS protocol monitoring history dataB-PON
67
IP port configuration data
68
IP router service profile
69
IP router configuration data
70
IP router performance monitoring history data 1
71
IP router performance monitoring history data 2
72
ICMP performance monitoring history data 1
73
ICMP performance monitoring history data 2
74
IP route table
75
IP static routes
76
ARP service profile
77
ARP configuration data
78
VLAN tagging operation configuration data
79
80
Physical path termination point ISDN UNI
Rec. ITU-T G.988 (10/2012)

Managed entity
class value
Managed entity
81
(Reserved)
82
Physical path termination point video UNI
83
Physical path termination point LCT UNI
84
85
ONUB-PON
86
ATM VC cross-connection
87
VC network CTPB-PON
88
VC PM history data
89
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 performance monitoring history data
97
802.11 PHY FHSS DSSS IR tables
98
99
100
xDSL line inventory and status data part 1
101
102
xDSL channel downstream status data
103
xDSL channel upstream status data
104
105
106
107
xDSL channel configuration profile
108
xDSL subcarrier masking downstream profile
109
xDSL subcarrier masking upstream profile
110
xDSL PSD mask profile
111
xDSL downstream RFI bands profile
112
xDSL xTU-C performance monitoring history data
113
xDSL xTU-R performance monitoring history data
114
xDSL xTU-C channel performance monitoring history data
115
xDSL xTU-R channel performance monitoring history data
116
TC adaptor performance monitoring history data xDSL
117
Physical path termination point VDSL UNI ([ITU-T G.993.1] VDSL1)
Rec. ITU-T G.988 (10/2012)
399

Managed entity
class value
400
Managed entity
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 performance monitoring history data
130
IEEE 802.1p mapper service profile
131
OLT-G
132
Multicast interworking VCC termination point
133
ONU power shedding
134
IP host config data
135
IP host performance monitoring history data
136
TCP/UDP config data
137
Network address
138
VoIP config data
139
VoIP voice CTP
140
Call control performance monitoring history data
141
VoIP line status
142
VoIP media profile
143
RTP profile data
144
RTP performance monitoring history data
145
146
147
148
Authentication security method
149
SIP config portal
150
151
SIP agent performance monitoring history data
152
SIP call initiation performance monitoring history data
153
SIP user data
154
MGC config portal
Rec. ITU-T G.988 (10/2012)

Managed entity
class value
Managed entity
155
MGC config data
156
MGC performance monitoring history data
157
Large string
158
ONU remote debug
159
Equipment protection profile
160
161
Port mapping packageBPON (B-PON only; use 297 for G-PON)
162
163
MoCA Ethernet performance monitoring history data
164
MoCA interface performance monitoring history data
165
VDSL2 line configuration extensions
166
167
168
VDSL2 line inventory and status data part 1
169
170
171
Extended VLAN tagging operation configuration data
172..239
Reserved for future B-PON managed entities
240-255
Reserved for vendor-specific managed entities
256
ONU-G (NOTE In [ITU-T G.984.4] this was called ONT-G)
257
ONU2-G (NOTE In [ITU-T G.984.4] this was called ONT2-G)
258
ONU-G (deprecated note that the name is re-used for code point 256)
259
ONU2-G (deprecated note that the name is re-used for code point 257)
260
PON IF line card-G
261
PON TC adapter-G
262
T-CONT
263
ANI-G
264
UNI-G
265
ATM interworking VCC termination point
266
267
GEM port performance monitoring history data (obsolete)
268
269
VP network CTP
270
VC network CTP-G
271
GAL TDM profile (deprecated)
272
273
Threshold data 1
Rec. ITU-T G.988 (10/2012)
401

Managed entity
class value
402
Managed entity
274
Threshold data 2
275
GAL TDM performance monitoring history data (deprecated)
276
GAL Ethernet performance monitoring history data
277
Priority queue
278
Traffic scheduler
279
Protection data
280
Traffic descriptor
281
282
283
284
285
Pseudowire performance monitoring history data
286
287
OMCI
288
Managed entity
289
Attribute
290
Dot1X port extension package
291
Dot1X configuration profile
292
Dot1X performance monitoring history data
293
Radius performance monitoring history data
294
TU CTP
295
TU performance monitoring history data
296
297
298
Dot1 rate limiter
299
Dot1ag maintenance domain
300
Dot1ag maintenance association
301
Dot1ag default MD level
302
Dot1ag MEP
303
Dot1ag MEP status
304
Dot1ag MEP CCM database
305
Dot1ag CFM stack
306
Dot1ag chassis-management info
307
Octet string
308
General purpose buffer
309
Multicast operations profile
310
Multicast subscriber config info
Rec. ITU-T G.988 (10/2012)

Managed entity
class value
Managed entity
311
Multicast subscriber monitor
312
FEC performance monitoring history data
313
RE ANI-G
314
Physical path termination point RE UNI
315
RE upstream amplifier
316
RE downstream amplifier
317
RE config portal
318
File transfer controller
319
CES physical interface performance monitoring history data 2
320
CES physical interface performance monitoring history data 3
321
Ethernet frame performance monitoring history data downstream
322
Ethernet frame performance monitoring history data upstream
323
VDSL2 line configuration extensions 2
324
xDSL impulse noise monitor performance monitoring history data
325
326
327
328
RE common amplifier parameters
329
330
Generic status portal
331
ONU-E
332
Enhanced security control
333
MPLS pseudowire termination point
334
Ethernet frame extended PM
335
SNMP configuration data
336
ONU dynamic power management control
337
PW ATM configuration data
338
PW ATM performance monitoring history data
339
PW Ethernet configuration data
340
BBF TR-069 management server
341
GEM port network CTP performance monitoring history data
342
TCP/UDP performance monitoring history data
343
Energy consumption performance monitoring history data
344
XG-PON TC performance monitoring history data
345
XG-PON downstream management performance monitoring history data
346
XG-PON upstream management performance monitoring history data
347
Rec. ITU-T G.988 (10/2012)
403

Managed entity
class value
Managed entity
348
MAC bridge port ICMPv6 process pre-assign table
349
PoE control
350-399
Reserved for vendor-specific use
400
Ethernet pseudowire parameters
401-65279
65280-65535

Reserved for vendor-specific use
11.2.5 Message contents length, extended message format

These two bytes contain the length, in bytes, of the message contents field. Its value lies between 0
and 1966, for a 1980-byte PDU limit.
Eleven bits suffice to specify this range. The five most significant bits of this field are reserved for
future use.
From time to time, new parameters may be added to OMCI messages. The rules for the extended
message set are as follows:
For backward compatibility, any new field must be added at the end of the OMCI message,
they must be optional (and be documented as such), with the default value 0 that has
backward compatible semantics.
Trailing optional fields in a message may be omitted or included at the option of the
transmitting device. The transmitting device sets the message contents length field
accordingly.
The receiving device should not reject the message on the grounds of unexpected message
contents length.
A receiving device that does not support the optional trailing fields should ignore them.
The OLT must be prepared to accept a response based on the premise that the ONU does
not support the optional fields, whether the optional fields are in the transmitted command
message or in the received response message or both. In such a case, the value in the
received response message contents length field will be lower than expected.
11.2.6 Message contents
The layout of the message contents field is specific to each message type. The detailed layout of all
messages appears in Annex A.
11.2.7 OMCI trailer, baseline message format
The eight bytes of this field are based on the AAL5 trailer definition:
a)
The first two bytes correspond to CPCS-UU and CPI. They are set to 0 at the transmitter
and ignored at the receiver.
b)
The length of the CPCS-SDU field is set to 0x0028 (40 decimal).
c)
In ITU-T G.984 applications, the MIC is a 32-bit CRC as specified in [ITU-T I.363.5]. In
ITU-T G.987 applications, the MIC is as specified in [ITU-T G.987.3].
404
Rec. ITU-T G.988 (10/2012)
11.2.8 MIC, extended message format

The integrity of an extended format OMCI message is verified by this four-byte field. In
ITU-T G.984 systems, the MIC is a 32-bit CRC as specified in [ITU-T I.363.5]. In ITU-T G.987
systems, the MIC is as specified in [ITU-T G.987.3].
11.2.9 Message limits
Baseline OMCI messages impose limits on the size of attributes. Table 11.2.9-1 lists the important
limits.
Table 11.2.9-1 OMCI baseline message limitations
Item
Limited by
Maximum
size, bytes
Total size of set-by-create attributes (including ME ID)
Create
34
Size of (R) or (R,W) simple attribute
Get response
25
Size of (R) or (R,W) structured table entry (Note)
Set
30
Total size of a get
Get response
25
Total size of a get current data
Get current data response
25
NOTE A structured table is one that contains distinct and separable rows, each row of which has the
same syntax as the others. Long strings of bytes are also designated tables in clause 9, because the
mechanism for retrieval is the same: get, followed by a number of get next commands. Such a byte string
could be regarded as a table with but a single row, the length of which is limited only by the number of get
next commands that can be specified. There is no way to set a value into such a byte string, however, so
these attributes are necessarily read-only.
Extended messages are limited by the total size of the PDU, and there is no possibility that a get or
set or create message, even with a maximum number (16) of maximum length (25-byte) attributes
can exceed the message size limit. For backward compatibility, attribute definitions remain within
the size limits of baseline messages, but a single extended message may contain more attributes
than a baseline message.
In cases where compatibility with [ITU-T G.984.4] is not required, future MEs are not intrinsically
subject to these constraints. However, the evolution of common code encourages that attributes
longer than 25 bytes be designated as table attributes, and that the get and get-next sequence be used
to retrieve tables.
The following considerations apply to baseline messages only. The larger PDU eliminates the
possibility of message length violation in the extended message set.
It is important that OLT and ONU implementations take size limits into account. For example, it is
easy to form a (baseline) get command that asks the ONU to return more attributes than can fit into
a (baseline) get response message. If the OLT asks for too many attributes in a get request, the ONU
may respond with as many attributes as fit into the space available. From the attribute-present mask,
the OLT can parse the attributes that were sent correctly, and can issue another get to retrieve the
attributes that did not fit.
While this is the preferred behaviour, an alternate interpretation is that the ONU would return a
parameter error code when it receives a (baseline) get request whose response does not completely
fit into one (baseline) get response message. For the sake of interoperability, the expected behaviour
between an OLT and ONU with different interpretations is provided below:
Case 1. The ONU reports a parameter error, and the OLT expects a partial list. If this happens, the
OLT should react by simplifying its get request. The ONU then responds without an error.
Rec. ITU-T G.988 (10/2012)
405
Case 2. The ONU provides a partial list, while the OLT expects to get an error. The OLT receives a
normal message and processes it normally. The OLT asks again for any attributes it did not
get.
11.2.10 Test result enumeration
Test actions can return measurements of various physical parameters in vendor-specific ways.
Table 11.2.10-1 identifies parameters that may be of interest, with enumerated values to represent
them in the test response message defined in Annex A.
The resolution shown in the following descriptions merely indicates the weight attached to the least
significant bit, and is not intended to impose requirements for precision or accuracy of the measured
value.
Table 11.2.10-1 Codes to represent measured values
Type
Parameter
Power feed voltage, V
DC voltage, 2s complement, 20 mV resolution
Low voltage, V
DC voltage, 2s complement, 100 V resolution
Received optical power, dB
dBW, 2s complement, 0.002 dB resolution
Received optical power, W
Power, unsigned integer, 0.1 W resolution
Transmitted optical power, dBW
dBW, 2s complement, 0.002 dB resolution
Transmitted optical power, W
Power, unsigned integer, 0.1 W resolution
Video level, dBmV
dBmV, 2s complement, 0.002 dB resolution
Video level, V
RF voltage, unsigned integer, 200 V

resolution. May be filtered or weighted in
accordance with vendor-specific needs.
Laser bias current
Unsigned integer, 2 A resolution
10
Received voice signal quality measure Q
Unsigned integer, resolution 0.1
11
Signal-to-noise ratio, dB
Unsigned integer, resolution 0.1 dB
12
Temperature, degrees C
2s complement, 1/256 degree C resolution
13..239
240-254
Not to be standardized. Available for

vendor use.
255
406
Representation
Reserved
Rec. ITU-T G.988 (10/2012)
Indicates an unavailable field in an ordered list

of response values.
Annex A
OMCI message syntax and common features
(This annex forms an integral part of this Recommendation.)
A.1
General
A.1.1
Result and reason
Responses to commands can indicate the result of the command. A zero value indicates that the
command was processed successfully. Non-zero values indicate the reason for the failure. If the
result was failure, the rest of the message contents may provide details of the failure, may be filled
with all 0, or in the extended message set, may simply be omitted. The definition of each result and
reason appears in Table A.1.1-1.
Table A.1.1-1 Result and reason codes
Code
Headline
Description
0000
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 ONU's command interpretation function
without errors and that the interpreted command was
successfully transferred to the ONU's command execution
function.
0001
Command processing error
This result means the command processing failed at the ONU

for reasons not described by one of the more specific error
codes.
0010
Command not supported
This result means that the message type indicated in byte 3 is

not supported by the ONU.
0011
Parameter error
This result means that the command message received by the

ONU was errored. It would be appropriate if an attribute mask
were out of range, for example. In practice, this result code is
frequently used interchangeably with code 1001. However, the
optional attribute and attribute execution masks in the reply
messages are only defined for code 1001.
0100
Unknown managed entity
This result means that the managed entity class (bytes 5..6) is
not supported by the ONU.
0101
Unknown managed entity

instance
This result means that the managed entity instance (bytes 7..8)
does not exist in the ONU.
0110
Device busy
This result means that the command could not be processed due
to process-related congestion at the ONU. This result code may
also be used as a pause indication to the OLT while the ONU
conducts a time-consuming operation such as storage of a
software image into non-volatile memory.
0111
Instance exists
This result means that the ONU already has a managed entity
instance that corresponds to the one the OLT is attempting to
create.
Rec. ITU-T G.988 (10/2012)
407
Table A.1.1-1 Result and reason codes

Code
Headline
Description
1001
Attribute(s) failed or unknown
This result means that an optional attribute is not supported by

the ONU or that a mandatory/optional attribute could not be
executed by the ONU, even if it is supported, for example,
because of a range or type violation. In 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;
Attribute execution mask coding, which indicates whether or
not the mandatory/optional attribute was executed.
See the set response and get response message layouts (see
clauses A.2.6, A.3.6, A.2.8 and A.3.8) for the placement of
these masks.
If one or more optional attributes are not supported by the
ONU, 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 ONU, the optional attribute mask coding
remains 0, while the attribute execution mask coding becomes 1
for each failed attribute.
If the ONU could not latch copies of all specified table
attributes, for example, because of insufficient memory, the
attribute execution mask is set to 1 for each attribute that does
not have a latched copy available for get next retrieval.
When the result-reason code in a response message indicates an exception (that is, its value is not
0), the response message is permitted to include vendor-specific additional information. The rules
for additional error information are:
1.
Additional error information is optional for the ONU to insert.
2.
Additional information may or may not be represented in textual form.
3.
The semantics of additional error information are specific to the ONU vendor.
4.
The ONU must not rely on the OLT being able to detect or interpret additional error
information.
5.
Additional error information may occupy only padding bytes (baseline message set) or only
uncommitted trailing bytes (extended message set).
6.
In get, get current data and get next responses, the attribute mask controls the padding
definition.
7.
No additional error information is permitted in responses to start download and end
download messages that are directed to multiple target MEs, as indicated by 0xFFFF in the
target ME identifier.
These rules are defined with a view to maximizing the simplicity of an implementation.
408
Rec. ITU-T G.988 (10/2012)
A.1.2
Table attributes
Normal attributes are coded such that they do not exceed the maximum OMCI attribute size, as
limited by the baseline message format. However, there are cases where attributes need to be larger
because they comprise arrays of data. In other cases, the attribute may be unstructured, but
nevertheless be too large to be represented as a conventional attribute. Both types of large attributes
are known as tables, and can be identified by the word table in their names.
A table entry may be short enough that more than one row would fit into a (baseline) set command.
However, the set command has no deterministic way to specify how many such rows are present.
Therefore, the set action is permitted to set only a single entry in the table, the size of which is
specified in clause 9 for the particular attribute in question.
The set operation on a table row is possible only when individual table entries have a fixed size that
does not exceed the maximum that can be conveyed in the (baseline) set message. A table attribute
with variable-length rows or longer fixed-length rows is restricted to being read-only.
NOTE 1 Future managed entity definitions may relax the attribute size restrictions if baseline message set
compatibility is not required. This is a matter for further study.
An optional set table command is defined in the extended message set. Functionally, the set table
command is the equivalent of an ordered sequence of set commands, each directed to the same table
attribute of a given managed entity. As with the set command, table rows must have a fixed length,
and because of the backward compatibility requirement, no table row may exceed the baseline
length limit.
The actual size of any given table attribute instance at any given time may be smaller than the
OMCI single-message limit. Regardless of its actual size, however, the following sequence governs
the retrieval of all table attributes.
Figure A.1.2-1 shows how the OLT retrieves a table attribute. The OLT sends a get command, just
as for any other attribute. The ONU latches a copy of the table for the anticipated get next sequence.
In the get response, the ONU returns, not the value of the table attribute, but a four-byte field
containing the table's size, expressed in bytes.
NOTE 2 Zero is a valid size for many table attributes.
The OLT then requests the attribute data from the ONU via the appropriate number of get next
commands. There is no structure in the get next response; it simply regards the table as a byte
string.
Rec. ITU-T G.988 (10/2012)
409
OLT
ONU
The OLT requests size

of a table attribute.
Get (ME (table attribute))
The ONU makes a copy of the attribute and
returns the size of the copy in bytes.
Get response (table attribute size)
The OLT uploads table attribute through an
appropriate number of get next commands.
Get next (ME (table attribute, sequence = 0))
Get next response (first N bytes of table)
During the get next sequence, the ONU can
send AVCs. The OLT records the update in
its image of the ONUs state.
During the get next sequence, the OLT can
send configuration commands. The ONU
updates its MIB or its state and responds to
the OLT. These commands do not affect the
copy of the table attribute being uploaded.
Get next (ME (table attribute, sequence = k [Note]))
Get next response (final M bytes of table)
G.988(12)_FA.1.2-1
NOTE k + 1 is the number of get next commands as derived by the OLT to retrieve the complete table. For baseline
OMCI messages, each get next response contains 29 bytes; for extended OMCI messages, up to 1966 bytes (1980
maximum PDU size 14 bytes of OMCI header) are returned in a full-length response.
Figure A.1.2-1 Get a table attribute

The OLT issues as many get next requests as are needed to accommodate the size of the table
attribute. As illustrated in Figure A.1.2-2, the ONU returns a parameter error response if the OLT
overruns the size of the table attribute copy.
OLT
ONU
Get (ME (table attribute))
Get response (table attribute size)
Get next (ME (table attribute, sequence = 0))
Get next response (first N bytes of table)
Get next (ME (table attribute, sequence = k))
Get next response (final M bytes of table)
The OLT erroneously issues an

additional get next command.
Get next (ME (table attribute, sequence = k))
Get next response (result-reason 0011 = parameter error)
G.988(12)_FA.1.2-2
Figure A.1.2-2 OLT overruns table attribute size
410
Rec. ITU-T G.988 (10/2012)
The maximum time between two get next requests is 60 seconds. If the OLT does not send a get
next request within 60 seconds of the previous get next request or after the initial get request, the
ONU assumes the get attribute transaction has terminated, discards its copy of the table attribute,
and denies further get next requests directed to that attribute, again with a parameter error
result-reason code.
Capturing snapshots of multiple large tables could exhaust the limited memory resources of the
ONU. Within any one ONU, the OLT should get and get-next only one table attribute at a time. If
more than one table attribute is selected in the get command attribute mask, the ONU may reject the
command with an attributes failed or unknown result-reason code.
If more than one bit is set in the get-next command attribute mask, or if the specified attribute is not
a table, the ONU should respond with a parameter error result code.
In each get next command, the OLT generates a sequence number, starting from 0. The sequence
number resets to 0 for each attribute, even if successive attributes are part of the same managed
entity parent.
A.1.3
Get, get response, create response, and set messages
For an attribute mask, a bit map is used in the get, get response, create response, and set messages.
This bit map indicates which attributes are requested (get) or provided (get response and set). The
bit map is composed as follows:
Bit
Byte
8
Attribute 1
Attribute 2
Attribute 3
Attribute 4
Attribute 5
Attribute 6
Attribute 7
Attribute 8
Attribute 9
Attribute 10
Attribute 11
Attribute 12
Attribute 13
Attribute 14
Attribute 15
Attribute 16
Attribute numbers correspond to the ordering of the attributes in clause 9. The managed entity
identifier, which is an attribute of each managed entity, has no corresponding bit in the attribute
mask. Thus, attributes are counted starting from the first attribute after the managed entity
identifier.
A.1.4
Alarm notifications
The ONU sends this notification each time an alarm status changes for the entity indicated in the
managed entity identifier message field. The message shows the status of all alarms of this entity. It
is up to the OLT to determine which alarm status has changed. The alarm message also reports
declarations and cancellations of PM threshold crossing alerts.
The maximum number of alarms supported by the OMCI for a given managed entity instance is 224
because of the available message field of the baseline get all alarm next message. The bit map is
composed as follows:
Bit
Byte
8
Alarm 0
Alarm 1
Alarm 2
Alarm 3
Alarm 4
Alarm 5
Alarm 6
Alarm 7
Alarm 8
Alarm 9
Alarm 10
Alarm 11
Alarm 12
Alarm 13
Alarm 14
Alarm 15
Alarm 216
Alarm 217
Alarm 218
Alarm 219
Alarm 220
Alarm 221
Alarm 222
Alarm 223
28
Alarm numbers correspond to the alarm coding or threshold coding in clause 9 (no ME class
declares both alarms and TCAs). Bits in the alarm bit map that correspond to non-existing alarms
Rec. ITU-T G.988 (10/2012)
411
are always set to 0. Bits that correspond to defined alarms are set to 0 to indicate that the
corresponding alarm is cleared or to 1 to indicate that the alarm is currently active.
Alarm message sequence numbers can take values in the interval 1 to 255. Zero is excluded in order
to make this counter similar to the MIB data sync counter.
A.1.4.1
Alarm sequence number increase
The ONU informs the OLT of alarm status changes by sending alarm status change notifications.
These notifications are sent in unacknowledged messages that carry an eight-bit alarm sequence
number so that the OLT can detect loss of alarm notifications. Use cases are illustrated in
figures A.1.4.1-1 to A.1.4.1-3.
After a restart of the ONU, the alarm sequence number is reset, so that the first alarm notification
sent by the ONU will have an alarm sequence number equal to 1. The alarm sequence number is
incremented for each alarm notification and wraps around from 255 to 1. No alarm notification ever
has the sequence number 0.
OLT
ONU
A fault occurs. The ONU updates its alarm
table and increments the alarm sequence number.
The ONU sends an alarm notification to the OLT.
Alarm [any ME] (instance, alarm mask)
The OLT updates its alarm table and alarm

sequence number. The alarm tables in
the OLT and ONU are aligned.
G.988(12)_FA.1.4.1-1
Figure A.1.4.1-1 Increment of alarm sequence number at the ONU and OLT
OLT
ONU
A fault occurs. The ONU updates its

alarm table and increments the alarm
sequence number. The ONU is unable
to send an alarm notification to the OLT.
Alarm [any ME] (instance, alarm mask)
The alarm tables in the OLT and ONU
are not aligned. They will become aligned only
after an alarm resynchronization process.
G.988(12)_FA.1.4.1-2
Figure A.1.4.1-2 Alarm sequence number fails to stay in sync

When alarms are suppressed by ARC (clause A.1.4.3), the alarm is recorded by the ONU, but no
alarm message is sent. Therefore, the alarm sequence number is not incremented.
412
Rec. ITU-T G.988 (10/2012)
OLT
ONU
A fault occurs. The ONU updates its

alarm table but does not increment its alarm
sequence number. The ONU does not
send an alarm notification to the OLT.
G.988(12)_FA.1.4.1-3
Figure A.1.4.1-3 No increment of alarm sequence number at the ONU and OLT under ARC
A.1.4.2
Alarm audit and resynchronization
At initialization, periodically, or when the OLT detects a gap in the alarm sequence number, it
reconciles its view of the ONU's alarm status by sending a get all alarms command targeted at the
ONU data ME, as shown in Figure A.1.4.2-1.
When it receives the get all alarms request, the ONU resets the alarm sequence number to zero.
If the OLT sets the alarm retrieval mode indicator in the get all alarms command to 1, the ONU
only returns alarms that are not currently under ARC. Otherwise, the ONU returns all alarms
regardless of ARC status. In accordance with this request option, the ONU creates a copy of its
current alarm status table. ME instances with no reportable alarms are not represented in this copy.
The ONU responds to the OLT with the number of get all alarms next commands required to
retrieve the alarm status table copy (baseline message set) or the number of ME instances to be
retrieved (extended message set). These are in fact the same value because each baseline message
returns the alarm mask from one ME instance. The OLT then uploads the copy via a sequence of
get all alarms next commands targeted at the ONU data ME.
During the upload, the ONU is permitted to issue alarm notifications, both to declare and to clear
alarms.
When the upload is complete, the OLT compares the received alarm statuses with its own alarm
table entries for that ONU, along with any alarm notifications received during the upload process,
and notifies the network manager of any changes.
Rec. ITU-T G.988 (10/2012)
413
OLT
ONU
Get all alarms (ONU data)
The ONU resets the alarm sequence number to 0.
The ONU makes a snapshot (copy) of the current
alarm status table of all managed entity instances.
The ONU responds to the OLTs request with N,
the number of get all alarms next commands
needed to retrieve the alarm status snapshot.
Get all alarms response (ONU data, N)
The OLT creates a blank alarm status table for

a later audit against its current view. The OLT
then uploads the ONUs alarm status table
copy with N get all alarms next requests.
Get all alarms next (ONU data (command sequence 0))
Get all alarms next response (ONU data (partial alarms snapshot, 0))
...
During the alarm resynchronization process, the ONU
can still send alarm notifications. The OLT is
responsible for reconciling interim notifications against
the static snapshot uploaded from the ONU.
Get all alarms next (ONU data (command sequence N-1))
Get all alarms next response (ONU data (partial alarms snapshot, N-1))
The OLT reconciles the newly uploaded snapshot
with its previous alarm state information
and with any newly received alarm notifications.
One minute after the last get all alarms next

command, the ONU discards alarms snapshot.
G.988(12)_FA.1.4.2-1
Figure A.1.4.2-1 Alarm resynchronization

The ONU allows one minute between two get all alarms next requests. If the OLT does not send a
get all alarms next request within this time after the previous get all alarms next request or after the
get all alarms request, the ONU assumes the alarm upload to be terminated. It then discards the
copy of the alarm table and considers any further get all alarms next requests to be out of range.
A.1.4.3
Alarm reporting control
Alarm reporting control allows for the suppression of alarms from physical path termination points
and cardholders, under the control of the management system. ARC suppresses alarm reporting on
the parent managed entity and all dependent entities, but does not suppress alarm conditions
themselves. Therefore, if an alarm condition develops during an ARC interval, the ONU should
maintain the internal indication of the alarm, and if the OLT gets all alarms regardless of ARC, it
should be reported.
[ITU-T M.3100] completely describes ARC from a generic viewpoint. The OMCI provides for
ARC functions using two attributes of the parent managed entity: ARC and ARC interval. These
two attributes are described below.
ARC
This attribute allows the activation of alarm reporting control (ARC) for this PPTP or cardholder.
The attribute works in concert with the ARC interval attribute. The value 0 disables ARC, while the
414
Rec. ITU-T G.988 (10/2012)
value 1 enables ARC. The default value is disabled. When the ARC attribute is set to disabled, the
PPTP or cardholder is in the ITU-T M.3100 ALM state, in which alarms are reported normally.
When the ARC attribute is set to enabled, the PPTP or cardholder is in the ITU-T M.3100
NALM-QI state, in which alarm reporting is suppressed.
The PPTP or cardholder moves from state ALM to state NALM-QI when the OLT changes the
ARC attribute to enabled. The PPTP or cardholder moves from the NALM-QI state to the ALM
state when either 1) the PPTP or cardholder is trouble-free and the ARC interval timer expires, or 2)
the ARC attribute is set to disabled by the OLT. Continuation or recurrence of a fault resets the
timer. If the ARC interval timer expires, the ONU sets the ARC attribute to disabled autonomously,
and sends an AVC to notify the OLT. Refer to [ITU-T M.3100] for a more extensive discussion.
The ARC interval attribute can assume normal timing values of 0 to 254 minutes. The value 0
implies that a PPTP or cardholder in the NALM-QI state goes immediately to the ALM state upon
detection of a problem-free state. An ARC interval value of 255 has the special meaning that the
timer never expires. The PPTP or cardholder remains 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 [ITU-T M.3100].
The OMCI does not support the ITU-T M.3100 NALM-TI sub-function.
ARC interval
This attribute defines the interval to be used with the ARC function for this PPTP or cardholder.
The values 0 to 254 give the duration in minutes for the NALM-QI timer of [ITU-T M.3100]. The
special value 255 means that the timer never expires. The default value is zero.
A.1.5
Test, test response and test result
This clause describes how test, test response and test result messages are related.
Test:
This message is used to initiate either a self-test or any of the specific tests defined
against various managed entity types.
Test response: This message is the ONU's immediate acknowledgement of a test message. The test
response message reports the ability of the ONU to run the required test, but it does
not contain any specific results. A successful test response message implies that a
test result message will be forthcoming in due course.
Test result:
This autonomous message is used to report the result of a self-test or one of the
specific tests defined against various managed entity types.
A test on a particular managed entity instance is invoked by sending a test message to this instance.
Each managed entity that supports tests has a test action defined for it. The type of test invoked by a
test message depends on the managed entity type.
Figure A.1.5-1 shows the sequence of events when the OLT requests the ONU to perform a test.
The OLT starts the test by sending a test command. The ONU acknowledges this command with a
test response. Then the ONU carries out the test. After the test is complete, the ONU reports the test
result via an autonomous test result notification.
Rec. ITU-T G.988 (10/2012)
415
OLT
ONU
The OLT requests a test.

Test command (ME type, instance, test selection)
Test response (ME type, instance, success)
The ONU can still send
AVCs during the test operation.
The ONU carries out the requested tests
and reports the results to the OLT.
Test result notification (ME type, instance, pass/fail[, details])
G.988(12)_FA.1.5-1
Figure A.1.5-1 Reporting of test result

If the test was requested by the OLT, the test result notification contains the transaction identifier of
the original test command. An ONU may also run continuing diagnostic or monitoring routines, and
report failures either through alarms or through autonomous test result messages or both. A test
result message from a self-initiated test contains the transaction identifier zero.
A.1.6
Administrative state considerations
The administrative state attribute has two values: 0 (unlock) and 1 (lock).
In the state model of [ITU-T X.731], administrative state represents the intention of management to
allow (unlock) or deny (lock) the functionality of a managed entity. Administrative lock must not
inhibit management access to the managed entity. Though specified by neither [ITU-T X.731] nor
[ITU-T X.733], a common side effect of administrative lock is to suppress notifications from the
locked entity and any dependent entities. This avoids unnecessary alarms during maintenance and
repair, or when a resource is not in use. The OMCI conforms to this convention.
The need for continuing management access implies that, regardless of the administrative state, an
ONU must maintain its presence on the PON, and it may also have to provide local craft access, for
example, to enter registration information.
Subject to continuing management access, it is suggested that the ONU itself, any separable circuit
packs, and all ports should power down as much as possible when the administrative state is locked.
It is further suggested that the default value for administrative state be locked. This reduces power
consumption in cases such as pre-installation of ONUs and unsubscribed or unused ports.
Operators may have additional requirements that override power-down or that override the
suggested lock default.
NOTE When an ITU-T G.987 ONU enters initial state, as defined in [ITU-T G.987.3], it may set
administrative lock on the ONU-G managed entity, thereby preventing all user traffic from flowing until the
OLT unlocks the ONU-G. Although this is optional behaviour on the part of the ONU, the OLT is advised to
check the state of this attribute when bringing an ONU into service.
A.2
Extended message set
The extended OMCI message set may be used by G-PON systems after initial start-up on the
baseline message set.
Extended OMCI messages may be up to 1980 bytes long, including headers.
416
Rec. ITU-T G.988 (10/2012)
A.2.1
Create
Field
Byte
Transaction
correlation identifier
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = create
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Size of message contents field, bytes
Message contents
11-n
Value of first set-by-create attribute,

NOT the ME ID (size depending on
the type of attribute)
Extended OMCI = 0x0B
Value of last set-by-create attribute

MIC
Message integrity check, 4 bytes
The contents of the create message apply only to attributes that are defined to be set-by-create.
Writeable attributes that are not set-by-create are not permitted in a create message. Thus, the first
byte of the message contents field begins with the value of the first set-by-create attribute and so
forth. Space for each set-by-create attribute must be allocated in the create message, even if the
attribute is optional. When an optional attribute is not to be instantiated, the placeholder value to be
entered into this space is specific to the definition of each attribute. If the ONU does not support a
given optional set-by-create attribute, the ONU should simply ignore that field in the create
message, and the ONU should not set an illegal value flag in the create message response.
When the OMCI specifies a default value for a set-by-create attribute, the intention is that the OLT
populate the default recommendation into the create message. The ONU is not responsible for
instantiating any particular value for a set-by-create attribute.
A.2.2
Create response
Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Rec. ITU-T G.988 (10/2012)
417
Field
Byte
Message contents
length
9-10
Message contents
11
MIC
Comments
Size of message contents field =
3 bytes
Result, reason
0000 command processed
successfully
0001 command processing error
0010 command not supported
0011 parameter error
0100 unknown managed entity
instance
0110 device busy
0111 instance exists
12-13
Attribute execution mask, used when

result, reason = 0011
0
attribute ok
1
illegal attribute value
14-17
Message integrity check
NOTE If the result, reason code is not 0011, the attribute execution mask in bytes 12-13 is omitted.
A.2.3
Delete
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Size of message contents field = 0
MIC
11-14
A.2.4
DB = 0, AR = 1, AK = 0
bits 5-1: action = delete
0
Delete response
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

1 byte
418
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 1
0
Field
Message contents
MIC
A.2.5
Byte
11
Comments
Result, reason
successfully
instance
0110 device busy
12-15
Set
As well as simple attributes, the set command may be used to set rows of tables. If it is used for this
purpose, however, one set command must set exactly one row of the table, because there is no way
to enumerate or separate multiple table entries. The set table command is available to set more than
one row with a single command.
Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = set
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Message contents
11-12
Attribute mask
13-n
Value of first attribute to set (size

depending on the type of attribute)
Value of last attribute to set

MIC
A.2.6
Set response
Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Rec. ITU-T G.988 (10/2012)
419
Field
Byte
Message contents
length
9-10
Message contents
11
Comments
Result, reason
successfully
instance
0110 device busy
1001 attribute(s) failed or unknown
12-13
Optional-attribute mask, used with

1001 encoding:
0
default
1
unsupported attribute
14-15
Attribute execution mask, used with

1001 encoding:
0
default
1
failed attribute
MIC
NOTE The attribute masks in bytes 12-15 are present if, and only if, the result-reason code is 1001.
A.2.7
Get
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
Attribute mask
MIC
13-16
420
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
bits 5-1: action = get
0
A.2.8
Get response
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Message contents
11
DB = 0, AR = 0, AK = 1
0
Result, reason
successfully
instance
0110 device busy
12-13
Attribute mask
14-15

1001 encoding:
0 default
1 unsupported attribute
16-17

1001 encoding:
0 default
1 failed attribute
18-n
Value of first attribute included (size

Value of last attribute included
MIC
Bytes 14-17 are always reserved for the optional-attribute and attribute execution masks; however,
the contents of these bytes are only valid in conjunction with result code 1001 used to indicate
failed or unknown attributes. When the result code is not 1001, these bytes should be set to 0 by the
ONU transmitter and ignored by the OLT receiver.
When the OLT wishes to retrieve a table attribute, i.e., an attribute whose size is, or might be, larger
than the space available in one OMCI baseline message, the ONU indicates the size of that attribute
in bytes, rather than its value. The size is conveyed as four bytes in the value field for that attribute,
with the attribute execution mask set to indicate that the attribute is included. The OLT should then
use a sequence of get next messages to retrieve such an attribute. This convention also pertains to
Rec. ITU-T G.988 (10/2012)
421
extended OMCI messages, even though some table attributes might fit into an extended get
response message.
A.2.9
Get all alarms

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class = ONU data
7-8
Entity instance
Message contents
length
9-10

1 byte
Message contents
11
MIC
DB = 0, AR = 1, AK = 0
bits 5-1: action = get all alarms
0
12-15
x = alarm retrieval mode

0
Get all alarms regardless of
ARC status
1
Get all alarms not currently
under ARC
A.2.10 Get all alarms response

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
Number of ME instances to be
retrieved
MIC
13-16
422
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 1
0
A.2.11 Get all alarms next

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = get all alarms next
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
Command sequence number
MIC
13-16
Command sequence numbers start from 0.

A.2.12 Get all alarms next response
Note that alarm bit maps for a number of managed entities may be returned within a single message.
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10
Size of message contents field

including all sub-parts, bytes
Message contents 1
11-12
Entity class whose alarms are reported
13-14
Entity instance whose alarms are

reported
15-42
Message contents 2
(as needed)
Bit map alarms
43-44
Entity class whose alarms are reported
45-46

reported
47-74
DB = 0, AR = 0, AK = 1
Bit map alarms
Message contents n
Further managed entity alarm maps as

needed
MIC
The bit map used in the get all alarms next response for a given managed entity class is identical to
the bit map used in the alarm notification for that managed entity class.
If the ONU receives a get all alarms next request message whose command sequence number is out
of range, the get all alarms next response message should contain a null message contents field.
Rec. ITU-T G.988 (10/2012)
423
A.2.13 MIB upload

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB upload
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10
MIC
11-14
A.2.14 MIB upload response

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
Number of MIB upload next

commands required
MIC
13-16
A.2.15 MIB upload next

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
MIC
13-16

424
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB upload next
0
A.2.16 MIB upload next response

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

including all sub-fields, bytes
Message contents,
ME instance 1
11-12
Size of ME instance 1 attribute values

included (excluding bytes 11-18),
bytes
13-14
Entity class of ME instance 1
15-16
Entity instance
17-18
Attribute mask
19-n
Value of first attribute (size depending

on the type of the attribute)
...
Value of last attribute
Message contents,
ME instance 2
Content of ME instance 2, defined as

above.
Message contents,
ME instance k
Content of ME instance k, defined as

above.
MIC
Note that, if not all attributes of a managed entity fit within one MIB upload next response message,
the attributes are 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.
Thus, a single extended MIB upload next response message must contain an integer number of
attribute values. A message may contain leading or trailing fragments of ME instance reports and
any number of complete ME instance reports.
If the ONU receives a MIB upload next request message whose command sequence number is out
of range, it should respond with a message containing no message contents field. This is also the
appropriate response if the ONU times out (one minute) from the most recent MIB upload next or
MIB upload request from the OLT.
Rec. ITU-T G.988 (10/2012)
425
A.2.17 MIB reset

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = MIB reset
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10
MIC
11-14
A.2.18 MIB reset response

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance
Message contents
length
9-10

1 byte
Message contents
11
MIC
426
12-15
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 1
0
Result, reason
successfully
instance
0110 device busy
A.2.19 Alarm
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

29 bytes
Message contents
11-38
Alarm bit map
MIC
DB = 0, AR = 0, AK = 0
bits 5-1: action = alarm
0
39
Alarm sequence number
40-43
A.2.20 Attribute value change

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 0
bits 5-1: action = attribute value
change
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Message contents
11-12
Attribute mask
13-n
Value of first changed attribute (size

...
Value of last changed attribute
MIC
NOTE The AVC message for a table attribute does not contain an attribute value, only a mask, and the
ONU does not create a snapshot of the table. If the OLT wishes to obtain the new value, it must do a get
operation, followed by the required number of get next operations.
A.2.21 Test
The format of the test message is specific to the target entity class. Several 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.
Rec. ITU-T G.988 (10/2012)
427
A.2.21.1 Format for ONU-G, ANI-G, RE ANI-G, PPTP RE UNI, RE upstream amplifier, RE
downstream amplifier and circuit pack entity classes
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
NOTE This format applies to entity
classes ONU-G, ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream
amplifier, RE downstream amplifier
and circuit pack.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
xxxx = select test

0000..0110 Reserved for future use
0111
Self-test
1000..1111 Vendor-specific use.
See description related
to the test result message.
12-13
Pointer to a general purpose buffer

ME, used to return vendor-specific
test results.
This field is optional. The OLT may
include this field, or in case it is not
used, set it to zero. If the following
field is not used or not supported, the
OLT may omit both fields. The ONU
should accept either option, ignoring
the field if it does not support the
feature.
14-15
Pointer to an octet string ME, used to

define the vendor-specific test
parameters.
used, omit it or set it to zero. The
ONU should accept either option,
ignoring the field if it does not support
the feature.
MIC
428
DB = 0, AR = 1, AK = 0
bits 5-1: action = test
Rec. ITU-T G.988 (10/2012)
A.2.21.2 Format for IP host config data and IPv6 host config data entity classes
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
classes IP host config data and IPv6
host config data.
7-8
Entity instance
Message contents
length
9-10

5 bytes (IPv4 address) or 17 bytes
(IPv6 address)
Message contents
11
DB=0, AR=1, AK=0

Bits 5-1: action=test
0
xxxx = select test

0001 Ping
0010 Traceroute
0011 Extended ping
0100..0111 Reserved
1000..1111 Vendor-specific use.
The ICMP message is intended to be
sent from the ONU upstream towards
the network. See discussion related to
the test result message.
12-15
Option 1: IPv4 address of target (zero

if byte 11 specifies extended ping test)
12-27
Option 2: IPv6 address of target (zero

if byte 11 specifies extended ping test)
28
Number of times to ping.

This field pertains to both explicit and
extended ping tests. The value 0 or the
absence of this field selects the ONU's
internal default.
29-30
Pointer to large string ME that

identifies the target via a DNSparseable string. This field is used
only for the extended ping test.
MIC
A.2.21.3 Format for PPTP POTS UNI entity class

The test message for POTS UNIs supports two basic categories of test operation, a defined set of
tests that look in and out from the POTS port, and a set of code points that may be used for vendorspecific tests. The latter category is further subdivided into code points that return test results in a
general purpose buffer ME, using the test result message primarily as an event trigger to signal test
completion, and code points that return all test results in an ordinary test result message. If it is
needed, the OLT must create the general purpose buffer managed entity before initiating the test
action.
Note that a single message can be used to initiate multiple tests on a given ME if desired.
Rec. ITU-T G.988 (10/2012)
429
Bytes 12-25 are used by the dial tone make-break test. A zero value for a timer causes the ONU 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
ONU can support the dial tone test with internal defaults only, and is not required to support any of
the attributes of bytes 12-25. Likewise, an ONU can use internal defaults for a drop test, rather than
the values given in bytes 26-35. The capabilities of an ONU are documented by the vendor and
known through administrative practices.
Several distinct test classes are defined.
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
class PPTP POTS UNI.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
430
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
Bits 5-1: action = test
0
tt selects one of the POTS test class

formats
0
MLT, dial tone make-break
1
SIP/ITU-T H.248 test call
2..3 Reserved
x Bits reserved for use in specific
test classes as defined below
Test class 0:
Field
Message contents
Byte
Comments
11
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
1001..1011 vendor-specific test, all
results returned in test results
message
1100..1111 vendor-specific test, test
results returned in general
purpose buffer ME. The ONU
should deny a test operation
command in this range if bytes
36..37 do not point to a GP
buffer.
12
DBDT timer T1 (slow dial tone

threshold), in units of 0.1 seconds.
Range 0.1 to 6.0 seconds.
13
DBDT timer T2 (no dial tone

14
DBDT timer T3 (slow break dial tone

15
DBDT timer T4 (no break dial tone

16
17
DBDT control byte

d: dialled digit
1 dialled digit specified in byte 17
0 use default digit
p = pulse (1) or tone (0) dialling
Digit to be dialled, ASCII character in
range "0"-"9", "*", "#".
18-19
Dial tone frequency 1, in units of Hz
20-21
Dial tone frequency 2, in units of Hz.

0 = unused (i.e., if only one tone is
specified).
Rec. ITU-T G.988 (10/2012)
431
Field
Byte
Comments
22-23

0 = unused (i.e., if only one or two
tones are specified).
24
Dial tone power threshold, absolute

value, 0.1 dB resolution, range []0.1
to []25.3 dBm0. E.g.,
13 dBm0 = 0x82. 0 = unspecified.
25
Idle channel power threshold, absolute

value, 1 dB resolution, range []1 to
[]90 dBm0. 0 = unspecified.
26
DC hazardous voltage threshold,

absolute value, volts. 0 = unspecified.
27
AC hazardous voltage threshold, volts

RMS. 0 = unspecified.
28
DC foreign voltage threshold, absolute

value, volts. 0 = unspecified.
29
AC foreign voltage threshold, volts

RMS. 0 = unspecified.
30
Tip-ground and ring-ground resistance

threshold, k 0 = unspecified.
31
Tip-ring resistance threshold, k.

0 = unspecified.
32-33
Ringer equivalence minimum

threshold, in 0.01 REN units.
0 = unspecified.
34-35
Ringer equivalence maximum

threshold, in 0.01 REN units.
0 = unspecified.
36-37

test results.
38-39

define vendor-specific test parameters.
used, omit it or set it to zero. The
ONU should accept either option,
ignoring the field if it does not support
the feature.
MIC
432
Rec. ITU-T G.988 (10/2012)
Test class 1:
Field
Message contents
MIC
Byte
11
Comments
a test mode
1 forced mode
x Reserved
12-27
ASCII string containing the number to

be dialled. Trailing unused octets are
padded with null bytes.
28-31
A.2.21.4 Format for dot1ag MEP entity class, loopback test

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
Device identifier
Managed entity
identifier
5-6
Entity class.
NOTE This format applies to the
dot1ag MEP entity class
7-8
Entity instance
Message contents
length
9-10

20 bytes
Message contents
11
x=select test
0: Ethernet loopback test
1: IEEE 802.1ag linktrace test (see
separate format description below)
Other values reserved
12
If c = 1, the value of the MEP's CCM

and LTM priority attribute is used,
with drop eligibility false.
If c = 0, pppd represents the priority
(P bits) and drop eligibility fields of
the transmitted LBM frame.
13-18
MAC address of target MHF or MEP,

or 0 if the destination MEP ID is to be
used instead. [IEEE 802.1ag] specifies
unicast addresses; [ITU-T Y.1731]
also allows for multicast.
19-20
Destination MEP ID, in the range

1..8191, or 0 if the MAC address in
bytes 13..18 is to be used instead.
Rec. ITU-T G.988 (10/2012)
433
Field
Byte
21-22
Repetition count, range 1..1024. This

governs how many LBMs are
generated. The rate at which LBMs
are generated is not specified. If
5 seconds elapses with no LBRs
received, the test aborts.
23-24
These four fields are pointers to as

many as four-octet string MEs, which
are concatenated to form an octet
string of up to 1500 bytes. The string
is packaged into a data TLV and
transmitted as part of the LBM. If all
four fields are null pointers, no data
TLV is sent. If only one octet string is
needed, it should be specified in bytes
23..24, etc., with null pointers in the
higher-numbered bytes of the test
message.
25-26
27-28
29-30
MIC
Comments
31-33
A.2.21.5 Format for dot1ag MEP entity class, linktrace test

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
dot1ag MEP entity class
7-8
Entity instance
Message contents
length
9-10

13 bytes
Message contents
11
x=select test
0: Ethernet loopback test (see separate
format description above)
1: IEEE 802.1ag linktrace test
Other values reserved
12
Flags, a bit map

f: Use FDB only. When 1, the bridge
uses only its normal MAC forwarding
tables for forwarding. When 0, the
bridge may also consult its MIP CCM
database to determine the forwarding
port.
13-18
434
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
0
Unicast MAC address of target MHF

or MEP, or 0 if the destination MEP
ID is to be used instead.
Field
Byte
19-20
MIC
Comments
1..8191, or 0 if the unicast MAC
address in bytes 13..18 is to be used
instead.
21
Max hops count specifies initial

TTL (time to live); limits the number
of relay stages through which the
LTM is forwarded before being
discarded, and the number of LTRs
that may be returned. [IEEE 802.1ag]
recommends a default value of 64.
22-23

ME, used to return the linktrace
results. The ONU should deny the test
operation command if this field is a
null or an invalid pointer.
24-27
A.2.22 Test response

If an ONU does not support all tests requested in byte 11 of the test request message, it should not
execute any test and should respond with result 0010, command not supported. If an ONU 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 then be re-issued with different thresholds or with default thresholds, and
would be expected to succeed.
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

1 byte
Message contents
11
MIC
12-15
DB = 0, AR = 0, AK = 1
0
Result, reason
successfully
instance
0110 device busy
Rec. ITU-T G.988 (10/2012)
435
The test response message is an indication to the OLT that the test request is received and is being
processed. Test outcome is reported by a subsequent autonomous test result message.
A.2.23 Start software download
When a file is to be downloaded to a single instance of the software image managed entity, the
target ME ID is specified in bytes 7..8. An optional feature permits the same file to be downloaded
to a number of circuit packs by setting bytes 7..8 = 0xFFFF and specifying the software image ME
IDs in bytes 17-18, 19-20, etc.
Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = start software
download
0

Entity class = software image
MS byte of software image instance

0
ONU-G
1..254 slot number
255
download to multiple
software image managed
entities
LS byte of software image instance

0
instance 0
1
instance 1
2..254 vendor-specific use
255
multiple download
Message contents
length
9-10
Message contents
11
12-15
16
Window size 1
Image size in bytes
Number of circuit packs to be updated
in parallel (value 1...9)
17-18
ME ID of software image entity

instance (first byte: slot number;
second byte: instance 0..1 or 2..254
vendor-specific)
1920,
etc.
Additional software image ME IDs

(same format as bytes 17..18) for
additional simultaneous downloads.
MIC
A.2.24 Start software download response

When a file is downloaded to a single software image ME, the response contains the target ME ID
in bytes 7..8, a result code in byte 11, and a window size counter-proposal (which may be the same
as that suggested by the OLT in the original request) in byte 12. Bytes 13..N are omitted.
436
Rec. ITU-T G.988 (10/2012)
An ONU that supports the optional parallel download feature responds to a multiple download
command with the full format shown below, where unused trailing image references may be
omitted. If the ONU does not support the parallel download feature, it responds with result code
0b0101, unknown managed entity instance.
Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 0, AK = 1
download
0


0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Message contents
length
9-10
Message contents
11
Result, reason
successfully
instance
0110 device busy
12
Window size 1
13
Number of instances responding

(value 0..9)
14-15
16
17-n

vendor-specific)
Result, reason for bytes 14..15 same
coding as byte 11
Repeat coding of bytes 14..16 for
additional requested software image
instances.
Rec. ITU-T G.988 (10/2012)
437
Field
Byte
MIC
Comments
A.2.25 Download section

Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = x, AK = 0
x = 0 no response expected (section
within a window)
x = 1 response expected (last section
of a window)
bits 5-1: action = sw download section
0


0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Message contents
length
9-10
Message contents
11
12-n
MIC
438
Download section number

Software image data
Rec. ITU-T G.988 (10/2012)
A.2.26 Download section response

Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 0, AK = 1
bits 5-1: action = sw download section
0


0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Message contents
length
9-10
Message contents
11
12
MIC
Result, reason
successfully
instance
0110 device busy
13-16
A.2.27 End software download

The format of this command is similar to that of the start software download message. Bytes 19..n
support the optional parallel download feature, and are omitted for download to a single target.
Field
Byte
Transaction
1-2
Message type
Device identifier
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = end software
download
0
Rec. ITU-T G.988 (10/2012)
439
Field
Managed entity
identifier
Byte
5-6
Comments

0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Message contents
length
9-10
Message contents
11-14
CRC-32, computed over all bytes of

the software image (excluding
padding), as specified in
[ITU-T I.363.5].
15-18
Image size in bytes
19
Number of parallel download

instances sent in this message
(value 1..9)
20-21

vendor-specific)
2223,
etc.
Software image ME IDs (same format

as bytes 20..21) for additional
simultaneous downloads.
MIC
A.2.28 End software download response

The response message informs the OLT whether the download command was successful. If a single
software image ME was targeted for download, byte 11 reports the result of the process, and
bytes 12..N are omitted. If a number of software images were targeted for parallel download, byte
11 reports device busy as long as any of the instances is busy writing the image to a non-volatile
store. Once the ONU has stored all images successfully, it responds to continued end software
download commands with a 0 in byte 11 and a separate result for each software image ME. Unused
trailing instance references may be omitted.
Field
Byte
Transaction
1-2
Message type
Device identifier
440
Rec. ITU-T G.988 (10/2012)
Comments
DB = 0, AR = 0, AK = 1
download
0
Field
Byte
Managed entity
identifier
5-6
Comments

0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Message contents
length
9-10
Message contents
11
12
Result, reason
successfully (CRC correct)
(CRC incorrect, in addition to
the normal criteria)
instance
0110 device busy
(value 0..9)
13-14

vendor-specific)
15
Result, reason for bytes 13..14 same

coding as byte 11
16-n

additional software image instances.
MIC
A.2.29 Activate image

Field
Byte
Transaction
1-2
Message type
Device identifier
Comments
DB = 0, AR = 1, AK = 0
bits 5-1: action = activate image
0
Rec. ITU-T G.988 (10/2012)
441
Field
Managed entity
identifier
Byte
Flags (Note 1)
5-6
MS byte entity instance

0
ONU-G
1..254
slot number
0
9-10
11
Comments
Message contents
length
LS byte entity instance

0
first instance
1
second instance
MIC
Bits FF:
00 Activate image
unconditionally
01 Activate image only if no
POTS/VoIP calls are in
progress
emergency call is in progress
(Note 2)
11 Reserved
If the ONU denies the activate image
command because of the FF field, it
returns result, reason code 0110,
device busy.
NOTE 1 The Flags byte is optional. If it is absent, the activate image command is to be executed
unconditionally.
NOTE 2 The ONU determines the presence of an originating emergency call on the basis of the
Emergency service number attribute of the VoIP feature access codes ME. Other ways for the ONU to
determine the presence of an emergency call are for further study.
A.2.30 Activate image response

Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 0, AK = 1
0

442

0
ONU-G
1..254
slot number
0
Rec. ITU-T G.988 (10/2012)

0
first instance
1
second instance
Field
Byte
Message contents
length
9-10
Message contents
11
MIC
Comments
1 byte
12-15
Result, reason
successfully
instance
0110 device busy
A.2.31 Commit image

Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
DB = 0, AR = 1, AK = 0
bits 5-1: action = commit image
0

Comments

0
ONU-G
1..254
slot number
0

0
first instance
1
second instance
Message contents
length
9-10
MIC
11-14
A.2.32 Commit image response

Field
Byte
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7
Comments
DB = 0, AR = 0, AK = 1
0

0
ONU-G
Rec. ITU-T G.988 (10/2012)
443
Field
Byte
Comments
1..254
Message contents
length
9-10
Message contents
11
MIC
slot number

0
first instance
1
second instance
1 byte
12-15
Result, reason
successfully
instance
0110 device busy
A.2.33 Synchronize time

The synchronize time command controls the tick boundary for performance monitoring collection,
and optionally, a date and time clock.
If this message specifies the time (and optionally the date), the ONU sets its PM interval counter to
a current offset from the most recent quarter-hour boundary, that is, to a value in the range
0..899 seconds. This may cause the current PM collection interval to be longer or shorter than
900 seconds. Date and time are not explicitly required in an ONU, but if the ONU has a real-time
clock, it is also set by this message. If the OLT does not wish to specify a date, it may set year,
month and day fields to 0. If the ONU does not support the setting of the date, it will use the success
result info field in the synchronize time response message to indicate that only the 15-minute tick
boundary was set.
If date and time are not present in the message, the ONU sets its PM interval counter to 0. This may
cause the current PM collection interval to be shorter than 900 seconds. The effect on a possible
ONU real-time clock is not specified.
There is no intention that this message be used to establish a precise time of day reference.
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class = ONU-G
7-8
Entity instance = 0
Message contents
length
9-10
444
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
bits 5-1: action = synchronize time
0
Field
Message contents
Byte
11-12
Comments
Year, e.g., 2009
13
Month, range 1..12
14
Day of month, range 1..31
15
Hour of day, range 0..23
16
Minute of hour, range 0..59
17
Second of minute, range 0..59
MIC
A.2.34 Synchronize time response

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
length
9-10
Message contents
11
Result, reason
successfully
instance
0110 device busy
12
x: reserved
rrrr: Success result info
0000 15-minute tick boundary set
successfully
0001 Date and 15-minute tick
boundary set successfully
This byte is present and meaningful
only when the result, reason code in
byte 11 is 0000. Byte 12 is optional
and is treated as described in
clause 11.2.5.
MIC
DB = 0, AR = 0, AK = 1
Bits 5-1: action = synchronize time
0
Rec. ITU-T G.988 (10/2012)
445
A.2.35 Reboot
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Flags (Note 1)
11
DB = 0, AR = 1, AK = 0
bits 5-1: action = reboot
0
MIC
Bits FF:
00 Reboot unconditionally
01 Reboot only if no
progress
10 Reboot only if no emergency
call is in progress (Note 2)
11 Reserved
If the ONU denies the reboot
device busy.
NOTE 1 The Flags byte is optional. If it is absent, the activate image command is to be executed
unconditionally.
NOTE 2 The ONU determines the presence of an originating emergency call on the basis of the
A.2.36 Reboot response

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

1 byte
446
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 1
0
Field
Message contents
MIC
Byte
11
Comments
Result, reason
successfully
instance
0110 device busy
12-15
A.2.37 Get next

The ONU should reject a get next command:
if the attribute mask specifies more than one attribute (result code 0011);
if the attribute mask specifies an attribute that is not a table (result code 0011);
if the specified attribute has not been prepared for upload with a prior get command (the
prior get is subject to one-minute timeout) (result code 0001).
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

4 bytes
Message contents
11-12
Attribute mask
13-14
15-18
MIC
DB = 0, AR = 1, AK = 0
bits 5-1: action = get next
0
A.2.38 Get next response

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK =1
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Rec. ITU-T G.988 (10/2012)
447
Field
Byte
Message contents
length
9-10
Message contents
11
Comments
Result, reason
successfully
instance
0110 device busy
12-13
Attribute mask
14-n
Value of the specified attribute (size

depending on the type of attribute,
limited by message capacity)
MIC
If the ONU receives a get next request message whose command sequence number is out of range,
the ONU responds with parameter error.
A.2.39 Test result
The test result message reports the outcome of a test. In the case of a requested test, the transaction
identifier of the test result message is identical to the transaction identifier of the test message that
initiated the corresponding test. In the case of a self-triggered test result, the transaction identifier is
set to 0.
Several formats are currently defined. They are used as follows:
self-test results, ONU-G, circuit pack, or any other ME that supports selftest;
vendor-specific test results, generic format, any ME that supports it;
POTS test results, either an MLT, dial tone draw-break or vendor-specific POTS tests that
use a general purpose buffer;
ICMP tests, either ping or traceroute;
the results of an optical line supervision test on the ANI-G, RE ANI-G, PPTP RE UNI, RE
upstream amplifier or RE downstream amplifier;
[IEEE 802.1ag] loopback and linktrace tests.

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.
A.2.39.1 Format for self-test action invoked against ONU-G and circuit pack entity classes
Field
Byte
Transaction
1-2
Message type
Device identifier
448
Rec. ITU-T G.988 (10/2012)
Comments
DB = 0, AR = 0, AK =0
bits 5-1: action = test result
0
Field
Managed entity
identifier
Byte
Comments
5-6
Entity class
NOTE This message format pertains
to ONU-G and circuit pack entity
classes.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
Reserved
12
xx: self-test result

00 failed
01 passed
10 not completed
13-14

ME. Valid only for vendor-specific
tests that require a GP buffer.
This field is optional. The ONU may
used, omit it or set it to zero. The OLT
should accept either option.
MIC
A.2.39.2 Format for vendor-specific test actions invoked against ONU-G and circuit pack
entity classes
This format is also used for vendor-specific test actions invoked against the PPTP POTS UNI entity
class when no general purpose buffer is needed.
Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK =0
Device identifier
Managed entity
identifier
5-6
Entity class
to ONU-G, circuit pack and PPTP
POTS UNI entity classes.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
Type 1 (Note)
12-13
Value 1
14
Type 2
15-16
Value 2
17
Type 3
18-19
Value 3
20
Type 4
Rec. ITU-T G.988 (10/2012)
449
Field
Byte
Comments
21-22
Value 4
23
Type 5
24-25
Value 5
26
Type 6
27-28
Value 6
29
Type 7
30-31
Value 7
32
Type 8
33-34
Value 8
35
Type 9
36-37
Value 9
38
Type 10
39-40
Value 10
MIC
NOTE Test result types are specified in clause 11.2.10. Type-value fields are packed in the lowest byte
positions. Unused trailing byte positions may be omitted. If more than 10 type-value pairs are to be
returned, an additional test type should be defined in the test message. At the vendor's discretion, a test
result may include an ordered sequence of repeated type-value pairs to represent, for example, port
ordering, or first/second power input. In this case, missing values can be flagged with type = 255.
A.2.39.3 Format for POTS UNI entity class

In this format, byte 11 reports a summary MLT test result. The result for each test category is
limited to the two values pass test or test not run or failed test. Byte 13 reports the results of a dial
tone test.
Byte 12 reports the result of a self-test or a vendor-specific test that returns results in a general
purpose buffer. At present, self-test is not supported for the POTS UNI entity class, 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 ONU. If an ONU does not support or recognize a given test, it is expected to deny the test
request message. To avoid physical damage, an ONU may cease testing if a test fails usually the
hazardous potential test and thus some subsequent tests will not be run. In addition, the ONU 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 11 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.
450
Rec. ITU-T G.988 (10/2012)
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
to the PPTP POTS UNI entity class.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
DB = 0, AR = 0, AK = 0
0
tt
selects one of the POTS test

class formats
0
1
2..3 Reserved
Bits reserved for use in specific
Test class 0:
Message contents
11
MLT drop test result:

0 fail test a/b/c/d/e/f
1 pass test, or test not run
a hazardous potential
b foreign EMF
c resistive faults
d receiver off-hook
e ringer
f NT1 dc signature test
12
xx: Result of self-test or vendorspecific test

00 failed
01 passed
10 not completed
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
13
Rec. ITU-T G.988 (10/2012)
451
452
14
Dial tone power flags (Note)

aaa Quiet channel power
bbb Dial tone power
15
Loop test DC voltage flags (Note)

aaa VDC, tip-ground
bbb VDC, ring-ground
16
Loop test AC voltage flags (Note)

aaa VAC, tip-ground
bbb VAC, ring-ground
17
Loop test resistance flags 1 (Note)

aaa Resistance, tip-ground
bbb Resistance, ring-ground
18
Loop test resistance flags 2 (Note)

aaa Resistance, tip-ring
bbb Ringer load test
19
Time to draw dial tone, in 0.1 second

units. Valid only if byte 13 ddd = xx1.
20
Time to break dial tone, in 0.1 second

units. Valid only if byte 13 bbb = xx1.
21
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 14 bbb = xx1.
22
Quiet channel power measurement,

unsigned absolute value, 1 dB
resolution, range 0 to []90 dBm0.
Valid only if byte 14 aaa = xx1.
23-24
Tip-ground DC voltage, 2s
complement, resolution 1V. Valid only
if byte 15 aaa = xx1.
25-26
Ring-ground DC voltage, 2s
complement, resolution 1V. Valid only
if byte 15 bbb = xx1.
27
Tip-ground AC voltage, Vrms. Valid

only if byte 16 aaa = xx1.
28
Ring-ground AC voltage, Vrms. Valid

only if byte 16 bbb = xx1.
29-30
Tip-ground DC resistance, k. Infinite

resistance: 0xFFFF. Valid only if byte
17 aaa = xx1.
31-32
Ring-ground DC resistance, k.
Infinite resistance: 0xFFFF. Valid only
if byte 17 bbb = xx1.
33-34
Tip-ring DC resistance, k. Infinite

resistance: 0xFFFF. Valid only if byte
18 aaa = xx1.
35
Ringer equivalence, in 0.1 REN units.

Valid only if byte 18 bbb = xx1.
Rec. ITU-T G.988 (10/2012)
36-37
Pointer to a general purpose buffer ME.

Valid only for vendor-specific tests that
require a GP buffer.
38
39
Loop tip-ring test AC/DC voltage flags.

Bytes 38-41 are optional as a group.
The ONU may include or omit them as
a group. The OLT should accept either
option in accordance with clause
11.2.5.
aaa VAC, tip-ring
bbb VDC, tip-ring
(Note)
Tip-ring AC voltage, Vrms. Valid only
if byte 38 aaa = xx1.
40-41
Tip-ring DC voltage, 2s complement,

resolution 1 V. Valid only if byte 38
bbb = xx1.
MIC
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.
Test class 1:
Field
Message contents
MIC
Byte
11
12-15
Comments
yyy
000
001
010
011
100
101
110
111
x
report the results of the test

Test failed
Test passed
Not completed, line off hook
Not completed, other reason
Reserved
Reserved
Reserved
Reserved
Reserved
A.2.39.4 Format for test action invoked against IP host config data and IPv6 host config data
entity classes
Field
Byte
Transaction
1-2
Message type
Device identifier
Comments
DB = 0, AR = 0, AK =0
0

Rec. ITU-T G.988 (10/2012)
453
Field
Managed entity
identifier
Byte
Comments
5-6
Entity class
classes IP host config data and IPv6
host config data.
7-8
Entity instance
Message contents
length
9-10
Message contents
11
12..n
MIC
xxx: Test result

000
Timed out, no response
001
ICMP echo responses
attached
010
ICMP time exceeded
responses attached
011
Unexpected ICMP response
100
Target address in large
string ME could not be
resolved
101..111 Reserved
See following descriptions for the
contents of these bytes
If xxx = 001 (echo response ping), the remainder of the message contains the following content. If
the test message specifies the number of times to ping, the ONU should generate that number of
echo requests; otherwise the number of echo requests generated is the ONU vendor's default. The
resolution of the delay measurement is vendor-specific. The special value 0xFFFF indicates a lost
response.
12-27
In the extended ping test, these bytes

contain the actual IP address that was
pinged 4 bytes for IPv4, 16 bytes for
IPv6. If the network address was not
resolvable, the ONU should set these
bytes to all zeroes.
In the normal (non-extended ping
test), delay measurements begin
immediately in byte 12, according to
the same pattern shown in
bytes 28-29, etc.
28-29
16-bit measurement of response

delay n, expressed in ms.
30-31

delay n+1, expressed in ms.
Etc.
If xxx = 010 (time exceeded traceroute), the remainder of the message contains the following
content. In PON applications, it is not expected that a route trace will exceed the available space in
the message, but if it does, the more distant responses should be dropped.
454
Rec. ITU-T G.988 (10/2012)
IP address of nearest neighbour

(4 bytes, IPv4, or 16 bytes, IPv6)
IP address of second nearest
neighbour (4 bytes, IPv4, or 16 bytes,
IPv6)
Etc.
If xxx = 011 (unexpected ICMP response), the remainder of the message contains the following
content:
12
Type
13
Code
14-15
Checksum
16-19
Bytes 5-8 of ICMP message (meaning

depends on type/code)
20-n
Internet header + original datagram

(truncated if necessary by extended
OMCI message size limit)
A.2.39.5 Format for optical line supervision test action invoked against ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream amplifier or RE downstream amplifier entity class
Field
Transaction
correlation
identifier
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
to ANI-G, RE ANI-G, PPTP RE UNI,
RE upstream amplifier or RE
downstream amplifier entity classes
7-8
Entity instance
Message contents
length
9-10
Message contents
11
DB = 0, AR = 0, AK =0
0
12-13
14
Type = 5, Mean optical launch power

dBW, 2s complement, 0.002 dB
resolution
21-22
23
Type = 3, Received optical power

resolution
18-19
20
Type = 1, Power feed voltage

V, 2s complement, 20 mV resolution
15-16
17
Type = 9, Laser bias current

Type 12, Temperature, degrees
Rec. ITU-T G.988 (10/2012)
455
Field
Byte
Comments
24-25
2s complement, 1/256 degree C

resolution
26-27
Pointer to a general purpose buffer ME.

Valid only for vendor-specific tests that
require a GP buffer.
used, omit it or set it to zero. The OLT
should accept either option.
MIC
NOTE Unsupported tests are indicated with test type indicator 0 and 2 bytes of 0 data.
A.2.39.6 Format for test action invoked against dot1ag MEP entity class, loopback test
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
classes.
7-8
Entity instance
Message contents
length
9-10

9 bytes
Message contents
11
MIC
456
DB = 0, AR = 0, AK =0
0
x = 1: indicates failure to receive any

loopback replies (LBRs) within
5 seconds
12-13
Valid LBRs count: the number of

valid, in-order LBRs received.
14-15
Out-of-order LBRs count: the number

of valid LBRs received that were out
of order.
16-17
Mismatch LBRs count: the number of

received LBRs whose MAC SDU did
not match that of the corresponding
LBM (except for opcode). Optional
feature, set to 0xFF if not supported.
18-19
Delay from LB message transmission

to LB response reception, measured in
microseconds. The value 0 indicates
no information available.
20-23
Rec. ITU-T G.988 (10/2012)
A.2.39.7 Format for test action invoked against dot1ag MEP entity class, linktrace test
Field
Byte
Comments
Transaction
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
classes.
7-8
Entity instance
Message contents
length
9-10

13 bytes
Message contents
11
MIC
DB = 0, AR = 0, AK =0
0

linktrace replies (LTRs) within
5 seconds
12-15
Transaction ID of transmitted LTM
16-23
Content of egress TLV data field in

transmitted LTM ([IEEE 802.1ag],
clause 21.8.8). The LTRs themselves
are captured in the general purpose
buffer designated by the test
command.
24-27
A.2.40 Get current data

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = get current data
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

2 bytes
Message contents
11-12
Attribute mask
MIC
13-16
Rec. ITU-T G.988 (10/2012)
457
A.2.41 Get current data response

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Message contents
11
DB = 0, AR = 0, AK = 1
0
Result, reason
successfully
instance
0110 device busy
12-13
Attribute mask
14-15

1001 encoding:
0 default
1 unsupported attribute
16-17

1001 encoding:
0 default
1 failed attribute
18-n
Value of first attribute included (size

MIC
Bytes 14..17 are always reserved for the optional-attribute and attribute execution masks; however,
the contents of these bytes are only valid in conjunction with the 1001 encoding used to indicate
failed or unknown attributes. If the result code is not 1001, these bytes should be set to 0 by the
ONU and ignored by the OLT.
A.2.42 Set table
The set table command provides a way in which a number of rows may be written into a table with
a single command. The same function can be achieved with individual set commands, with each
command instance directed to a single row of the table.
458
Rec. ITU-T G.988 (10/2012)
Writeable tables in the OMCI have various mechanisms to control whether a given set operation
causes a new row to be added to the table, an existing row to be overwritten or deleted, or the entire
table cleared. All such mechanisms are embedded within the definition of the table row itself.
Conflicting control semantics are therefore possible. The set table command executes each table
row sequentially, in list order.
Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 1, AK = 0
bits 5-1: action = set table
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10
Message contents
11-12
Attribute mask (Note)
13-n
Value of the first table row (size

depending on table definition)
Value of the last table row

MIC
NOTE Exactly one bit of the attribute mask must be set, and that bit must correspond to a read-write
table attribute in the definition of the parent managed entity.
A.2.43 Set table response

Field
Byte
Transaction
1-2
Comments
Message type
DB = 0, AR = 0, AK = 1
bits 5-1: action = set table
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
length
9-10

1 byte
Rec. ITU-T G.988 (10/2012)
459
Field
Message contents
MIC
A.3
Byte
11
Comments
Result, reason
successfully
instance
0110 device busy
12-15
Baseline message set
All G-PON OLTs and ONUs support the baseline message set.
A.3.1
Create
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
Attribute value of first set-by-create

attribute, NOT the ME ID (size
Attribute value of last set-by-create

attribute (size depending on the
type of attribute)
xx-40
OMCI trailer
Zero padding
41-48
It should be noted that the message contents for the create message apply only to attributes that are
defined to be set-by-create. Writeable attributes that are not set-by-create are not permitted in a
create message. Thus, the first byte of the message contents field begins with the attribute value for
the first set-by-create attribute and so forth. Space for each set-by-create attribute must be allocated
in the create message, even if the attribute is optional. When an optional attribute is not to be
instantiated, the placeholder value to be entered into this space is specific to the definition of each
attribute. If the ONU does not support a given optional set-by-create attribute, the ONU should
simply ignore that field in the create message, and the ONU should not set an illegal value flag in
the create message response.
460
Rec. ITU-T G.988 (10/2012)
When the OMCI specifies a default value for a set-by-create attribute, the intention is that the OLT
populate the default recommendation into the create message. The ONU is not responsible for
instantiating any particular value for a set-by-create attribute.
A.3.2
Create response
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
OMCI trailer
A.3.3
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
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
10-11

0011 encoding:
0=
attribute ok
1=
illegal value attribute
12-40
Zero padding
41-48
Delete
Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 1, AK = 0
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-40
Zero padding
OMCI trailer
41-48
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
461
A.3.4
Delete response
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
DB = 0, AR = 0, AK = 1
0
Result, reason
successfully
instance
0110 device busy
10-40
OMCI trailer
A.3.5
OMCI = 0x0A
Zero padding
41-48
Set
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-10
Attribute mask
11
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
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-40
OMCI trailer
462
41-48
Rec. ITU-T G.988 (10/2012)
Zero padding
A.3.6
Set response
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
OMCI trailer
A.3.7
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Result, reason
successfully
instance
0110 device busy
10-11
Optional attribute mask, used with

1001 encoding:
0 = default
1 = unsupported attribute
12-13

1001 encoding:
0 = default
1 = failed attribute
14-40
Zero padding
41-48
Get
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-10
Attribute mask
11-40
Zero padding
OMCI trailer
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
41-48
Rec. ITU-T G.988 (10/2012)
463
Based on the size of the message contents field, the aggregate size of the attributes requested by a
single get command should not exceed 25 bytes.
A.3.8
Get response
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
10-11
12
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Result, reason
successfully
instance
0110 device busy
1001 attribute(s) failed or
unknown
Attribute mask
Value of first attribute included
(size depending on the type of
attribute)

(size depending on the type of
attribute)
OMCI trailer
xx-36
Zero padding
37-38

1001 encoding:
0 = default
39-40

1001 encoding:
0 = default
41-48
Bytes 37 to 40 are always reserved for the optional attribute and attribute execution masks;
however, the contents of these bytes are only valid in conjunction with the 1001 encoding used to
indicate failed or unknown attributes.
When the OLT wishes to transfer an attribute whose size is, or might be larger than the space
available in one OMCI message (table attribute), the ONU responds with four bytes to indicate the
464
Rec. ITU-T G.988 (10/2012)
size of that attribute with an appropriate attribute mask. The OLT should then use the get next
message in order to retrieve the attribute.
A.3.9
Get all alarms

Field
Transaction
Byte
Device identifier
Managed entity
identifier
5-6
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
7-8
Entity instance
x = alarm retrieval mode

0 = Get all alarms regardless
of ARC status
1 = Get all alarms not
currently under ARC
10-40
OMCI trailer
Comments
1-2
Message type
Message contents
Zero padding
41-48
A.3.10 Get all alarms response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-10
Number of subsequent get all

alarms next commands
11-40
Zero padding
OMCI trailer
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
41-48
A.3.11 Get all alarms next

Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 1, AK = 0
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
465
Field
Message contents
OMCI trailer
Byte
Comments
9-10
11-40
Zero padding
41-48
Command sequence numbers start from 0 onwards.

A.3.12 Get all alarms next response
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-10
Entity class whose alarms are

reported
11-12

reported
13-40
OMCI trailer
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Bit map alarms
41-48
The bit map used in the get all alarms next response for a given managed entity class is identical to
the bit map used in the alarm notifications for that managed entity class.
In the case where the ONU receives a get all alarms next request message in which the command
sequence number is out of range, the ONU should respond with a message in which bytes 9 to 40
are all set to 0. This corresponds to a response with entity class 0, entity instance 0, and bit map all
0s.
A.3.13 MIB upload
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-40
Zero padding
OMCI trailer
41-48
466
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
A.3.14 MIB upload response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-10
Number of subsequent MIB upload

next commands
11-40
Zero padding
OMCI trailer
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
41-48
A.3.15 MIB upload next

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-10
11-40
Zero padding
OMCI trailer
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
41-48

A.3.16 MIB upload next response
Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
467
Field
Message contents
Byte
Comments
9-10
Entity class of object
11-12
Entity instance of object
13-14
Attribute mask
15-n
Value of the first attribute (size

depending on type of the attribute)
...
Value of the last attribute (size
depending on type of the attribute)
xx-40
OMCI trailer
Zero padding
41-48
If the ONU receives a MIB upload next request message whose command sequence number is out
of range, it should respond with a message in which bytes 9 to 40 are all set to 0. This corresponds
to a response with entity class 0, entity instance 0, attribute mask 0, and padding from byte 15 to
byte 40.
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.
A.3.17 MIB reset
Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 1, AK = 0
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-40
Zero padding
OMCI trailer
41-48
OMCI = 0x0A
A.3.18 MIB reset response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
468
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Field
Message contents
Byte
10-40
OMCI trailer
Comments
Result, reason
successfully
instance
0110 device busy
Zero padding
41-48
A.3.19 Alarm
Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 0, AK = 0
bits 5-1: action = alarm
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-36
Alarm bit map
37-39
Zero padding
40
OMCI trailer
OMCI = 0x0A
Alarm sequence number
41-48
A.3.20 Attribute value change

Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 0, AK = 0
bits 5-1: action = attribute value
change
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
469
Field
Message contents
Byte
Comments
9-10
Attribute mask
11-n
Attribute value of first attribute

changed (size depending on the
type of attribute)
...
Attribute value of last attribute
changed (size depending on the
type of attribute)
xx-40
OMCI trailer
Zero padding
41-48
NOTE 1 For table attributes, the AVC message does not contain an attribute value (only a mask), and no
snapshot of the table is created. If the OLT wishes to obtain the new value, it must then do a get operation,
followed by the required number of get next operations.
NOTE 2 If there is insufficient space in the message body for the new values of all changed (non-table)
attributes, the ONU should issue multiple AVCs, each with a consistent attribute mask and a list of new
attribute values, the total to include all changed attributes and their new values.
A.3.21 Test
The format of the test message is specific to the target entity class. A number of formats are
presently 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.
A.3.21.1 Format for ONU-G, ANI-G, RE ANI-G, PPTP RE UNI, RE upstream amplifier, RE
downstream amplifier and circuit pack entity classes
Field
Byte
Transaction correlation
identifier
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
NOTE This format applies to
entity classes ONU-G, ANI-G,
RE ANI-G, PPTP RE UNI, RE
upstream amplifier, RE
downstream amplifier and circuit
pack.
7-8
Entity instance
Message contents
470
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
xxxx = select test

0000..0110 reserved for future use
0111 self-test
See the description related to the
test result message.
Field
OMCI trailer
Byte
Comments
10-11
Pointer to a general purpose

buffer ME, used to return vendorspecific test results.
0 = unused (vendor-specific
results are not expected).
12-13
Pointer to an octet string ME,

used to define the vendor-specific
test parameters.
parameters are not specified).
14-40
Zero padding
41-48
A.3.21.2 Format for IP host config data and IPv6 host config entity classes
Field
Byte
Transaction correlation
identifier
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
entity classes IP host config data
and IPv6 host config data.
7-8
Entity instance
Message contents
10-13
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
xxxx = select test

0001 = Ping
0010 = Traceroute
0011 = Extended ping
0100..0111 Reserved
1000..1111 Vendor-specific use
The ICMP message is intended to
be from the ONU upstream
towards the network. See
discussion related to the test result
message.
Option 1: IPv4 address of target
(zero if byte 0 specifies extended
ping test)
Rec. ITU-T G.988 (10/2012)
471
Field
OMCI trailer
Byte
Comments
10-25
Option 2: IPv6 address of target

(zero if byte 0 specifies extended
ping test)
26
Number of times to ping.

This field pertains to both explicit
and extended ping tests. The value
0 selects the ONU's internal
default.
NOTE The number is bounded
by the size of the test result
message. It can be up to 15 for
explicit ping and up to 7 for
extended ping.
27-28
Pointer to large string ME that

identifies the target via a DNSparseable string. This field is used
only for the extended ping test.
-40
Zero padding
41-48

The test message for POTS UNIs supports two basic categories of test operation, a defined set of
tests that look in and out from the POTS port, and a set of code points that may be used for vendorspecific tests. The latter category is further subdivided into code points that return test results in a
general purpose buffer ME, using the test results message primarily as an event trigger to signal test
completion, and code points that return all test results in an ordinary test result message. If it is
needed, the OLT must create the general purpose buffer managed entity before initiating the test
action.
Note that a single message can be used to initiate multiple tests on a given ME if desired.
Bytes 10-23 are used by the dial tone make-break test. A zero value for a timer causes the ONU 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
ONU can support the dial tone test with internal defaults only, and it is not required to support any
of the attributes of bytes 10-23. Likewise, an ONU can use internal defaults for a drop test, rather
than the values given in bytes 24-33. The capabilities of an ONU are documented by the vendor and
known through administrative practices.
Field
Byte
Transaction
1-2
Message type
Device identifier
472
Rec. ITU-T G.988 (10/2012)
Comments
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
Field
Managed entity
identifier
Message contents
Byte
Comments
5-6
Entity class.
class PPTP POTS UNI.
7-8
Entity instance
tt
selects one of the POTS test

class formats
0
1
2..3 Reserved
x
Bits reserved for use in specific
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
1001..1011 = vendor-specific test, all
results returned in test results message
1100..1111 is a vendor-specific test,
test results returned in general
purpose buffer ME. The ONU should
deny a test operation command in this
range if bytes 34-35 do not point to a
GP buffer.
Test class 0:
Message contents
10
DBDT timer T1 (slow dial tone

11
DBDT timer T2 (no dial tone

12
DBDT timer T3 (slow break dial tone

13
DBDT timer T4 (no break dial tone

Rec. ITU-T G.988 (10/2012)
473
14
15
474
DBDT control byte

d: dialled digit
1 = dialled digit specified in
byte 15
0 = use default digit
p = pulse (1) or tone (0) dialling
Digit to be dialled, ASCII character in
range "0"-"9", "*", "#".
16-17
Dial tone frequency 1, in units of Hz
18-19

0 = unused (i.e., if only one tone is
specified).
20-21

0 = unused (i.e., if only one or two
tones are specified).
22
Dial tone power threshold, absolute

value, 0.1 dB resolution, range []0.1
to []25.3 dBm0, e.g., 13 dBm0 =
0x82. 0x00 = unspecified.
23
Idle channel power threshold,

absolute value, 1 dB resolution, range
[]1 to
[]90 dBm0. 0x00 = unspecified.
24
DC hazardous voltage threshold,

absolute value, volts 0x00 =
unspecified.
25
AC hazardous voltage threshold, volts

RMS 0x00 = unspecified
26
DC foreign voltage threshold,

absolute value, volts 0x00 =
unspecified
27
AC foreign voltage threshold, volts

RMS 0x00 = unspecified
28
Tip-ground and ring-ground

resistance threshold, k 0x00 =
unspecified
29
Tip-ring resistance threshold, k

0x00 = unspecified
30-31
Ringer equivalence minimum

threshold, in 0.01 REN units 0x00 =
unspecified
32-33
Ringer equivalence maximum

threshold, in 0.01 REN units 0x00 =
unspecified.
34-35

test results
Rec. ITU-T G.988 (10/2012)
OMCI trailer
36-37

define vendor-specific test
parameters.
parameters are not specified).
38-40
Zero padding
41-48
Test class 1:
Field
Message contents
OMCI trailer
Byte
Comments
a test mode
1 forced mode
x Reserved
10-25
ASCII string containing the number to

be dialled. Trailing unused octets are
padded with null bytes.
26-40
Zero padding
41-48
A.3.21.4 Format for dot1ag MEP entity class, loopback test

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
dot1ag MEP entity class.
7-8
Entity instance
Message contents
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
x=select test
0: Ethernet loopback test
1: IEEE 802.1ag linktrace test (see
separate format description below)
10
If c = 1, the value of the MEP's

CCM and LTM priority attribute is
used, with drop eligibility false.
If c = 0, pppd represents the priority
(P bits) and drop eligibility fields of
the transmitted LBM frame.
Rec. ITU-T G.988 (10/2012)
475
Field
Byte
11-16
MAC address of target MHF or

MEP, or 0 if the destination MEP ID
is to be used instead. [IEEE 802.1ag]
specifies unicast addresses;
[ITU-T Y.1731] also allows for
multicast.
17-18

1..8191, or 0 if the MAC address in
bytes 11-16 is to be used instead.
19-20
Repetition count, range 1..1024. This

governs how many LBMs are
generated. The rate at which LBMs
are generated is not specified. If
5 seconds elapse with no LBRs
received, the test aborts.
21-22
These four fields are pointers to as

many as four octet string MEs,
which are concatenated to form an
octet string of up to 1500 bytes. The
string is packaged into a data TLV
and transmitted as part of the LBM.
If all four fields are null pointers, no
data TLV is sent. If only one octet
string is needed, it should be
specified in bytes 21-22, etc., with
null pointers in the higher-numbered
bytes of the test message.
23-24
25-26
27-28
29-40
OMCI trailer
Comments
Zero padding
41-48
A.3.21.5 Format for dot1ag MEP entity class, linktrace test

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
dot1ag MEP entity class.
7-8
Entity instance
Message contents
476
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
x=select test
0: Ethernet loopback test (see
separate format description above)
1: IEEE 802.1ag linktrace test
Other values reserved.
Field
Byte
Comments
10
Flags, a bit map

f: Use FDB only. When 1, the bridge
uses only its normal MAC
forwarding tables for forwarding.
When 0, the bridge may also consult
its MIP CCM database to determine
the forwarding port.
11-16
Unicast MAC address of target MHF

or MEP, or 0 if the destination MEP
ID is to be used instead.
17-18

1..8191, or 0 if the unicast MAC
address in bytes 11-16 is to be used
instead.
19
OMCI trailer
Max hops count specifies initial

TTL (time to live); limits the number
of relay stages through which the
LTM is forwarded before being
discarded, and the number of LTRs
that may be returned.
[IEEE 802.1ag] recommends a
default value of 64.
20-21

ME, used to return the linktrace
results. The ONU should deny the
test operation command if this field
is a null or an invalid pointer.
22-40
Zero padding
41-48
A.3.22 Test response

If an ONU does not support all tests requested in byte 9 of the test message, it should not execute
any test and should respond with result 0010, command not supported. If an ONU 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 then be reissued with different thresholds or default thresholds, and would be
expected to succeed.
Field
Transaction
Byte
Comments
1-2
Message type
DB = 0, AR = 0, AK = 1
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
477
Field
Message contents
Byte
10-40
OMCI trailer
Comments
Result, reason
successfully
instance
0110 device busy
Zero padding
41-48
The test response message is an indication to the OLT that the test request is received and is being
processed.
A.3.23 Start software download
When a file is to be downloaded to a single instance of the software image managed entity, the ME
ID is specified in bytes 7-8. An optional feature permits the same file to be downloaded to a number
of circuit packs by setting bytes 7-8 = 0xFFFF and specifying the software image ME IDs in
bytes 15..16, etc.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
478
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
download
0
OMCI = 0x0A
0
ONU-G
1..254 slot number
255
entities
Field
Message contents
Byte

0
instance 0
1
instance 1
255
multiple download
Window size 1
10-13
OMCI trailer
Comments
Image size in bytes
14
Number of circuit packs to be

updated in parallel (value 1...9)
15

(slot number of circuit pack)
16

(value 0..1 or 2..254 vendorspecific)
17-n
Software image ME IDs (same

format as bytes 15..16) for
additional simultaneous downloads
xx-40
Zero padding
41-48
A.3.24 Start software download response

When a file is downloaded to a single software image ME, the response contains the target ME ID
in bytes 7-8, a result code in byte 9, a window size counter-proposal (which may be the same as that
suggested by the OLT in the original request) in byte 10, and 0 padding for the remaining bytes.
An ONU that supports the optional parallel download feature responds with the full format shown
below. If the ONU does not support the parallel download feature, it responds with the code
0b0101, unknown managed entity instance.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7
DB = 0, AR = 0, AK = 1
download
0
OMCI = 0x0A
0
ONU-G
1..254 slot number
255
entities
Rec. ITU-T G.988 (10/2012)
479
Field
Byte
Message contents

0
instance 0
1
instance 1
255
multiple download
0
Result, reason
successfully
instance
0110 device busy
10
Window size 1
11

(value 0..9)
12-13

instance (slot number plus instance
0..1 or 2..254 vendor-specific)
14
OMCI trailer
Comments
Result, reason for bytes 12..13

same coding as byte 9
15-n

additional requested software image
instances
xx-40
Zero padding
41-48
A.3.25 Download section

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
480
Rec. ITU-T G.988 (10/2012)
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
OMCI = 0x0A
Field
Managed entity
identifier
Message contents
Byte
5-6

0
ONU-G
1..254 slot number
255
entities

00
instance 0
01
instance 1
255
multiple download
10-40
OMCI trailer
Comments
Data; 0 padding if final transfer

requires only a partial block
41-48
A.3.26 Download section response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
DB = 0, AR = 0, AK = 1
bits 5-1: action = sw download
section
0
OMCI = 0x0A

0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
Rec. ITU-T G.988 (10/2012)
481
Field
Message contents
Byte
10
Result, reason
successfully
instance
0110 device busy
11-40
OMCI trailer
Comments
Zero padding
41-48
A.3.27 End software download

The format of this command is similar to that of the start software download message. Bytes 17..N
support the optional parallel download feature, and are set to 0 for download to a single target.
Field
Transaction
Byte
Device identifier
Managed entity
identifier
5-6
482
Comments
1-2
Message type
Message contents
DB = 0, AR = 1, AK = 0
download
0
OMCI = 0x0A

0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
9-12
CRC-32, computed over all bytes

of the software image (excluding
padding), as specified in
[ITU-T I.363.5].
13-16
Image size in bytes
17
Number of parallel download

instances sent in this message
(value 1..9)
18

(slot number of circuit pack)
Rec. ITU-T G.988 (10/2012)
Field
OMCI trailer
Byte
Comments
19

(value 0..1 or 2..254 vendorspecific)
20-n
Software image ME IDs (same

format as bytes 18..19) for
additional simultaneous downloads
xx-40
Zero padding
41-48
A.3.28 End software download response

The response message informs the OLT whether the download command was successful. If a single
software image ME was targeted for download, byte 9 reports the result of the process. Byte 9
reports device busy as long as any of the instances is busy writing the image to a non-volatile store.
Once the ONU has stored all images successfully, it responds with a 0 in byte 9 and a separate
result for each software image ME.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Message contents
DB = 0, AR = 0, AK = 1
download
0
OMCI = 0x0A

0
ONU-G
1..254 slot number
255
entities

0
instance 0
1
instance 1
255
multiple download
10
Result, reason
successfully (CRC correct)
(CRC incorrect)
instance
0110 device busy
(value 0..9)
Rec. ITU-T G.988 (10/2012)
483
Field
Byte
11-12

instance (slot number plus instance
0..1 or 2..254 vendor-specific)
13
OMCI trailer
Comments
Result, reason for bytes 11..12

same coding as byte 9
14-37

additional software image instances
38-40
Zero padding
41-48
A.3.29 Activate image

Because the end software download only signals completion after a new image has been stored in
non-volatile memory, it is possible for the OLT to send the activate image command immediately
after a successful end software download response.
Field
Transaction
Byte
Device identifier
Managed entity
identifier
5-6
484
Comments
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A

0
ONU-G
1..254
slot number

0
first instance
1
second instance
Bits FF:
00 Activate image
unconditionally
progress
emergency call is in
progress (Note)
11 Reserved
If the ONU denies the Activate
image command because of the FF
field, it returns result, reason code
0110, device busy.
10-40
OMCI trailer
1-2
Message type
Message contents
41-48
Rec. ITU-T G.988 (10/2012)
Zero padding
Field
Byte
Comments
NOTE The ONU determines the presence of an originating emergency call on the basis of the
A.3.30 Activate image response

Field
Transaction
Byte
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A

0
ONU-G
1..254
slot number

0
first instance
1
second instance
Result, reason
successfully
instance
0110 device busy
10-40
OMCI trailer
1-2
Message type
Message contents
Zero padding
41-48
Rec. ITU-T G.988 (10/2012)
485
A.3.31 Commit image

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
DB = 0, AR = 1, AK = 0
0
Message contents
9-40
OMCI trailer
41-48
OMCI = 0x0A
0
ONU-G
1..254
slot number

0
first instance
1
second instance
Zero padding
A.3.32 Commit image response

Field
Transaction
Byte
Device identifier
Managed entity
identifier
5-6
Comments
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A

0
ONU-G
1..254
slot number

0
first instance
1
second instance
Result, reason
successfully
instance
0110 device busy
10-40
486
1-2
Message type
Message contents
Rec. ITU-T G.988 (10/2012)
Zero padding
Field
OMCI trailer
Byte
Comments
41-48
A.3.33 Synchronize time

The synchronize time command controls the tick boundary for performance monitoring collection,
and optionally, a date and time clock.
If this message specifies the time (and optionally the date), the ONU sets its PM interval counter to
a current offset from the most recent quarter-hour boundary, that is, to a value in the range
0..899 seconds. This may cause the current PM collection interval to be longer or shorter than
900 seconds. Date and time are not explicitly required in an ONU, but if the ONU has a real-time
clock, it is also set by this message. If the OLT does not wish to specify a date, it may set year,
month and day fields to 0.If the ONU does not support the setting of the date, it will use the success
result info field in the synchronize time response message to indicate that only the 15-minute tick
boundary was set.
If date and time are not present in the message, the ONU sets its PM interval counter to 0. This may
cause the current PM collection interval to be shorter than 900 seconds. The effect on a possible
ONU real-time clock is not specified.
There is no intention that this message be used to establish a precise time of day reference.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
9-10
Year, e.g., 2009
OMCI = 0x0A
11
Month, range 1..12
12
Day of month, range 1..31
13
Hour of day, range 0..23
14
Minute of hour, range 0..59
15
Second of minute, range 0..59
16-40
OMCI trailer
DB = 0, AR = 1, AK = 0
bits 5-1: action = synchronize time
Zero padding
41-48
Rec. ITU-T G.988 (10/2012)
487
A.3.34 Synchronize time response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
7-8
Entity instance = 0
Message contents
DB = 0, AR = 0, AK = 1
Bits 5-1: action = synchronize time
0
Result, reason
successfully
instance
0110 device busy
10
Success result info this field has a

meaning only when the result,
reason code in byte 9 was '0000
command processed successfully'.
0000 15-minute tick boundary set
successfully
0001 Date and 15-minute tick
boundary set successfully
11-40
OMCI trailer
OMCI = 0x0A
Zero padding
41-48
A.3.35 Reboot
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
488
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
Field
Byte
Comments
Bits FF:
00 Reboot unconditionally
progress
emergency call is in
progress (Note)
11 Reserved
If the ONU denies the reboot
device busy.
Message contents
10-40
OMCI trailer
Zero padding
41-48
NOTE The ONU determines the presence of an originating emergency call on the basis of the
A.3.36 Reboot response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
10-40
OMCI trailer
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Result, reason
successfully
instance
0110 device busy
Zero padding
41-48
Rec. ITU-T G.988 (10/2012)
489
A.3.37 Get next

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-10
Attribute mask
11-12
13-40
Zero padding
OMCI trailer
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
41-48

A.3.38 Get next response
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
OMCI trailer
DB = 0, AR = 0, AK =1
0
OMCI = 0x0A
Result, reason
successfully
instance
0110 device busy
10-11
Attribute mask
12-n
Attribute value (size depending on

the type of attribute)
xx-40
Zero padding
41-48
If the ONU receives a get next request message whose command sequence number is out of range,
the ONU responds with parameter error.
490
Rec. ITU-T G.988 (10/2012)
A.3.39 Test result

The test result message reports the outcome of a test. In the case of a requested test, the transaction
correlation identifier of the test result message is identical to the transaction correlation identifier of
the test message that initiated the corresponding test. In the case of a self-triggered test result, the
transaction correlation identifier is set to 0.
Several formats are currently defined. They are used as follows:
self-test results, ONU-G, circuit pack, or any other ME that supports selftest;
vendor-specific test results, generic format, any ME that supports it;
POTS test results, either MLT, dial tone draw-break or vendor-specific POTS tests that use
a general purpose buffer;
ICMP tests, either ping or traceroute;
the results of an optical line supervision test on the ANI-G, RE ANI-G, PPTP RE UNI, RE
upstream amplifier or RE downstream amplifier;
[IEEE 802.1ag] loopback and linktrace tests.

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.
A.3.39.1 Format for self-test action invoked against ONU-G and circuit pack entity classes
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
NOTE This message format
pertains to ONU-G and circuit pack
entity classes.
7-8
Entity instance
Message contents
OMCI trailer
DB = 0, AR = 0, AK = 0
0
OMCI = 0x0A
Unused
10
Self-test result:
xx = 00: failed
xx = 01: passed
xx = 10: not completed
11-12

tests that require a GP buffer,
otherwise zero.
13-40
Zero padding
41-48
Rec. ITU-T G.988 (10/2012)
491
A.3.39.2 Format for vendor-specific test actions invoked against ONU-G and circuit pack
entity classes
This format is also used for vendor-specific test actions invoked against the PPTP POTS UNI entity
class when no general purpose buffer is needed.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
pertains to ONU-G, circuit pack
and PPTP POTS UNI entity
classes.
7-8
Entity instance
Type 1 (Note)
Message contents
OMCI trailer
DB = 0, AR = 0, AK =0
0
OMCI = 0x0A
10-11
Value 1
12
Type 2
13-14
Value 2
15
Type 3
16-17
Value 3
18
Type 4
19-20
Value 4
21
Type 5
22-23
Value 5
24
Type 6
25-26
Value 6
27
Type 7
28-29
Value 7
30
Type 8
31-32
Value 8
33
Type 9
34-35
Value 9
36
Type 10
37-38
Value 10
39-40
Zero padding
41-48
NOTE Test result types are specified in clause 11.2.10. Type-value fields are packed in the lowest byte
positions. Unused trailing byte positions are filled with 0 values. If more than ten type-value pairs are to be
returned, an additional test type should be defined in the test message. At the vendor's discretion, a test
result may include an ordered sequence of repeated type-value pairs to represent, for example, port
ordering, or first/second power input. In this case, missing values can be flagged with type = 255.
492
Rec. ITU-T G.988 (10/2012)

Byte 9 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 11 and 12 report the results of a dial tone
test.
Byte 10 reports the result of a self-test or a vendor-specific test that returns results in a general
purpose buffer. At present, self-test is not supported for the PPTP POTS UNI entity class, 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 ONU. If an ONU does not support or recognize a given test, it is expected to deny the test
request message. To avoid physical damage, an ONU may cease testing if a test usually hazardous
potential fails, and thus some subsequent tests will not be run. In addition, the ONU 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 9 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.
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
pertains to PPTP POTS UNI entity
class.
7-8
Entity instance
Message contents
DB = 0, AR = 0, AK = 0
0
OMCI = 0x0A
tt selects one of the POTS test

class formats
0 MLT, dial tone make-break
1 SIP/ITU-T H.248 test call
2..3 Reserved
x Bits reserved for use in specific
Rec. ITU-T G.988 (10/2012)
493
Test class 0:
Message contents
494
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
10
Result of self-test or
vendor-specific test:
xx = 00: failed
xx = 01: passed
xx = 10: not completed
11
Dial tone make-break flags:

ddd Dial tone draw
= 000 test not run
= 01 m failed, could not draw
= 10 m slow draw
= 11 m passed
bbb Dial tone break
= 000 test not run
= 01 m failed, could not break
= 10 m slow break
= 11 m passed
m measured value flag
= 0 measurement not reported
= 1 measurement reported
12
Dial tone power flags:

aaa quiet channel power
bbb dial tone power
(Note)
13
Loop test DC voltage flags

aaa VDC, tip-ground
bbb VDC, ring-ground
(Note)
14
Loop test AC voltage flags

aaa VAC, tip-ground
bbb VAC, ring-ground
(Note)
15
Loop test resistance flags 1

aaa resistance, tip-ground
bbb resistance, ring-ground
(Note)
Rec. ITU-T G.988 (10/2012)
16
Loop test resistance flags 2

aaa resistance, tip-ring
bbb ringer load test
(Note)
17
Time to draw dial tone, in 0.1

second units. Valid only if byte 11
ddd = xx1.
18
Time to break dial tone, in 0.1

second units. Valid only if byte 11
bbb = xx1.
19
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
20
Quiet channel power measurement,

unsigned absolute value, 1 dB
resolution, range 0 to []90 dBm0.
21-22
Tip-ground DC voltage, 2s
complement, resolution 1 V. Valid
23-24
Ring-ground DC voltage, 2s
25
Tip-ground AC voltage, Vrms.

26
Ring-ground AC voltage, Vrms.

Valid only if byte 14 bbb = xx1.
27-28
Tip-ground DC resistance, k.
Infinite resistance: 0xFFFF. Valid
29-30
Ring-ground DC resistance, k.
Infinite resistance: 0xFFFF. Valid
31-32
Tip-ring DC resistance, k. Infinite

resistance: 0xFFFF. Valid only if
byte 16 aaa = xx1.
33
Ringer equivalence, in 0.1 REN

units. Valid only if byte 16
bbb = xx1.
34-35
36

a
Loop tip-ring test AC/DC voltage

flags
aaa VAC, tip-ring
bbb VDC, tip-ring
(Note)
Rec. ITU-T G.988 (10/2012)
495
37
Tip-ring AC voltage, Vrms. Valid

38-39
Tip-ring DC voltage, 2s
40
OMCI trailer
Zero padding
41-48
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.
Test class 1:
Field
Message contents
Byte
Comments
yyy report the results of the test
000 Test failed
001 Test passed
010 Not completed, line off hook
011 Not completed, other reason
100 Reserved
101 Reserved
110 Reserved
111 Reserved
x Reserved
10-40
OMCI trailer
Zero padding
41-48
A.3.39.4 Format for test action invoked against IP host config data and IPv6 host config data
entity classes
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
entity classes IP host config data
and IPv6 host config data.
7-8
Entity instance
496
Rec. ITU-T G.988 (10/2012)
DB = 0, AR = 0, AK = 0
0
OMCI = 0x0A
Field
Message contents
Byte
Comments
Test result:
xxx = 000: timed out, no response
xxx = 001: ICMP echo responses
attached
xxx = 010: ICMP time exceeded
responses attached
xxx = 011: Unexpected ICMP
response
xxx = 100: target address in large
string ME could not be
resolved
xxx = 101-111: Reserved
10
yyyyy: number of meaningful bytes

in the remainder of the test result
message. In the case of extended
ping, this field is the number of
bytes that contain delay
measurement values.
If xxx = 001 (echo response ping), the remainder of the message contains the following content. If
the test message specifies the number of times to ping, the ONU should generate that number of
echo requests; otherwise the number of echo requests generated is the ONU vendor's default. The
resolution of the delay measurement is vendor-specific. The special value 0xFFFF indicates a lost
response.
11-12

delay 1, expressed in ms
13-14

delay 2, expressed in ms
25-40
OMCI trailer
Etc.
For ping test 0001, these bytes can
be either delay measurements or
padding.
For extended ping, these bytes
contain the actual IP address that
was pinged, 4 bytes for IPv4,
16 bytes for IPv6. If the network
address was not resolvable, the
ONU should set these bytes to all
zeroes.
41-48
If xxx = 010 (time exceeded traceroute), the remainder of the message contains the following
content. In PON applications, it is not expected that a route trace will exceed the available space in
the message, but if it does, the more distant responses should be dropped. There is only enough
space in the message body for a single IPv6 address.
Rec. ITU-T G.988 (10/2012)
497
11-14
IP address of the nearest neighbour
15-18
IP address of the second nearest

neighbour
Etc.
-40
OMCI trailer
Zero padding
41-48
If xxx = 011 (unexpected ICMP response), the remainder of the message contains the following
content:
OMCI trailer
11
Type
12
Code
13-14
Checksum
15-18
Bytes 5-8 of ICMP message

(meaning depends on type/code)
19-40
Internet header + 64 bits of original

datagram (truncated)
41-48
A.3.39.5 Format for optical line supervision test action invoked against ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream amplifier or RE downstream amplifier entity class
Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
pertains to ANI-G, RE ANI-G,
PPTP RE UNI, RE upstream
amplifier or RE downstream
amplifier entity class.
7-8
Entity instance
Message contents
DB = 0, AR = 0, AK =0
0
10-11
12
Type = 5, Mean optical launch

power
resolution
19-20
498
Type = 3, received optical power

resolution
16-17
18
Type = 1, power feed voltage

V, 2s complement, 20 mV
resolution
13-14
15
OMCI = 0x0A
Rec. ITU-T G.988 (10/2012)
Type = 9, laser bias current

Field
OMCI trailer
Byte
21
Comments
Type 12, temperature, degrees
22-23
2s complement, 1/256 degree C

resolution
24-25

26-40
Zero padding
41-48
NOTE Unsupported tests are indicated with test type indicator 0 and 2 bytes of 0 data.
A.3.39.6 Format for test action invoked against dot1ag MEP entity class, loopback test
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
pertains to the dot1ag MEP entity
class.
7-8
Entity instance
Message contents
OMCI trailer
DB = 0, AR = 0, AK =0
0
OMCI = 0x0A

loopback replies (LBRs) within
5 seconds
10-11
Valid LBRs count: the number of

valid, in-order LBRs received.
12-13
Out of order LBRs count: the

number of valid LBRs received that
were out of order.
14-15
Mismatch LBRs count: the number

of received LBRs whose MAC SDU
did not match that of the
corresponding LBM (except for
opcode). Optional feature, set to
0xFF if not supported.
16-19
Delay from LB message

transmission to LB response
reception, measured in
microseconds. The value 0 indicates
no information available.
20-40
Zero padding
41-48
Rec. ITU-T G.988 (10/2012)
499
A.3.39.7 Format for test action invoked against dot1ag MEP entity class, linktrace test
Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class.
pertains to the dot1ag MEP entity
class.
7-8
Entity instance
Message contents
OMCI trailer
DB = 0, AR = 0, AK =0
0
OMCI = 0x0A

linktrace replies (LTRs) within
5 seconds
10-13
Transaction ID of transmitted LTM
14-21
Content of egress TLV data field in

transmitted LTM ([IEEE 802.1ag],
clause 21.8.8). The LTRs themselves
are captured in the general purpose
buffer designated by the test
command.
22-40
Zero padding
41-48
A.3.40 Get current data

Field
Byte
Transaction
1-2
Comments
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
9-10
Attribute mask
11-40
Zero padding
OMCI trailer
DB = 0, AR = 1, AK = 0
0
OMCI = 0x0A
41-48
Based on the size of the message contents field, the aggregate size of the attributes requested by a
single get current data command should not exceed 25 bytes.
500
Rec. ITU-T G.988 (10/2012)
A.3.41 Get current data response

Field
Transaction
Byte
Comments
1-2
Message type
Device identifier
Managed entity
identifier
5-6
Entity class
7-8
Entity instance
Message contents
DB = 0, AR = 0, AK = 1
0
OMCI = 0x0A
Result, reason
successfully
instance
0110 device busy
10-11
Attribute mask
12-n
Attribute value of first attribute

included (size depending on the type
of attribute)
Attribute value of last attribute

included (size depending on the type
of attribute)
OMCI trailer
xx-36
Zero padding
37-38

1001 encoding:
0 = default
39-40

1001 encoding:
0 = default
41-48
Bytes 37 to 40 are always reserved for the optional attribute and attribute execution masks;
however, the contents of these bytes are only valid in conjunction with the 1001 encoding used to
indicate failed or unknown attributes.
Rec. ITU-T G.988 (10/2012)
501
Annex B
OMCI in ITU-T G.984 and ITU-T G.987 systems
B.1
Establishing the ONU management and control channel (OMCC)
This clause should be read in conjunction with [ITU-T G.984.3] or [ITU-T G.987.3], as applicable
to the system under consideration.
Upon initialization, the ONU creates a default alloc-ID for the OMCC. The default alloc-ID neither
requires nor uses a T-CONT. The discussion below explains when a T-CONT may meaningfully be
associated with the default alloc-ID.
The establishment of the OMCC follows the process shown in Figure B.1-1. During activation, the
ONU receives a PLOAM message from the OLT indicating the assignment of the ONU-ID. The
ONU creates the default alloc-ID with the same value as the ONU-ID. It is therefore not necessary
for the OLT to send an assign_alloc-ID message to establish the OMCC. If the OLT nevertheless
chooses to send an assign_alloc-ID PLOAM with the default alloc-ID, the ONU should
acknowledge this message without taking any specific further action. This is true regardless of the
alloc-ID type value in the assign_alloc-ID message: it is not allowed to de-allocate the default
alloc-ID with an assign_alloc-ID type 255 message.
Upon completion of ONU activation in ITU-T G.984 systems, the OLT assigns a GEM port-ID to
the ONU for OMCI messages. This is accomplished by a configure_port-ID PLOAM message. The
ONU maps the OMCI port-ID attribute to OMCC traffic and the default alloc-ID, and responds
back to the OLT with an acknowledgment.
In ITU-T G.987 systems, the GEM port for OMCI use is automatically assigned, and is equal to the
ONU-ID.
At this point, the OMCC path has been successfully established.
OLT
ONU
Assign_ONU-ID PLOAM message
ONU sets OMCI alloc-ID
to ONU-ID
ITU-T G.987: ONU sets OMCI
GEM port to ONU-ID.
Registration
process
Ranging grant
ITU-T G.984: serial_number_ONU PLOAM message
ITU-T G.987: Registration PLOAM message
OMCI
connection
setup
Ranging_time PLOAM message

ITU-T G.987: Acknowledge PLOAM message
ITU-T G.984: Configure_port-ID PLOAM message
ITU-T G.984: ONU sets OMCI
GEM port
ITU-T G.984: Acknowledge PLOAM message
G.988(12)_FB.1-1
Figure B.1-1 OMCC establishment
502
Rec. ITU-T G.988 (10/2012)
While it is not forbidden, it is not recommended that the default alloc-ID be used to carry subscriber
traffic. If subscriber traffic is nevertheless to be carried in the default alloc-ID, this alloc-ID must be
mapped to a T-CONT through normal OMCI messages.
OMCI traffic then consumes bandwidth allocated to the designated alloc-ID, but with strictly higher
priority than all other traffic in the same alloc-ID. DBA reports for such a dual-purpose alloc-ID
include both OMCI and subscriber traffic queues.
A T-CONT shared with the OMCC can be deallocated for subscriber traffic, in which case it
disappears from the MIB view of the ONU. OMCC traffic over the default alloc-ID cannot be
removed, deleted or redirected.
After the OMCC has been established, it is possible for the OLT to enable encryption on the OMCC
GEM port. In ITU-T G.984 systems, this is accomplished by the OLT sending an encrypted_portID PLOAM that names the OMCC GEM port.
In [ITU-T G.987], port encryption is normally established through the corresponding GEM port
network CTP. The OMCC has no such associated managed entity, so it relies on defaults. If the
GEM frame itself contains an encryption key index, it is understood to refer to the unicast key and
to require encryption both upstream and down. OMCI message channel failure may indicate the
absence or miscoordination of unicast keys.
Regardless of OMCC encryption, ITU-T G.987 OMCI messages are protected by a message
integrity check (MIC), whose computation is specified in [ITU-T G.987.3].
B.2
OMCI handling within the ONU
Message response times should not exceed one second. The message definition considers cases
where command execution may take longer than this. For example, in executing tests, the ONU
acknowledges the test command from the OLT within the required one second, then initiates an
autonomous test result message at some later time when the test is complete. Another example is
the case where downloaded software may take some significant time to write into a non-volatile
store; in this case, the ONU responds to the end download command from the OLT with a device
busy code, and the OLT retries periodically until the operation is complete.
B.2.1
Message flow control and error recovery
NOTE Prioritized message handling is defined only for the baseline OMCI message set. In the context of
the extended message set, this clause should be read with the understanding that there is only one priority
class.
The flow control/error recovery procedures for message exchange over the OMCC are based on a
simplex acknowledged transaction stop-and-wait mechanism that can 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 ONU 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 on a message integrity check (MIC) to verify the data integrity of all
received messages.
When a transaction request message of priority level i is sent to an ONU, a transaction request timer
Ti is started. Timer Ti is stopped upon receipt of an acknowledgement message containing the same
transaction correlation identifier value. If a valid acknowledgement message is not received by the
OLT after timer Ti expires at time Tmaxi, the OLT re-sends the original transaction request
message. A retransmitted acknowledged transaction request message carries the same transaction
correlation ID as the original message.
Rec. ITU-T G.988 (10/2012)
503
Retry counter Ri is defined at priority level i. Upon the first transmission of a new command at
priority i, Ri is initialized to zero, and each time an acknowledged transaction request message is
retransmitted, the OLT increments Ri. When Ri reaches the maximum retry value, Rmaxi, the OLT
stops retransmitting the message and declares an OMCC link state error.
These timers (Ti) and retry counters (Ri) are only maintained within the OLT and do not exist
within the ONU. 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 the high priority
Tmax should account for the typical message transmission delay plus the command message
response time.
These flow control/error recovery procedures are illustrated in Figure B.2.1-1 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. While message 1 is outstanding, the OLT issues message 2 with
priority level 1. Both of these commands are received and executed with the associated response
messages returned to the OLT by the ONU. 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). From the identical transaction ID, the ONU detects that this retransmitted
command is identical to the last received priority level 1 command and therefore does not
re-execute it. The ONU simply retransmits the original response from the previous execution of
message 2, which in Figure B.2.1-1 reaches the OLT in time.
The final transaction in the example shows the case where 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 ONU. After the associated timer (T0) expires, the OLT retransmits the
command and now all goes well.
504
Rec. ITU-T G.988 (10/2012)
OLT
Start T 0
Start T 1
ONU
Message 1/Priority 0/AR = 1/AK = 0/TID = 1234
Execute
message 1
Execute
message 2

Stop T0
(< Tmax0)
Message 2 reply/Priority 1/AR = 0/AK = 1/TID = 8123
T1 expires
( Tmax1)
Re-send message 2
Increment R 1
Start T 1
Stop T1
(< Tmax1)
Discard message 2
(do not re-execute)

Start T 0
T0 expires
( Tmax0)
Re-send message 3
Increment R 0
Start T 0
Stop T0
(< Tmax0)
Execute
message 3

G.988(12)_FB.2.1-1
Figure B.2.1-1 Concurrent message exchange with error recovery

A case where the OMCC link is effectively broken (link down) is shown in Figure B.2.1-2.
Rec. ITU-T G.988 (10/2012)
505
OLT
Start T 0
ONU
T0 expires
( Tmax0)
Re-send message 4
Increment R 0
Start T 0
T0 expires
( Tmax0)
Re-send message 4
Increment R 0
Start T 0
T0 expires
Declare link error
G.988(12)_FB.2.1-2
Figure B.2.1-2 OMCC link error detection

B.2.2
Prioritized protocol entities
NOTE 1 Prioritized message handling is defined only for the baseline message set. In the context of the
extended message set, this clause should be read with the understanding that there is only one priority class.
This clause specifies the behaviour of the ONU more precisely than in the preceding clause with
respect to the prioritized request mechanism of the OMCC.
Conceptually, the way the ONU handles the OMCC requests can be illustrated by referring to the
dual priority level implementation example shown in Figure B.2.2-1.
When the ONU receives a GEM frame via the GEM port associated with the management channel,
it calculates the MIC and compares it with the value found in the OMCI trailer. If the values do not
match, the ONU discards the message. It is recommended that this event be logged by the ONU and
possibly communicated to the OLT by an out-of-band mechanism but, as far as the protocol is
concerned, the message is discarded silently.
NOTE 2 Loss of encrypted OMCI communications with an otherwise functional ONU may indicate lost or
corrupt keys. The OLT is advised to renegotiate keys or to fall back to an unencrypted OMCI as the first
steps in diagnosing the trouble.
Messages with a correct MIC are then placed into either of two distinct incoming message queues,
according to the high or low priority level of the associated command encoded in the most
significant bit of the transaction correlation identifier field. If the associated incoming message
queue is already full, the ONU discards the message. It is recommended that this event be logged by
the ONU and possibly communicated to the OLT by an out-of-band mechanism but, as far as the
protocol is concerned, the message is discarded silently.
There are two distinct incoming command processing protocol entities, one associated with each
priority level, which serve messages sequentially from independent incoming queues. Each protocol
entity can execute concurrently. If a message is a one-way (unacknowledged) command, the
protocol entity simply executes the command. If a message is an acknowledged command, the
506
Rec. ITU-T G.988 (10/2012)
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 executes the command and places the response/acknowledgement, with an identical
transaction correlation identifier, in the outgoing 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 (the
case where the OLT retransmits a command due to a lack of proper acknowledgement), the protocol
entity does not actually execute the command but simply places the response from the last
execution of that command in the outgoing queue to resend the previous acknowledgement
response. In both cases, the command processing protocol entity for a given priority level should
block until there is room in the associated outgoing queue for the response message.
In the upstream direction, requests by ONU applications to send autonomous event notifications
simply result in the corresponding messages being directed to an event notification protocol entity
for transmission to the OLT. The event notification protocol entity forwards these event notification
messages to the low priority outgoing queue. In this case as well, the event notification protocol
entity should block until there is room in the low priority outgoing queue to hold the notification
message. The MIC generator removes messages from the outgoing queues using a strict priority
discipline (that is, the low-priority queue is served only when the high-priority queue is empty),
generates an MIC, formats the packet as either a baseline or an extended message, depending on
which form is in use, and transmits the message to the OLT.
MIC generation
High priority
queue
Low priority
queue
MIC validation
Possible
discard
High priority
queue
Low priority
queue
Event notification
protocol entity
High priority
protocol entity
Applications
Low priority
protocol entity
G.988(12)_FB.2.2-1
Figure B.2.2-1 Protocol entities within the ONU

B.2.3
Restrictions on actions in relation to the protocol entities
To reduce the complexity and the amount of memory necessary in the ONU, 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.
B.2.4
Use of the default alloc-ID
The upstream OMCC is carried in the default allocation_ID. In some implementations, the default
alloc_ID is also used for user traffic, and is associated with a T-CONT ME. In these cases, the
OMCC traffic is combined with the user traffic using simple strict priority multiplexing, with the
OMCC having a higher priority.
Rec. ITU-T G.988 (10/2012)
507
Annex C
OMCI in Ethernet PON systems
C.1
Establishing the ONU management and control channel (OMCC)
Ethernet PON registration is described in [IEEE 802.3] clauses 64 and 77; the differences between
the descriptions are immaterial to the establishment of the OMCC.
The OMCC for an Ethernet PON is established during the ONU discovery process. Figure C.1-1
replicates the illustration of the ONU discovery process from [IEEE 802.3] clause 77. During the
discovery process, the OLT and ONU exchange their MAC addresses and physical parameters. The
OLT then assigns a unique logical link ID (LLID) to the ONU, whereupon a logical connection
between the OLT and ONU is established. When this discovery handshake is complete, the OMCC
has been established. No additional process is needed to establish the OMCC in an Ethernet PON
system.
ONU
OLT
GATE1
DA = MAC control
SA = OLT MAC address
Content = Grant + Sync time + Discovery information
Grant start
1
Discovery
window
REGISTER_REQ
DA = MAC control
SA = ONU MAC address
Content = Pending grants + Discovery information + Laser on
time + Laser off time
Random
delay
REGISTER1
DA = ONU MAC address
Content = LLID + Sync time + Echo of pending grants +
Target laser on time + Target laser off time
GATE2
DA = MAC control
Content = Grant
2
REGISTER_ACK
DA = MAC control
SA = ONU MAC address
Content = Echo of LLID + Echo of sync time
Discovery handshake completed
OMCC established
OMCC established
1
Messages sent on broadcast channel

Messages sent on unicast channel
G.988(12)_FC.1-1
Figure C.1-1 OMCC establishment process, Ethernet PON
508
Rec. ITU-T G.988 (10/2012)
C.2
Encapsulating OMCI messages in Ethernet frames
The extended OAM frame defined in IEEE 802.3 is used for the EPON OMCI frame format.
Figure C.2-1 shows the extended OAM frame for EPON OMCI.
Extended OMCI message - variable length up to 1493 bytes
OMCI Ethernet frame

Preamble Destination
MAC
and LLID/
address
SFD
(6 bytes)
(8 bytes)
Source
MAC
address
(6 bytes)
Transaction
correlation
identifier
(2 bytes)
Message
type
(1 byte)
Device
identifier
(1 byte)
Managed
entity
identifier
(4 bytes)
Message
contents
length
(2 bytes)
Message
contents
(variable)
MIC
(excluded)
Extended
OAM
Ethertype
(2 bytes)
Subtype
(1 byte)
Flags
(2 bytes)
Code
(1 byte)
OUI
(3 bytes)
OMCI
message
Frame
check
sequence
(4 bytes)
Preamble and LLID (EPON)

<mode,
0x55
0x55
0x55
0x55
CRC8
0xd5
logical_link_id [14:8]> <logical_link_id [7:0]>
(1 byte) (1 byte) (1 byte) (1 byte) (1 byte)
(1 byte)
(1 byte)
(1 byte)
Coverage of CRC8
G.988(10)_FC.2-1
Figure C.2-1 Extended OAM frame structure for EPON OMCI

The extended OAM frame format and fields for the OMCI are defined in Table C.2-1.
Table C.2-1 Extended OAM frame format and fields for EPON OMCI
Field
Length
Definition
Value
Preamble and
LLID/SFD
8 bytes
Defined in clause 4.2 and

clause 76 of [IEEE 802.3]
LLID is assigned during

ONU discovery process
Destination MAC
address
6 bytes
Destination MAC address
0x0180C2000002
Source MAC address
6 bytes
Source MAC address
MAC address of source

equipment
Ethertype
2 bytes
[IEEE 802] clause 57
0x8809 (Slow protocol)
Subtype
1 byte
0x03 (OAM)
Flags
2 bytes
Code
1 byte
0xFE
OUI
3 bytes
ITU-T OUI
0x0019A7
OMCI message
up to
1493 bytes
Defined in clauses 11 and A.2.

Extended OMCI message
Excludes MIC (4 bytes)
Frame check sequence

FCS
4 bytes
Defined in [IEEE 802.3]
Rec. ITU-T G.988 (10/2012)
509
C.3
Relationship between the OMCI and OAM defined in IEEE 802.3, clause 57
Clause 57 of [IEEE 802.3] describes OAM as an optional function. Items described in this clause
can be covered by the OMCI. In most cases, an ITU-T G.988 support system does not need to
support [IEEE 802.3] clause 57 OAM; however, it is a system dependent matter.
Table C.3-1 Relationship between [IEEE 802.3] clause 57 OAM and OMCI
#
Items in IEEE 802.3 clause 57
Corresponding OMCI functionalities
Information
This item is the OAM channel set-up procedure. It is provided

by the OMCC initial set-up procedures.
Event notification
This item is alarm notification. It is provided by the alarm

notification function defined in the OMCI.
Variable request/response
This item can be interpreted as MIB get/set. The OMCI

supports the same functions.
Loopback control
This item is provided by OMCI loopback control.
C.4
Adaptation of the G-PON information model to EPON
C.4.1
Overview
Table 8-1 lists the managed entities that are mandatory or not applicable for EPON systems. Some
MEs are redefined in the present clause for use in EPON.
Managed entities on the ANI side were originally defined for the G-PON system architecture. In an
EPON system, the PON framing protocol is different from G-PON or XG-PON. To adapt the
OMCI to an EPON system, the following interpretations are required.
In EPON, GEM ports and T-CONTs are not defined, because EPON conveys Ethernet frames
transparently in the PON section. However, these differences can be absorbed by the interpretation
shown in Table C.4-1. On the other hand, the MEs on the UNI side are usable without modification.
Table C.4-1 Interpretation of ANI-side MEs
#
Items
Interpretation in EPON system
GEM port
The concept of GEM port is interpreted as a layer 2 flow such as VLAN, CoS,
etc. In an EPON system, GEM port network CTP and GEM interworking
termination point MEs exist for binding the layer 2 flows and priority queue
MEs and the MAC bridge ME.
T-CONT
The T-CONT is the unit of bandwidth assignment. In an EPON system, the

unit of bandwidth assignment is the logical link.
For providing an Ethernet service to users in a PON system,
G-PON/XG-PON1: Ethernet flows are encapsulated by GEM/XGEM in the PON section.
EPON/10G-EPON: Ethernet flows are transparently conveyed in the PON section.

Except for GEM encapsulation, there is no difference between G-PON and EPON. MEs on the UNI
side are compatible in both systems. Both systems require QoS configuration, cross connection,
filtering, VLAN operation, etc., for each layer 2 service flow.
510
Rec. ITU-T G.988 (10/2012)
VLAN operation, filtering, cross connection,

priority mapping, rate limiting, etc.
PQs, downstream
MEs on the UNI side

(eg.. L2 data service)
GEM port
Interworking Network
TP
CTP
Downstream
...
UNI
GEM port
PPTP
Extracting L2 flow
from GEM port
MEs on the UNI side
Upstream
Mapping L2 flow
to GEM port
GEM ports
PQs, upstream
...

T-CONT
ANI
G.988(10)_FC.4.1-1
Figure C.4.1-1 Layer 2 flows in G-PON ONU

By introducing the concept of a virtual GEM port into the OMCI, the MEs in this Recommendation
can be re-used for EPON. In G-PON, a GEM port is defined to convey each layer 2 flow. The GEM
port network CTP connects the MAC bridge port and upstream/downstream priority queues in the
ONU for an Ethernet service. EPON requires the same configuration of connectivity between the
MAC bridge port and upstream/downstream priority queues. By configuring the GEM ports
virtually, G-PON and EPON are compatible in the OMCI. A virtual GEM port exists for the
purpose of connecting the MAC bridge port and priority queue. GEM port network CTP and GEM
interworking termination point MEs are created for the ME pointer relationship.
What this means is that the GEM port network CTP is re-used in EPON, but the value of the GEM
port attribute is not used. It is suggested that it be set to 0 by the OLT, and it must be ignored by the
ONU.
Rec. ITU-T G.988 (10/2012)
511

PQs, downstream
MEs on the UNI side

Virtual GEM port

Interworking Network
TP
CTP
...
UNI
Downstream
L2 flows
GEM port
PPTP
MEs on the UNI side

PQs, upstream
T-CONT
(Logical link) ANI
L2 flows
Virtual GEM ports
Upstream
...

G.988(10)_FC.4.1-2
Figure C.4.1-2 Virtual GEM ports in EPON ONU

C.4.2
ME definitions
This clause modifies certain MEs from their definitions in clause 9. Where no change is noted, the
clause 9 definition remains applicable.
C.4.2.1
Clause 9.2.3: GEM port network CTP
This managed entity represents the termination of a GEM port on an ONU. In an EPON system, the
GEM port exists virtually for keeping the pointer relationship. The value of the port-ID attribute is
"don't care" because it does not represent an actual Port-ID. The optional attributes encryption state
and encryption key ring are not used in an EPON system for the same reason.
Relationships
No change required.
Attributes
Table C.4.2.1-1 summarizes the attributes of the GEM port network CTP for EPON.
Table C.4.2.1-1 Attributes of GEM port network CTP
Attributes
R/W, M/O
Definition changes in EPON
Managed entity ID
(R, Set-by-create) (mandatory)
No change required.
Port-ID
(R, W, Set-by-create) (mandatory)
Don't care. Recommended to be set to 0

by OLT. Must be ignored by ONU.
T-CONT pointer
T-CONT represents logical link in

EPON.
Direction
No change required.
Traffic management
pointer for upstream
No change required.
512
Rec. ITU-T G.988 (10/2012)
Table C.4.2.1-1 Attributes of GEM port network CTP

Attributes
R/W, M/O
Traffic descriptor profile

pointer for upstream
(R, W, Set-by-create) (optional)
No change required.
UNI counter
(R) (optional)
No change required.
Priority queue pointer for

downstream
No change required.
Encryption state
(R) (optional)
Not used.
Traffic descriptor profile

pointer for downstream
No change required.
Encryption key ring
Not used.
Actions
No change required.
Notifications
End-to-end loss of continuity (optional) is not used in EPON.
C.4.2.2
Clause 9.2.4: GEM interworking termination point
bearer service (usually Ethernet) to the GEM layer takes place. In an EPON system, the GEM port
exists virtually, only for keeping pointer relationships. Interworking option attribute values are
limited because there is no actual interworking function. The value of the GAL profile pointer is
null because there is no GAL profile in EPON. Likewise, the value of GAL loopback configuration
is always 0 (no loopback).
Relationships
No change required.
Attributes
Table C.4.2.2-1 summarizes the attributes of the GEM interworking termination point for
EPON.
Table C.4.2.2-1 Attributes of the GEM interworking termination point
Attributes
R/W, M/O
Managed entity ID
(R, Set-by-create) (mandatory)
No change required.

connectivity pointer
(R, W, Set-by-create)
(mandatory)
No change required.
Interworking option
(mandatory)
0
1
2
3
4
5
6
7
Reserved
MAC bridged LAN
Reserved
Reserved
Reserved
802.1p mapper
Downstream broadcast
Reserved
Rec. ITU-T G.988 (10/2012)
513
Table C.4.2.2-1 Attributes of the GEM interworking termination point

Attributes
R/W, M/O
Service profile pointer
(mandatory)
No change required.
Interworking termination point

pointer
(mandatory)
No change required.
PPTP counter
(R) (optional)
No change required.
Operational state
(R) (optional)
No change required.
GAL profile pointer
(mandatory)
Not used. Set to 0 by OLT,

ignored by ONU.
GAL loopback configuration
(R, W) (mandatory)
Fixed value 0x00 (No loopback)
Actions
No change required.
Notifications
No change required.
514
Rec. ITU-T G.988 (10/2012)
Appendix I
OMCI common services
(This appendix does not form an integral part of this Recommendation.)
This appendix describes the common services of the OMCI.
NOTE Although this appendix describes capabilities that are intended to be common to any technology
that employs the OMCI, some information in this appendix should be modified appropriately when applied
to [ITU-T G.986].
Common services comprise:

a)
ONU MIB management
b)
equipment management
c)
software upgrade
d)
performance monitoring.
These services are explained with the aid of scenario diagrams.
I.1
ONU MIB management
An ONU contains data known as a MIB (management information base) that reflects its hardware
configuration and whatever service provisioning may have been done.
Viewing an access system as a distributed system, it is important that the OLT retain its own view
of the ONU, for example if the ONU needs to be replaced, and that the OLT's view remain
synchronized with the ONU's own MIB.
The results of external events such as DHCP queries or adapting to subscriber interfaces are also
visible via OMCI get commands or AVCs. The OLT is normally also interested in this transient
information, but transient information synchronization is beyond the scope of this clause. In
general, the OLT is expected to use a variety of techniques including AVCs, alarms, including
indications from the TC layer, periodic retrievals, or features such as snooping of protocols
(e.g., IGMP) for this information.
I.1.1
I.1.1.1
MIB discovery
OMCI capability report option
The OLT may discover the ONU's software capability and a summary of its existing provisioning
by querying the two table attributes contained in the optional OMCI ME of clause 9.12.8, and the
contents of the managed entity ME instances.
The OLT may obtain the managed entity types supported by the ONU through the managed entity
type table attribute of the OMCI ME. The OLT may then obtain the message types supported by the
ONU through the message type attribute of the OMCI ME.
The OLT may obtain further details about the ONU's support for a given OMCI ME, as well as a
summary of existing instances of that ME type by reading the managed entity ME for that ME.
Refer to clause 9.12.9.
I.1.1.2
MIB upload
When an ONU initializes, it populates its MIB with information about its equipment configuration
and restores any other inbuilt information. The ONU makes this MIB visible to the OLT. MIB
population should occur before the ONU responds to discovery messages, so that the response to a
Rec. ITU-T G.988 (10/2012)
515
MIB upload request reflects the current configuration of the ONU. This permits the OLT to
discover the hardware and service configuration of the ONU by analysing the uploaded MIB.
I.1.2
I.1.2.1
MIB data sync

MIB data sync attribute
It is essential to the correct operation of the composite access system to keep the MIB synchronized
between the OLT and ONU. The generic tool to achieve this is the MIB data sync attribute of the
ONU data managed entity. The MIB data sync attribute is an 8-bit sequence number. When auditing
the ONU's MIB, the OLT requests this sequence number. If the ONU's sequence number is equal to
the sequence number in the OLT, the OLT may decide that no further action is needed, as the copy
of the MIB in the ONU and the copy in the OLT are likely to be identical. However, the MIB data
sync attribute does not reflect the state of the entire MIB, so it is important to understand its
operation.
I.1.2.2
MIB data sync operation
The MIB data sync attribute is incremented for the creation and deletion of managed entity
instances that are the consequences of commands by the OLT. The MIB data sync counter is also
incremented for changes in attribute values that are the consequences of commands by the OLT
(Figure I.1.2.2-1). The MIB data sync counter is incremented once per executed command, not once
per changed attribute. This includes the modification of the MIB data sync counter attribute itself
via a set command from the OLT. Therefore, a set of the MIB data sync counter to the value N
results in a MIB data sync counter value of N+1 after completion of the set command.
A set action can include several attributes, some of which may result in changes to the ONU's MIB,
and others which may fail. MIB sync is updated if and only if the ONU's MIB changes, that is, if
any of the attributes are modified. This rule is not intended to establish a policy on all-or-nothing
transaction semantics, which is beyond the scope of this Recommendation.
OLT
ONU
Command that changes the ONUs MIB (create, delete, set)

The ONU executes command, updates its
MIB and increments MIB data sync.
Command response (result-reason code)
The OLT updates its MIB and
increments its MIB data sync.
MIBs in the OLT and
ONU are aligned.
G.988(12)_FI.1.2.2-1
Figure I.1.2.2-1 Increment of MIB data sync at the ONU and OLT under OLT command
In contrast, the MIB data sync counter is not incremented for autonomous creation and deletion of
managed entity instances by the ONU itself, nor is the MIB data sync counter incremented for
autonomous changes to attributes of managed entities within the ONU (Figure I.1.2.2-2).
516
Rec. ITU-T G.988 (10/2012)
OLT
ONU
Attribute value changes autonomously.
The ONU updates its MIB.
Attribute value change notification
The OLT updates its MIB. The MIB in

the OLT and ONU are aligned.
G.988(12)_FI.1.2.2-2
Figure I.1.2.2-2 No increment of MIB data sync at the ONU and OLT
If the ONU is offline when the operations system sends a command (create/delete/set), the OLT
updates its MIB locally and increments its MIB data sync, but it cannot send the command to the
ONU. The incremented OLT MIB data sync value guarantees that when the ONU comes online, the
MIB audit will fail. This mechanism also forces audit and reconciliation when an ONU is replaced.
The order in which the OLT and the ONU update their MIBs and increment the MIB data sync
attribute is not specified. Regardless of the order chosen, both the OLT and the ONU must locally
update their MIBs and increment their MIB data syncs as atomic actions. It is considered good
practice for the OLT not to increment its MIB data sync counter until it has received a positive
acknowledgement to the command that it sent to the ONU.
When incremented, the sequence number that follows 255 is 1. Zero is reserved for the following
cases:
1)
default MIB with which the ONU left the factory
2)
an ONU which after initialization cannot restore its MIB.
In other words, a sequence number of 0 indicates that the ONU's MIB is not well defined, or that it
does not contain service provisioning, and therefore requires configuration or reconfiguration.
I.1.2.3
Loss of MIB synchronization
In the process of an OLT modifying the MIB in an ONU, the MIB at the OLT could fall out of
synchronization with the MIB at the ONU. Figure I.1.2.3-1 shows one possible scenario for this.
OLT
ONU
Command that changes the ONUs MIB (create, delete, set)

The ONU executes command, updates its
MIB and increments MIB data sync.
Command response (success)
The OLT fails to update its MIB
and does not increment its
MIB data sync.
MIBs in the OLT and
ONU are not aligned.
G.988(12)_FI.1.2.3-1
Figure I.1.2.3-1 Mismatch of MIBs at the ONU and OLT under OLT command
Figure I.1.2.3-2 illustrates an autonomous change at the ONU, whose AVC is not received by the
OLT. Normally, this information is transient and is not part of the MIB as strictly defined, but it
must be recognized that the OLT no longer has a correct view of the ONU's current state. Periodic
scans of ONU information are therefore encouraged.
Rec. ITU-T G.988 (10/2012)
517
OLT
ONU
An attribute value changes autonomously.
The ONU updates its state.
AVC [lost]
Notification does not reach

the OLT. The OLT does not have a
correct view of ONU state.
G.988(12)_FI.1.2.3-2
Figure I.1.2.3-2 Lost AVC

I.1.3
I.1.3.1
MIB audit and resynchronization

MIB audit
The ONU is audited with respect to its MIB in three cases:

1)
on loss and re-establishment of the OMCC
2)
periodically, based on the operator's requirements
3)
on demand of an operations system.
On detecting a newly installed ONU, regardless of the sequence number of its MIB, the OLT will
directly perform a MIB reset and the new-ONU bring up procedure (clause I.1.4.1). Figure I.1.3.1-1
is the scenario diagram of a MIB audit that uncovers no problems.
OLT
ONU
The OLT requests MIB data sync.

Get (ONU data (MIB data sync))
Get response
The OLT compares retrieved MIB data
sync with its own copy. The values
are the same: the OLT assumes
the MIBs are aligned.
G.988(12)_FI.1.3.1-1
Figure I.1.3.1-1 MIB audit

I.1.3.2
MIB resynchronization
Since the MIB data sync attribute does not reflect the status of the entire MIB, it is considered good
practice for the OLT to periodically perform a MIB resynchronization regardless of the outcome of
a MIB audit. The OLT may repair the MIB incrementally, as illustrated in Figure I.1.3.2-1, or it
may choose to simply reset the MIB and rebuild it from scratch.
518
Rec. ITU-T G.988 (10/2012)
OLT
ONU
The OLT requests MIB data sync.

Get (ONU data (MIB data sync))
Get response
The OLT compares retrieved MIB data sync with
its own copy. The values do not match.
MIB upload
The ONU makes a copy of its MIB and
responds with an indication of the number
of MIB upload next commands required.
Get response
MIB upload next
MIB upload next response
...
The OLT uploads the MIB from the ONU.
MIB upload next

The OLT compares ONUs MIB with its own local
copy and issues commands appropriately to
bring the ONU MIB into alignment with its own.
Create, delete, set commands as needed
G.988(12)_FI.1.3.2-1
Figure I.1.3.2-1 MIB resynchronization

The OLT must issue as many MIB upload next requests as the number of commands given in the
MIB upload response. The maximum time between two MIB upload next requests is one minute. If
the OLT does not send a MIB upload next request within this time after the previous MIB upload
next request or after the MIB upload start request, the ONU assumes the MIB upload to be
terminated. The ONU can drop its copy of the MIB, and consider any further MIB upload next
requests to be invalid.
MIB upload returns all attributes of most MEs, including those that reflect transient information.
MIB upload is therefore a valid way for the OLT to synchronize much transient information, as well
as data of long-term interest. However, certain MEs are excluded from the MIB upload. In
particular, instances of some general purpose MEs, such as the managed entity ME and the attribute
ME, are not included in a MIB upload. Table attributes are never included in a MIB upload. If the
OLT requires this information, it obtains it on a per table basis through the use of the get/get next
mechanism. And finally, the measurement attributes of performance monitoring MEs are not
included in MIB uploads.
As the final step of MIB resynchronization, the OLT sets the MIB data sync attribute of the ONU
data ME to some suitable value of its own choice. It then sets its own record of the same attribute to
the same value, incremented by 1, as explained in clause I.1.2.2.
I.1.4
Bringing up ONUs
ONU bring-up may be separated into two classes: new ONU bring-up and old ONU bring-up. The
definition of new versus old ONU is based on the status of the ONU as viewed by the OLT.
New ONU: The ONU has never completed MIB synchronization with the OLT. For instance:
Rec. ITU-T G.988 (10/2012)
519
1)
2)
The ONU has never been connected to the OLT, and the OLT has never recorded its serial
number. This could arise during initial installation or replacement of an ONU.
The ONU has been connected to the OLT but the OLT did not assign a management layer
ONU-ID to it. This could happen if an ONU is auto-discovered but has not been
provisioned for service.
NOTE A TC layer ONU-ID is a precondition of successful transition into state O5. The TC layer
ONU-ID is not necessarily the same as the management layer ONU-ID, nor is it necessarily stable
from one activation lifetime to another. The management layer ONU-ID is the name by which an
ONU is visible from a service and maintenance point of view, and normally persists for the lifetime
of a service endpoint, even across the possible replacement of physical ONUs.
3)
The ONU has been provisioned but later de-provisioned by an operations system. That is,
its management layer ONU-ID has been de-assigned from the OLT.
Old ONU: The ONU has been connected to the OLT, it has been assigned a management layer
ONU-ID, and has completed MIB synchronization at least once. The OLT has a non-trivial MIB for
this ONU and needs to confirm during bring-up that the ONU's MIB matches its own.
I.1.4.1
Old ONU bring-up
After the ONU powers up and begins execution of a valid software image, it automatically creates a
MIB. Refer to [ITU-T G.984.3] and [ITU-T G.987.3] for a detailed explanation of state transitions
during the activation process. Once the ONU goes into operation state O5, the OLT creates the
OMCC as described in clause B.1.
Once the ONU enters operation state O5 after activation, the OLT creates the OMCC as described
in clause B.1. As described in clause I.1.3.1, the OLT then retrieves the ONU MIB data sync value
by sending a get (ONU data (MIB data sync)) message to the ONU. The OLT compares the
received MIB data sync attribute value to the OLT's own MIB data sync value for that ONU. The
result of the comparison leads to three possible ONU bring-up scenarios:
If the ONU's MIB data sync value matches the OLT's value, and is not zero, the OLT may
assume that their MIBs are in alignment. The ONU bring-up process is complete.
NOTE The OLT ultimately makes the choice between trusting MIB sync match which is not a
guarantee and resynchronizing the MIBs in detail. The OLT also has the choice to reset the MIB
and rebuild it from scratch or to audit and repair it incrementally.
I.1.4.2
If the ONU's MIB data sync value equals zero, possibly the result of an ONU software
upgrade or because the ONU considers its MIB to be invalid, the OLT follows the bring-up
sequence described for a new ONU (clause I.1.4.2).
If the ONU's MIB data sync value does not match the OLT's value, the OLT executes the
MIB synchronization process, as described in clause I.1.3.2. Once the OLT has provisioned
the ONU's MIB, it must align MIB data sync values. The OLT completes the bring-up
process by sending a set (ONU data (MIB data sync)) command.
New ONU bring-up
The bring-up process for a new ONU is shown in Figure I.1.4.2-1. Initially, the OLT sets the ONU
MIB to its default state by sending a MIB reset to the ONU. The ONU re-initializes its MIB to the
default and resets the MIB data sync attribute to zero. Next, the OLT uploads the ONU's MIB to
retrieve all ME instances and capabilities. The OLT then issues create, delete and set commands to
bring the ONU's MIB into sync with the OLT's MIB.
NOTE The details of initialization may differ in other (non-G-PON) access technologies.
When an ONU changes an attribute value autonomously, it sends an attribute value change message
(AVC) to the OLT. The ONU can send AVCs during the MIB synchronization or MIB download
processes. AVCs should be viewed as a partial method of ONU state discovery. Not all managed
520
Rec. ITU-T G.988 (10/2012)
entities or attributes issue AVCs, and an AVC message can be lost in transmission without an error
being detected. Therefore, the OLT should audit the ONU state immediately after a reset has been
completed.
OLT
New ONU
Power up, select local software
image, and create MIB
Upstream_overhead PLOAM
...
Activation
Ranging_time PLOAM
Configure port_ID PLOAM
...
OMCC
setup
Acknowledge PLOAM
MIB reset
Clear MIB, re-initialize to default
MIB reset response
An attribute value changes
autonomously, ONU updates MIB
MIB reset

Notification reaches OLT;
OLT updates its MIB
MIB upload, MIB upload next
...
Save retrieved ONU data
Command [create, delete, set]
Execute command, update
MIB and MIB data sync
Command response
Increment MIB data sync
MIB
provisioning
An attribute value changes

autonomously, ONU updates MIB

Notification reaches OLT;
OLT updates its MIB
Set (ONU data (MIB data syncN))
ONU sets its MIB data sync to
value N, then increments to N+1
Set response
OLT sets its MIB data
sync to value N+1
G.988(12)_FI.1.4.2-1
Figure I.1.4.2-1 New ONU bring-up
Rec. ITU-T G.988 (10/2012)
521
I.2
I.2.1
Slot-port model
ONU equipment management is modelled on a three-level hierarchy: the chassis (the ONU itself),
cardholders (also known as slots), which may contain circuit packs of varying types over the course
of time, and ports, which present external interfaces either to the subscriber, to the PON or to a local
management tool. Many OMCI managed entities are addressed in accordance with the slot-port
model. Ports the physical path termination point group of MEs would be expected to follow this
model, but the T-CONT, MAC bridge service profile and traffic scheduler are also modelled by
slot, if not by port.
All ONUs must therefore adhere to at least a minimal slot-port model. An integrated ONU is
represented as a virtual chassis containing virtual cardholders. There are three ways in which this
may be done.
1)
Several virtual cardholders may be defined, one for each interface type. This was the
original model and is the most common. The more significant byte of the ME ID of a
virtual cardholder has the value 1; a real cardholder has the value 0. In both cases, the slot
number (actual or virtual) is the value of the less significant byte.
2)
A single virtual cardholder may be defined as slot 0 (LS byte), and all interfaces may be
represented through the port mapping package ME, which maps ports of arbitrary types in
arbitrary combinations. The port mapping package has the merit that it is universally
applicable to integrated and chassis-based ONUs equipped with any type of real or virtual
circuit pack, but for historical reasons, it is commonly used only when it is the only choice:
a chassis-based ONU that contains circuit packs with mixed port types.
3)
The port mapping package may be contained by the ONU directly, rather than by a virtual
cardholder. This approach has the merit that it avoids a virtual cardholder that serves no
real purpose, and the disadvantage that it applies only to integrated ONUs. It is unlikely to
appear in actual practice.
In the original model, real or virtual slot numbering was segregated by PON-side (128 up) vs
subscriber-side (127 down). Although this constraint is no longer specified it was unsatisfactory
for real chassis with real slots, as well as mixed-function circuit packs some virtual-slot
implementations continue to follow this convention for historical reasons.
In addition, the two most significant bits of the slot address are available to designate xDSL bearer
channels when desired. While this violates orthogonality, it poses fewer problems in practice than in
theory, since a space of 64 slots more than suffices for real or virtual cardholders. Best practice
would indicate that slot numbers be unique within their 6 LSBs, particularly if there is any
possibility that xDSL bearer channels may need to be modelled.
As to port addressing, the original model specified ports numbered in increasing order, left to right,
bottom to top, but this was inappropriate both for three-dimensional ONU packages with mixed
ports of all types on several surfaces or edges and for chassis-based ONUs with service connections
through the backplane rather than on circuit pack faceplates. Today, port addresses are expected
only to start with 1 and to be unique. Small numbers in a contiguous sequence are preferred.
Finally, it is worth mentioning that nothing actually prohibits mixing port types on any card type,
without benefit of the port mapping package. The combined video UNI and PON type (code
point 44) even explicitly allows for differing port types. No convention exists for the numbering of
such ports, configuration discovery is likely to be a problem, and best practice would avoid this
option.
522
Rec. ITU-T G.988 (10/2012)
I.2.2
The chassis-based ONU
The original slot-port model was, and is, arguably adequate for integrated ONUs, where it is easy to
create as many virtual cardholders as may be desirable. For chassis-based ONUs however, a number
of difficulties arise:
The model does not readily accommodate the richness of possible service interfaces.
Table 9.1.5-1 defines circuit pack types, with an eye to listing all possibilities, but it does
not scale well. As an example, the long list of VF specials is not presently represented. See
the next two bullet points as well.
The model does not adequately represent common equipment, circuit packs with no
external ports at all, for example, power supply packs. This Recommendation includes a
single code point for common equipment; it does not distinguish different types of common
equipment.
It has no way to flexibly model equipment with a combination of interfaces, for example, a
single circuit pack with a PON interface, a craft port and an RF video port (code point 44
includes PON and RF video, but not craft). Code point 45 is defined for multi-function
packs; it does not distinguish different types of multi-function packs. As mentioned above,
port numbering conventions are undefined, except by way of the port mapping package.
There were ambiguities in the original plug-in unit type definitions of [ITU-T G.984.4],
specifically between the possible mixes of 10/100/1000 Mbit/s Ethernet and its physical
media. The ambiguity was resolved with a compromise, but existing implementations must
be regarded with caution.
The original model could not distinguish between two Ethernet packs, for example, with
four ports on one and eight on the other. Port count attributes were added as a patch, but
they do not address the reality that both operators and vendors are likely to manage real
equipment inventory by a code (CLEI, for example, or vendor product name/number),
rather than simply by generic type.
The integrated ONU was first to be developed, so the issues mentioned above were not immediately
apparent. Various extensions have been added to the equipment model to address these concerns, as
discussed below.
While the generic circuit pack types of Table 9.1.5-1 arguably suffice for the integrated ONU, it is
recommended that the chassis-based ONU use the equipment ID attributes as its primary means to
identify equipment options. Equipment ID is also the preferred way to identify an integrated ONU
for inventory purposes.
In Table 9.1.5-1, a small range of equipment types is reserved for vendor-specific assignment.
Vendor-specific code points would seem to introduce interoperability issues, but they are in
principle no worse than equipment ID as an identifier: the OLT and EMS must have a priori
knowledge of the meaning and characteristics of whatever identifiers are used, presumably through
business agreements and information exchange between the vendors concerned.
I.2.3
I.2.3.1
Dynamic behaviour
ONU initialization: the ONU's view
When an ONU initializes, it populates its MIB with information about its equipment configuration.
The Recommendations are written as if the ONU discovers this information for itself when it comes
to life. This may be the case, but it is also possible that an ONU, especially an integrated ONU, may
be equipped with a basic MIB at the factory, in which case initialization may comprise merely
copying the MIB into a working store and discovering only options that may have changed after the
last shutdown and prior to the current initialization.
Rec. ITU-T G.988 (10/2012)
523
If it exists, the non-volatile MIB image used as the initialization reference for a chassis-based ONU
may be populated with circuit pack types or equipment IDs, either by factory predetermination or
from prior operation of the ONU. This equipment may or may not be present during the current
initialization. Whether there is a non-volatile MIB or not, the ONU must actually perform some
level of self-discovery to determine what, if anything, exists in its cardholders.
The ONU is specified to issue AVCs or alarms when it discovers circuit packs, or when it discovers
that a circuit pack that was recorded in its non-volatile MIB (if there is one) is no longer present or
no longer has the same type or equipment ID. However, ONU initialization is recommended to
occur before the ONU is activated on the PON, so transmission of AVCs and alarms is not possible.
Queueing of notifications for future delivery is not specified, so the OLT must audit the connected
equipment when the ONU re-ranges.
If there are mismatches between an ONU's actual equipped configuration and its (possible) nonvolatile MIB, the ONU should declare alarms as appropriate and should not attempt to bring the
mismatched circuit packs into service.
I.2.3.2
ONU initialization: the OLT view
When the OLT activates an ONU, the OLT either has a MIB that corresponds to that ONU or it
does not.
If the OLT does not have a MIB for that particular ONU already, it uploads the ONU's MIB as a
starting point. Subsequent operation and provisioning is recorded both in the ONU's MIB and in the
OLT's functional duplicate. AVCs from the ONU alert the OLT to changes that could occur from
external causes such as craft removal or the installation of circuit packs. An AVC triggers the OLT
to update its view of the ONU. The details of such an update are beyond the scope of this
Recommendation.
When it activates the ONU, the OLT may already have a MIB (or database functional equivalent)
for a particular ONU, either because the ONU has been pre-provisioned or because the ONU has
previously been active on the PON. The initialization requirements are the same in either case.
Assuming that the OLT has a MIB for this particular ONU, an audit is necessary once activation
is complete as part of service (re-)activation. The ONU is responsible for knowing its current
equipment configuration, which must be reconciled by the OLT. The OLT, on the other hand, is
responsible for knowing all provisioned information, and to ensure that, once initialization is
complete, the ONU is provisioned accordingly. The OLT should declare alarms or events towards
an EMS if the configuration has changed unexpectedly or provisioning reconciliation fails.
I.2.3.3
Circuit pack provisioning
The previous clause discusses ONU initialization. This clause discusses the dynamics of circuit
pack provisioning, installation and removal for an ONU that is active on the PON. It assumes a
chassis-based ONU: changes to (virtual) circuit packs should not occur on integrated ONUs. An
integrated ONU should deny attempts to provision cardholder and circuit pack attributes that are in
fact immutable, even if their OMCI definitions indicate that they have write or set-by-create
semantics.
The ONU is sensitive to four events in this context, each of which has a number of use cases. Each
event is discussed in its own clause below.
1)
A circuit pack is provisioned into a cardholder.
2)
A cardholder is de-provisioned.
3)
A circuit pack is physically inserted into a cardholder.
4)
A circuit pack is physically extracted from a cardholder.
524
Rec. ITU-T G.988 (10/2012)
I.2.3.3.1 Circuit pack provisioned into a cardholder

This event comprises the change of any of the writeable attributes of the cardholder, except setting
the expected plug-in unit type to 0, which is covered under the de-provisioning clause below. If the
expected plug-in unit type is 0, all of the other attributes of the cardholder may be freely altered
without generating a provisioning event or affecting the ONU's state or its alarms. That is, the
ONU's expectation of the presence or absence of a circuit pack is based entirely on the non-zero
value of the expected plug-in unit type attribute.
If the cardholder is empty at the time of provisioning, the ONU can, and should, confirm that all
attributes are consistent within the scope of its knowledge. That is, if either or both the expected
port count and expected equipment ID are also provisioned, either in the same set command or
separately, the combination of attributes must be consistent with the expected plug-in unit type. An
Ethernet pack CLEI, for example, should be denied in the expected equipment ID attribute if the
expected plug-in unit type is xDSL. Likewise, if the only Ethernet packs supported by the ONU
have four ports, the ONU should deny an attempt to pre-provision an Ethernet slot with eight ports.
Expected plug-in unit type code-point 255 (plug-and-play) is a "don't care" case in terms of
consistency checking, but the remaining attributes must still be mutually consistent and known to
the ONU.
Assuming the provisioning event succeeds, the cardholder immediately declares the plug-in LIM
missing alarm. If a standing alarm is undesirable, the alarm may be suppressed with an ARC. The
ONU should then instantiate a circuit pack ME, though it may be only an empty husk if insufficient
information is provided (plug-and-play case).
It is possible that the provisioning command does not unambiguously define the equipment. For
example, an ONU may support both a four-port and an eight-port Ethernet pack. If pre-provisioning
merely calls out an Ethernet pack in such an example, best practice suggests that the ONU create an
empty husk circuit pack ME. It is also acceptable for the ONU to deny the provisioning command,
but creating four ports now and possibly four more ports later is discouraged.
Given enough information about type, port count and equipment ID, the ONU now creates a fully
populated circuit pack ME, along with a suitable number of physical path termination point or
ANI-G MEs, and any other MEs known to be appropriate to the configuration, for example, a port
mapping package ME, an equipment extension package or a protection data ME, software images,
traffic shapers, T-CONTs, etc. From this enhanced MIB, the ONU is prepared to accept preprovisioning of services. Service pre-provisioning should be denied if an empty husk circuit pack
ME was created.
If the cardholder is occupied at the time of provisioning, the provisioning action may either
create a mismatch with the existing circuit pack or resolve a mismatch.
Provisioning creates a mismatch if it sets the expected plug-in unit type to any value other than 0, to
255 (plug-and-play) or to the actual type. Provisioning creates a mismatch if it sets the expected
equipment ID to any value other than all spaces, or to the actual equipment ID. Provisioning creates
a mismatch if it sets the expected port count to any value other than 0 or to the actual port count.
The ONU declares an alarm for a type or equipment ID mismatch. No alarm is defined for expected
port count mismatch; rather the ONU should deny a provisioning command that attempts to create
such a mismatch. The ONU should take no additional action upon mismatch creation. For example,
if service is in fact running on existing hardware, it should be left in place. (But service would not
be restored to a mismatch after ONU initialization because the ONU would have no independent
record of the prior configuration.)
If the cardholder was in mismatch before the provisioning action, the mismatch is resolved if all of
the following are true:
The expected plug-in unit type is provisioned to the actual plug-in unit type. If the ONU
supports plug-and-play, code point 255 also resolves a mismatch.
Rec. ITU-T G.988 (10/2012)
525
The expected port count is provisioned either to 0 or to the actual port count.
The expected equipment ID is provisioned either to the actual equipment ID or to a string
of all spaces.
The ONU should clear any alarms that may have been declared as a consequence of the mismatch
state. It should also initialize (or complete the initialization of) the physical circuit pack, up to and
including bringing up any services that may be provisioned onto it.
I.2.3.3.2 Cardholder de-provisioned
This event occurs when the cardholder's expected type is set to 0. If it was already 0, this is a no-op.
The ONU should delete all associated managed entities (see the list and examples above), and clear
any alarms associated with the equipment. It is an error for the OLT to de-provision equipment
without first de-provisioning all services that depend on the equipment, and while ONU robustness
is encouraged, the ONU's behaviour is undefined, up to and including the possibility that orphan or
conflicting MEs may be left behind in the MIB, and nothing less than a MIB reset can recover.
If the cardholder is populated with a circuit pack at the time of de-provisioning, the ONU
should place it in an inactive holding pattern, awaiting extraction or re-provisioning. The holding
pattern state implies no user services; provisioning and test commands should be denied, alarms
should be cleared and no new ones generated, and ports and preferably the entire circuit pack
should be powered down. ONU initialization from this state should initiate the sequence that occurs
when a circuit pack is inserted into an unprovisioned slot.
I.2.3.3.3 Circuit pack physically inserted into a cardholder
The two cases to consider in this event are distinguished by whether the circuit pack managed entity
already exists or not. The common cases are the installation of new packs and the replacement of
defective packs. In the normal course of events, a circuit pack ME exists before either of these
events.
If the cardholder is provisioned with an expected plug-in unit type, then a circuit pack ME
exists, either of the specified type or of type 255, signifying unknown. When the actual circuit pack
appears, the ONU updates the circuit pack ME with actual values from the equipment. If the
appearance of the circuit pack resolves ambiguous provisioning, for example, as a plug-and-play
circuit pack, this is the point at which the ONU creates the subordinate MEs mentioned above:
PPTPs, software images, etc.
NOTE 1 The OMCI does not define AVCs for changes to normally immutable attributes that may in fact
change during this process. The OLT should use the AVC on the cardholder actual type and actual
equipment ID to trigger a query of all cardholder and circuit pack attributes.
The appearance of a circuit pack either triggers a mismatch, in accordance with the mismatch
discussion above, or it does not. If there is no mismatch, the ONU continues initialization and
bring-up of the circuit pack and services. If there is a mismatch, the ONU declares a mismatch
alarm through the cardholder ME. No alarm is defined for a mismatch of port count.
Most, if not all, physical path termination points (ports) include an optional operational state ME.
Among other circumstances, this attribute should have the value disabled when the pack is not
present. Operational state should change to enabled, and be reported via an AVC, when the port
successfully enters service. Within the scope of a current OMCI, the failure to receive an AVC on
the port is the only notification the OLT has of port mismatch.
If the circuit pack ME does not already exist, the ONU should instantiate it upon pack insertion.
The ONU should populate the attributes of the circuit pack from the equipment itself, and report
them to the OLT via AVCs from the cardholder.
526
Rec. ITU-T G.988 (10/2012)
NOTE 2 The OMCI does not define AVCs for changes to all attributes that may change during this
process. The OLT should use the AVC on the cardholder actual type and actual equipment ID to trigger a
query of all cardholder and circuit pack attributes.
The ONU should instantiate the complete set of PPTP/ANI MEs, port mapping packages, etc., as
described above. If the pack and ports pass self-test, each should report an AVC when its
operational state becomes enabled.
The absence of the circuit pack ME a priori guarantees that no additional pre-provisioned
information exists in the MIB, except possibly in the de-provisioned corner case discussed above, in
which the ONU's behaviour is undefined.
I.2.3.3.4 Circuit pack physically extracted from a cardholder
The most common cause of this event is the replacement of a defective circuit pack. When the old
circuit pack is extracted, the event may trigger additional alarms the circuit pack and some or all
of the services are likely already in alarm such as cardholder improper removal. No managed
entities are deleted as the consequence of this event; MEs are only destroyed through deprovisioning.
Replacing the defective pack with a like pack follows the normal sequence of events: the pack is
initialized, no MIB changes are necessary, and services are restored. Replacing the pack with an
incompatible pack triggers mismatch behaviour as described in the previous clause. Replacing the
pack with a functionally similar pack (e.g., different CLEI, same capabilities) may or may not be
accepted by the ONU, depending on its built-in knowledge of equipment compatibilities.
Less common is the removal of a circuit pack, either to leave the slot unpopulated or to reuse it for
other purposes. It is recommended that services first be de-provisioned and then the cardholder be
de-provisioned before the circuit pack is extracted, but if the pack is extracted first, it is treated
exactly as if it were simply being replaced with another pack of the same type.
I.2.3.4
MIB sanity
Regardless of the flows described above, it is always allowed and encouraged for an ONU to deny
provisioning actions that create MIB inconsistencies.
I.2.4
Protection
Two kinds of protection can be supported within the OMCI model, ANI (PON) protection and
equipment protection. Vendor-interoperable protection has not been widely deployed as yet; in the
absence of real-world experience, some aspects of its operation doubtless remain for further study.
The model for PON protection assumes two ANI MEs, which would presumably reside on separate
circuit packs. The protection data ME coordinates the two ANIs and specifies various attributes of
the protection group. PON protection handshaking is based on SDH K bytes. If more than LOSbased single-ended protection were to be supported, further work would likely be needed to
rationalize the details of K-byte protection with G-PON.
The model for equipment protection is exemplified by a chassis-based ONU with DS1 circuit packs,
in which one or two circuit packs protect up to eight working packs. Protection of this nature is
likely to be built into the backplane or cabling of the ONU; protection packs may or may not be the
same as the working packs. This function is supported by the equipment protection profile ME.
Equipment protection can be manually invoked through an attribute of the working cardholder ME.
Subscriber facility protection, for example 1+1 protection of 155 Mbit/s drops, is not presently
supported by the OMCI.
Rec. ITU-T G.988 (10/2012)
527
I.2.5
Environmental inputs and outputs
The OMCI provides an equipment extension package that may be associated either with an ONU or
a cardholder to provide external sense or control points. The conceptual model is of equipment able
to detect external contact closures, and report either a closed or an open contact as an off-normal
event. Rectifier plant alarms may be reported with this mechanism, for example. The semantics of
these alarms are undefined to the OMCI and the ONU, and must be interpreted at the OLT or EMS
level.
Where the ONU structure is hard-wired for particular alarms that are already defined in the OMCI,
the hard-wired alarms should be reported in preference to the general-purpose capabilities of the
equipment extension package. For example, a physical intrusion alarm can be declared by the
ONU-G, and is preferred, as long as no ONU provisioning is needed to associate the alarm with a
specific input point. Likewise, existing battery alarms, declared by the ONU-G ME, are preferred
where they convey the correct semantics and require no provisioning.
The equipment extension package managed entity also allows for external control points to be
activated or released.
I.2.6
Managed entity analysis
This clause discusses managed entities and attributes of interest. It is not a complete list of all
concerned MEs or their characteristics; it represents those for which commentary is appropriate.
I.2.6.1
ONU-G, ONU2-G
These MEs define attributes, actions and notifications that conceptually pertain to the ONU as a
whole equipment unit. When the ONU is implemented as integrated equipment, no issues arise.
This clause describes the common attributes, actions and notifications for the chassis-based ONU.
Attributes
Vendor id, version, serial number, vendor product code (RO) These attributes may not exist for
the chassis, per se. Their values may be taken from a controller pack, and may require
re-provisioning or re-learning if a controller pack is replaced.
Traffic management option (RO) Report the value from the pack that implements traffic
management. In most cases, this would be the controller pack.
Battery backup (RW) The integrated ONU should proxy this value on behalf of the pack that
implements battery monitoring unless explicit provisioning is required, in which case the external
sense points of the equipment extension ME should be used instead. If the ONU/ONU has no
capability to monitor battery-related states, it should deny an attempt to enable battery monitoring.
Admin state (RW) Administrative lock at the ONU level should disable all subscriber services on
all ports of all circuit packs, and suppress all alarms, as well as powering down as much as possible,
consistent with continued craft and PON access.
Operational state (RO) Operational state indicates whether the ONU in its entirety is capable of
performing some (vs none) of its functions. In accordance with the state model of [ITU-T X.731],
the ONU should report its operational state as disabled only if all of its ports are out of service for
autonomous reasons (for example, failure or circuit pack extraction). At the ONU level, this
information is not very useful because operational state is an optional attribute, it may be omitted.
Equipment ID (RO) The equipment ID string is 20 characters, typically long enough for two
informative fields. It is recommended that the primary information field be left justified in the
equipment ID attribute, for example, CLEI code in markets that use this identifier. If a second
identifier (for example, vendor product designator) is desired, it is recommended that it be rightjustified in the equipment ID attribute, with spaces padding the gap in the centre. Although this
information may be provided by the controller pack rather than the backplane, it is quite likely to
528
Rec. ITU-T G.988 (10/2012)
differ from the corresponding equipment ID attribute of the controller circuit pack, since it
represents the ONU, rather than the circuit pack.
OMCC version (RO) This attribute indicates the OMCI version supported by the ONU as an
entirety, and should be reported as the most primitive version, considering all software residing on
all circuit packs.
NOTE For historical reasons, an implementation may report 0x80, even though it actually supports a more
recent version of the OMCI.
Total priority queue number, total traffic scheduler number (RO) These attributes are defined to be
the count of queues (schedulers) not associated with a specific circuit pack. The chassis-based ONU
should report these on behalf of the controller (or traffic management) circuit pack, if a specific
pack provides these functions. It is also acceptable to report these values as 0, and to report values
for individual packs instead.
Total GEM port-ID number (RO) This attribute should be reported for the ONU as an entirety on
behalf of the ANI or traffic management circuit pack, typically the (primary) controller.
Actions
Reboot This action should cause the ONU as an entirety to re-boot. It would be expected that the
controller pack (or both controller packs) would re-boot, and any other circuit packs would be rebooted or re-initialized as applicable. Re-boot is not expected to be hitless to subscriber services.
POTS calls are allowed to be dropped, and layers 2, 3 and 4 data associations are allowed to be lost.
Test The test action on a chassis-based ONU may not be meaningful. In the case that the test
action is not meaningful, it is the vendor's choice whether to reject an ONU-directed test action, or
whether to proxy the action to the (primary) controller pack.
Synchronize time This action should resynchronize all circuit packs that maintain PM-related
interval timers and counters.
Notifications AVCs
Op state As noted above, the operational state attribute is optional, and conveys little information
at best. When the ONU is really incapable of performing any of its functions, it is likely also
incapable of conveying a state indication over the PON.
Notifications alarms
Equipment alarm, ONU self-test fail This alarm would be expected to be declared against an
individual circuit pack, rather than against a chassis-based ONU as an entirety. If one of these
alarms is declared by a chassis-based ONU, the alarm should really indicate a chassis-wide
problem, not a circuit pack problem.
Powering alarm, battery missing, battery failure, battery low, physical intrusion, voltage yellow,
voltage red These alarms are meaningfully declared by the ONU as an entity in its own right.
Dying gasp The purpose of this alarm is to help the OLT distinguish, when possible, between
fibre cuts and equipment faults. Dying gasp should therefore be declared by the ONU on behalf of
the circuit pack that supports the ANI. That is, other parts of the ONU may remain up and running;
the alarm indicates only the state of the PON optics, or of the ONU as an entirety. If the ONU has
redundant PON interface circuit packs, dying gasp should not be declared to indicate failure, loss of
power or imminent shutdown of one controller. In that sense, the alarm is really declared by the
PON circuit pack, but using the ONU-G as a reporting entity. Dying gasp is not an irrevocable
commitment to drop off the PON: the OLT should accept the possibility that the ONU remains
active on the PON and clears the alarm after a last-second recovery.
Temperature yellow, temperature red While it is possible that a chassis could contain global
temperature sensors, it is expected that, in the case of a chassis-based ONU, temperature alarms
Rec. ITU-T G.988 (10/2012)
529
would be declared by individual circuit packs instead. In any event, the alarms should be declared
by the ME that best represents the scope of the problem.
ONU manual power off This alarm is similar to dying gasp, inasmuch as it signals the likelihood
that the ONU will drop off the PON, but it conveys the additional information that the shutdown is
due to subscriber action.
I.2.6.2
Cardholder
The cardholder ME is needed even by integrated ONUs because it contains information pertinent to
the virtual slot model.
Attributes
Actual plug-in unit type (RO) This attribute takes a value from Table 9.1.5-1. Choices from the
table are expected to suffice for the integrated ONU, and the equipment ID attributes are not
expected to be used.
Expected plug-in unit type (RW) This attribute permits some level of pre-provisioning. Although
the equipment ID is preferred to indicate a precise circuit pack type, this attribute should be selected
from Table 9.1.5-1 to be as meaningful as possible. Even though this attribute is marked read-write,
the integrated ONU should deny attempts to change its value.
Expected port count (RW) This attribute permits pre-provisioning of generic circuit pack types
when the equipment ID is not specified. Since equipment ID is preferred, this attribute should not
be used. If it is used, it must be set to a value that does not conflict with other attributes, such as
equipment ID, that may exist already or that may be part of the same set operation. As with the
expected plug-in type, which is also read-write, an integrated ONU should deny an attempt to
change the value of this attribute.
Expected equipment ID (RW) The OMCI definition states that this attribute pertains only to real
(not virtual) cardholders. An integrated ONU should deny an attempt to write its value. As noted
earlier, vendors may choose to encode two informative fields into this attribute, for example, a
CLEI and a vendor product code name. No substring matching behaviour is expected: the
provisioned value of this attribute must match exactly the value found in the equipment itself.
Actual equipment ID (RO) The OMCI definition states that this attribute pertains only to real (not
virtual) cardholders.
ARC and ARC interval (RW) These attributes permit alarms to be suppressed on cardholders. The
specific application is automatic in-service provisioning, whereby no alarms are declared on
pre-provisioned empty slots, but upon insertion of the circuit packs, alarm behaviour goes to normal
without further intervention from an operations system.
Notifications AVCs
Actual type, actual equipment ID These AVCs are not meaningful for integrated ONUs.
Plug-in circuit pack missing, plug-in type mismatch, improper card removal, plug-in equipment ID
mismatch, protection switch These alarms are not meaningful for integrated ONUs.
I.2.6.3
Circuit pack
Virtual circuit packs exist for an integrated ONU. The type and number of port attributes are
meaningful from an equipment management point of view.
Attributes
Type (RWSC) This attribute takes a value from Table 9.1.5-1. While the attribute value should
align as closely as possible with an appropriate equipment type (Table 9.1.5-1), a chassis-based
530
Rec. ITU-T G.988 (10/2012)
ONU should rely on the equipment ID attribute to convey precise information about circuit pack
type.
Number of ports (RO) Because a circuit pack can have only one type, all of its ports must be the
same, and this attribute is just a scalar port count. More complex configurations are managed either
by defining additional virtual cardholders and virtual circuit packs (integrated ONU) or with the
port mapping package managed entity.
Serial number, version, vendor id, equipment ID (RO) These attributes are reported from the
circuit pack hardware. For the (primary) controller pack, they would have the same value as
reported in the ONU-G ME pair.
Administrative state (RWSC) When this attribute has the value locked, all subscriber (and craft)
services depending on this circuit pack are blocked. It may not be meaningful to lock circuit packs
without subscriber (or craft) interfaces, or circuit packs with mixed interfaces such as ANI, LCT
and video UNI; the behaviour in such a case depends on the vendor. It would be reasonable for the
ONU to deny the lock operation, or for the operation to have no effect. It is desirable to power
down as much circuitry as possible, and to minimize power consumption by establishing locked as
the default state.
Operational state (RO) This attribute has the value disabled if none of the circuit pack's functions
is operational for autonomous reasons.
Power shed override (RW) This attribute permits ports to be declared essential and thereby to be
excluded from power shedding timeout. It assumes a simple scalar numbering of ports, not to
exceed 32.
Actions
Reboot This action is intended to permit an individual (real) circuit pack to be re-booted. If the
circuit pack is the (primary) controller, however, it may have the same effect as an ONU reboot
action.
Powering alarm This alarm is intended to indicate a more specific failure of the equipment. The
failed equipment could be either a power supply circuit pack or a client circuit pack with a failed
input fuse or converter. Battery and AC alarms are declared at the ONU level if they are hard-wired.
I.2.7
Power shedding
Power shedding is the ability of an ONU to reduce power consumption during AC power outages. It
is predicated on the assumption that the ONU is attached to a power source that contains a battery
back-up and the ability to notify the ONU of AC power loss and restoration. When the ONU is
notified by the power source that AC power has been lost, the ONU may reduce power
consumption by shutting down selected ONU interfaces. For the purposes of provisioning, these
interfaces are divided into classes that may be individually provisioned to shed power after AC
power loss is reported to the ONU.
Provisioning of ONU power shedding is accomplished through the use of two OMCI MEs. These
are the ONU power shedding ME and the circuit pack ME. The ONU power shedding ME contains
most of the attributes associated with power shedding. The circuit pack ME contains a single
attribute, power shed override, that allows for the override of power shedding on a per port basis.
The power shedding ME is auto-created by an ONU if that ONU supports power shedding.
The power shed override attribute within the circuit pack ME is a bit map that can be used on a per
port basis to override the settings contained in the ONU power shedding ME. This attribute is
defined as a 4-byte bit map with port 1 as MSB. When a bit in this attribute is set to 1, the
corresponding port in its circuit pack is exempt from the ONU power shedding ME.
Rec. ITU-T G.988 (10/2012)
531
If the hardware associated with the circuit pack does not support individually powering off its ports,
then the entire attribute is taken as a single composite value. In this case, any bit of value 1 exempts
all ports on that circuit pack from the ONU power shedding ME. Intermediate cases are also
possible, for example, where the hardware permits ports to be powered down in groups of four. The
point is to retain power on ports designated as essential, while powering down all other ports within
the capabilities of the hardware.
Of particular interest in the management of ONU power shedding is the expected behaviour of the
ONU during various power shedding scenarios. This is especially true for the relationship between
the two timers represented by the attributes restore power reset interval (Tr) and shedding interval
(Ts). This behaviour is depicted in Figure I.2.7-1. The following terms are used in the diagram:
Start timer The timer is started or resumed from its existing value. A start timer action
does not imply a reset of the timer.
Stop timer The specified timer is stopped and not reset.
Reset timer Stops and resets a timer. The timer is not started.
AC on
Reset timer Ts
AC off
Start timer Ts
AC on
Stop timer Ts
Start timer Tr
PreShed timing
Timer Ts expires
Timer Tr expires
PostShed timing
Stop timer Tr
Start timer Ts
AC off
Start timer Tr
Reset timer Tr
Shed power
Power Shed
AC on
G.988(12)_FI.2.7-1
Figure I.2.7-1 Power shedding state diagram

I.2.8
Remote debug
The remote debug managed entity (clause 9.1.12) is used for free-form information exchange with
an ONU for the purpose of debugging an ONU from an OLT. This may be appropriate due to the
lack of other debug access (primarily due to security concerns of the operator) or because the ONU
is located remotely. It is not the purpose of remote debug access to offer management abilities that
should be done using conventional OMCI or other vendor-specific managed entities.
The remote debug entity has the ability to send 25 bytes of information to an ONU and collect up to
0xFFFFFFFE bytes of response. The information exchange may be ASCII coded or in vendorspecific binary format.
532
Rec. ITU-T G.988 (10/2012)
It is assumed that the majority of the OLTs and ONUs would implement the ASCII format,
whereby OLTs could inject basic ASCII commands to an ONU and receive ASCII formatted
reports in reply. The raw binary data format offers the ability to collect information in a
single-vendor environment for advanced debugging purposes.
The managed entity ID of this object is always zero. Since the object is created by the ONU, no
other managed entity ids are possible. The remote debug capability of an ONU can be detected by a
get operation on the remote debug managed entity, with an error response if the object does not
exist.
Command syntax (in either mode) is vendor-specific, as is the reply information. However, some
general guidelines for the ASCII mode are suggested as best practice. The ASCII command help
should be supported by the ONU, such that the ONU would then reply back with the available
commands that may be supported by the remote debug process. In addition, if a command is not
recognized or cannot be parsed by the ONU, a reply to that nature should be returned in the
specified format. The use of OMCI error codes to indicate an error in the ASCII command (not the
OMCI command) is not advised.
Figure I.2.8-1 illustrates a potential remote debug exchange. In this example, the OLT sends an
ASCII text string command dump status to the ONU, and the ONU replies.
OLT
ONU
Get (ONU remote debug (command format))
Get response (command format = ASCII)
Set (ONU remote debug (command = "dump status "))
Set response
Get (ONU remote debug (reply table))
Get response (reply table size)
Get next (ONU remote debug (reply table, sequence))
Get next response
...
G.988(12)_FI.2.8-1
Figure I.2.8-1 Success example

I.3
Software upgrade
I.3.1
Overview
The software image managed entity is defined in clause 9.1.4. For each ME that contains
independently manageable software (either the ONU or a circuit pack), the ONU creates two
software images, 0 and 1. Each image has three Boolean attributes: committed, active and valid. An
image is valid if the contents have been verified to be an executable code image. An image is
committed if it will be loaded and executed upon reboot of the ONU or circuit pack. An image is
active if it is currently loaded and executing in the ONU or circuit pack. At any given time, at most
one image may be active and at most one image may be committed.
An ONU goes through a series of states to download and activate a software image as shown in
Figure I.3.1-1. Each state is determined by the status of both software images. For example, S3 is
the state where both images are valid but only image 0 is committed and active. State S0 is a
conceptual initialization state.
The OLT controls the state of the ONU through a series of commands defined in clause 9.1.4. For
example, an ONU in state S3 will traverse to state S4 upon receipt of the activate(1) command. The
Rec. ITU-T G.988 (10/2012)
533
defined commands are start download, download section, end download, activate image and
commit image.
State S1
SW image 0
is active: yes
is committed: yes
is valid: yes
version: xxxx
State S1'
SW image 1
is active: no
is committed: no
is valid: no
version: null
Start
download (1)
Reboot
Activate (0)
Commit (0)
Reboot
Activate (1)
Commit (1)
Successful completion
of initial (proprietary)
bootstrap of SW image 0
Successful completion
of initial (proprietary)
bootstrap of SW image 1
SW image 0
is active: no
is committed: no
is valid: no
version: null
SW image 1
is active: yes
is committed: yes
is valid: yes
version: yyyy
Start
download (0)
State S0 (OMCC not operational)
Reboot
End download (1),
incorrect CRC
State S2
SW image 0
is active: yes
is committed: yes
is valid: yes
version: xxxx
Reboot
Activate (0)
Commit (0)
Start download (1)
Download section (1)
SW image 1
is active: no
is committed: no
is valid: no
version: null
End
download (1),
correct CRC
Reboot
End download (0),
incorrect CRC
State S2'
Reboot
Activate (1)
Commit (1)
Start download (0)
Download section (0)
SW image 0
is active: no
is committed: no
is valid: no
version: null
Start
download (0)
Start download (1)
SW image 1
is active: no
is committed: no
is valid: yes
version: yyyy
Reboot
Activate (0)
Commit (0)
Reboot
Activate (1)
Commit (1)
SW image 0
is active: no
is committed: no
is valid: yes
version: xxxx
Activate (1)
SW image 1
is active: yes
is committed: yes
is valid: yes
version: yyyy
Activate (0)
Commit (1)
Reboot
Activate (0)
Commit (1)
Commit (0)
Commit (0)
Reboot
Activate (1)
State S4
SW image 0
is active: no
is committed: yes
is valid: yes
version: xxxx
End
download (0)
State S3'
State S3
SW image 0
is active: yes
is committed: yes
is valid: yes
version: xxxx
SW image 1
is active: yes
is committed: yes
is valid: yes
version: yyyy
State S4'
SW image 1
is active: yes
is committed: no
is valid: yes
version: yyyy
Activate (1)
Commit (0)
Activate (0)
Commit (1)
SW image 0
is active: yes
is committed: no
is valid: yes
version: xxxx
SW image 1
is active: no
is committed: yes
is valid: yes
version: yyyy
G.988(12)_FI.3.1-1
NOTE In Figure I.3.1-1, states S1 and S2 (and S1' and S2') are distinguished only for convenience in understanding the flow. Upon
receipt of a start download message, and particularly when the ONU re-boots, any partial downloads in progress are discarded.
Figure I.3.1-1 Software image state diagram

534
Rec. ITU-T G.988 (10/2012)
I.3.2
Software image download
The software image download operation is a file transfer from the OLT to the ONU. The OMCI
defines two mechanisms to download software images to ONUs. This clause describes the
mechanism built into the OMCI, first describing download in the context of the baseline OMCI
message set; the description is then modified as appropriate for the extended message set.
The second download mechanism uses the OMCI to define the parameters of a file transfer from an
external server, which may or may not be the OLT. The file transfer controller is defined in
clause 9.12.13, and is not discussed further in this clause.
I.3.2.1
Baseline message set download
The atomic unit of file transfer is the section, the 31 bytes of data that can be transferred in a single
(baseline) download section message. The last section in a software download may be padded with
null bytes as needed.
A number of sections comprise a so-called window. A window may not exceed 256 sections. Figure
I.3.2.1-1 illustrates the relationship between a software image and its decomposition into windows
and sections.
Section
byte number
Window
"Download
section number"
...
0 1 2
...
30
Window
size-1
Image
G.988(12)_FI.3.2.1-1
Figure I.3.2.1-1 Relationship between image, windows and sections (baseline message set)
During the initial software download message exchange, the OLT proposes a maximum window
size, but a lower value can be stipulated by the ONU, which must be accepted by the OLT. The
OLT may send windows with fewer sections than this negotiated maximum, but may not exceed the
maximum. Though it is not a preferred choice, the OLT may send all windows at the full negotiated
maximum size, with the final window of the download operation padded out with download section
messages containing only null pad bytes.
Each download section message contains a sequence number, which begins anew at 0 with each
window. By tracking the incrementing sequence numbers, the ONU can confirm that it has in fact
received each section of code.
In the message type field of the last download section message of each window, the OLT indicates
the end of the window by setting the AR (acknowledgement request) bit prior download section
messages are unacknowledged. If the ONU has not received the entire window correctly, i.e., if it
misses a sequence number, it acknowledges with a command processing error result, whereupon the
OLT falls back to the beginning of the window and tries again. To improve the chance of successful
transmission, the OLT may choose to reduce the size of the window on its next attempt.
When the final window has been successfully downloaded, the OLT sends an end software
download message whose contents include the size of the downloaded image in bytes, along with a
CRC-32 computed according to [ITU-T I.363.5], across the entire image but excluding pad bytes
Rec. ITU-T G.988 (10/2012)
535
that may have been transmitted. If the ONU agrees with both of these values, it updates the software
image validity attribute to indicate that the newly downloaded image is valid. Figure I.3.2.1-2
illustrates this process.
OLT
ONU
Start software download (instance, window size-1, image size[, parallel download info])
The ONU sets given software image ME to not valid.
The ONU updates MIB data sync.
The ONU responds with the same or smaller window size N.
Start software download response (instance, success, window size-1[, parallel download info])
The OLT accepts proposed window size N.

The OLT updates the MIB and increments MIB data sync.
The OLT downloads the first window: for illustration,
this one contains N full sections.
Download section (instance, section 0, 31 bytes of image data)
...
Download section (instance, section N-1, 31 bytes of image data) [AR = ack rqst]
Download section response (instance, command processing error, section N-1)
ONU signals failure to receive some or all of window.
The OLT re-transmits the window. For illustration, the OLT
chooses to send only S sections this time, S N.
...
Download section (instance, section S-1, 31 bytes of image data) [AR]
Download section response (instance, success, section S-1)
The OLT transmits the final window.
For illustration, F sections (F N) are assumed
with padding required in section F-1. The OLT chooses
to send only F sections, rather than an additional
(N F) trailing padding-only section.
...
Download section (instance, section F-1, 31 bytes of image data padded with nulls) [AR]
Download section response (instance, success, section F-1)
The OLT terminates the software download.
End software download (instance, CRC-32, image size[, parallel download info])
End software download response (instance, success[, parallel download status])
The ONU terminates software download,
marks its image instance(s) valid.
G.988(12)_FI.3.2.1-2
Figure I.3.2.1-2 Software download, baseline message set

The ONU should positively acknowledge an end download message only after it has performed
whatever operations may be necessary such as storage in non-volatile memory to accept an
immediate activate or commit message from the OLT. As illustrated in Figure I.3.2.1-3, the ONU
536
Rec. ITU-T G.988 (10/2012)
should respond with a device busy result code until these operations are complete, and the OLT
should periodically retry the end download command. The OLT should include a timeout to detect
an ONU that never completes the download operation.
OLT
ONU
The OLT sends the last window.

Download section (Software image (section 0, image data))
Download section (section 1, image data)
...
Download section (section N-1, image data) [AR = ack rqst]
The ONU successfully receives the window.
Download section response
End software download (instance, CRC-32, image size)
CRC32 and image size ok, but
the ONU is not ready to activate or commit.
End software download response (result-reason 0110 = device busy)
The OLT retries after a delay.
End software download (instance, CRC-32, image size)
CRC and image size ok.
The ONU is now ready to commit.
The ONU sets valid attribute of software image
instance and updates MIB data sync.
End software download response (ok)
G.988(12)_FI.3.2.1-3
Figure I.3.2.1-3 Busy response handling

The nested state machines in the OLT and ONU can conceivably get out of step in a number of
unspecified ways; nor is it specified how to escape from a loop of transmission failure and retry. As
a recovery mechanism from detectable state errors, it is recommended that the ONU reply with
command processing error result codes to both the acknowledged download section and end
software download commands, and that the OLT send a final end software download command
with a known bad CRC and image size (e.g., all 0), whereupon both the OLT and ONU should reset
to the state in which no download is in progress, that is, state S1/S1' of Figure I.3.1-1. Likewise, the
OLT should be able to abort the download operation at any time by sending an end software
download message with invalid CRC and image size.
As well as the download of an image to the ONU as a whole, the download messages allow an
option to download an image to each of several circuit packs in parallel. The starting assumption is
that the OLT knows the set of circuit packs that require the same download file, so that it can
specify this set in the download command sequence.
I.3.2.2
Extended message set download
The description of clause I.3.2.1 pertains also to download using the extended OMCI message set,
except that the maximum size of the section is limited by the extended message format itself, and is
potentially as large as 1965 bytes. The OLT may send smaller sections at will, including the final
section of a file transfer. Because the extended message format allows for variable length, software
image sections are never padded in this message format.
Rec. ITU-T G.988 (10/2012)
537
I.3.3
Software image activate and commit
Figure I.3.3-1 shows the details of software image activate and commit. When the ONU has
downloaded and validated a new image, that image is initially not-committed and not-activated. The
OLT may then send the activate image command. After the ONU sends a positive activate image
response, the ONU loads and executes the new software image, but without changing the committed
state of either image. The OLT may then send the commit image command, causing the ONU to set
the commit state true for the new image, and false for the previous image. The time between the
download, activate and commit phases is not specified.
If there is a problem with the newly activated image that causes the ONU to fail (e.g., watchdog
timeout), the ONU should do a soft restart on the (other) committed image. Activating prior to
committing may thereby allow for automatic failure recovery by the ONU.
OLT
ONU

Activate image (software image (instance))
The ONU updates its MIB and
Activate image response
The ONU restarts with a new image,

which is now active but uncommitted.
...
After a successful start-up sequence,

the OLT decides to commit
the active software image.
Commit image (software image (instance))
The ONU updates its MIB and
Commit image response
G.988(12)_FI.3.3-1
Figure I.3.3-1 Software activate and commit

I.4
Performance monitoring
The tools used for performance monitoring (PM) are:
The performance monitoring history data and extended PM managed entities. PM is defined
in clause 9 for many ONU functions including GEM adaptation, circuit emulation service,
Ethernet service and voice service.
The synchronize time action on the ONU-G ME. This action synchronizes all PM MEs to a
common 15-minute collection interval starting point.
The threshold data 1 and threshold data 2 ME pair. These MEs provide thresholds for the
threshold crossing alert (TCA) function.
The TCA notification, which alerts the OLT to a threshold crossing event.
Performance monitoring managed entities share a number of characteristics, as described in this
clause. Exceptions to the generic behaviour are defined in the specific managed entity affected.
538
Rec. ITU-T G.988 (10/2012)
Two groups of PM managed entities are defined:

1)
Classical PM, whose members are identified by names containing the string, "performance
monitoring history data".
2)
Extended PM, whose members are identified by names containing the string, "extended
PM".
All PM managed entities are created and deleted by the OLT.
The remainder of this parent clause describes behaviour common to the two classes of PM MEs.
Aspects unique to each PM ME class are discussed in the following subclauses.
PM collection intervals
Classical PM, and optionally extended PM, are based on the assumption of a continuing sequence
of 15-minute intervals. This sequence of 15-minute intervals is coordinated by the synchronize time
action, issued by the OLT against the ONU-G managed entity. The synchronize time action resets
all PM attributes, establishes a 15-minute tick boundary and starts numbering the intervals from 0.
The interval number is represented by the interval end time attribute of the PM ME, a single byte
counter that rolls over from 255 to 0.
The synchronize time action is the only mechanism guaranteed to reset either the phase or the
interval number. For example, neither ONU re-boot nor MIB reset can be expected to have these
effects (the performance monitoring consequence of these events is undefined). In the absence of a
synchronize time message, an ONU would be expected to maintain 15-minute intervals
asynchronously with the outside world, and with an incrementing but arbitrary interval identifier.
No explicit mechanism is provided to synchronize a new PM ME that may be created on a working
ONU. Best practice suggests that the ONU run all of its 15-minute PM according to a single
ONU-wide 15-minute timer and interval counter.
The ONU does not perform any calculations upon the collected data nor does it keep an archive of
collected data beyond the previous 15-minute interval. Archival and analysis, if required, are
performed by a higher order network element such as the OLT or EMS, along with possible
accumulation into 24-hour statistics.
In 15-minute accumulation mode, as distinguished from the optional continuous accumulation mode
of the extended PM MEs, the ONU conceptually has only two storage bins for each PM ME
instance: a current accumulator and a history bin. At 15-minute intervals, they switch roles. History
is discarded at age thirty minutes, when the previous history bin is initialized into its role as the new
current accumulator. The previous accumulator, now in its role as the history bin, retains its totals
for 15 minutes, so that the OLT can upload them if desired.
In 15-minute accumulation mode, the get action on a PM managed entity returns the values of
attributes in the history bin. An ONU may also support an optional action in 15-minute
accumulation mode, get current data. The effect of this action is to return the value of attributes in
the current accumulator. When a PM attribute is an average or a ratio, it acquires a value only at the
end of a 15-minute interval. The value returned by a get current data operation is undefined (0xFF
in every byte would be reasonable).
Thresholds and alerts
The OMCI supports PM thresholds and threshold crossing alerts. Not all PM attributes can be
thresholded; threshold definition and assignment is part of the specification of each PM attribute.
The PM ME definition includes a pointer to threshold data MEs, a null pointer by default. If the
OLT does not require TCAs, it leaves the pointer undefined. To enable thresholds, the OLT creates
an instance of the threshold data 1 ME, and if any of the required thresholds is numbered above 7,
Rec. ITU-T G.988 (10/2012)
539
also an instance of the threshold data 2. The OLT then populates the threshold data attributes with
threshold values in accordance with the mapping defined in each type of PM ME.
Any number of PM ME instances may subscribe to a given set of thresholds.
Most performance attributes are counters. During the accumulation interval, the PM managed entity
collects counter statistics in accordance with each PM attribute definition, and continuously
compares the accumulated values with any thresholds that may exist. When an accumulated value
first equals or exceeds the threshold, the ONU originates a TCA.
If a counter PM attribute should fill up during the interval, it remains at its maximum possible
value, rather than rolling over.
The threshold for a given counter attribute may be disabled by setting it either to 0 or to 0xFFFF. It
may also be effectively disabled by setting it to a value greater than the range of the counter, for
example, a value greater than 900 when used for an errored seconds PM attribute.
The OLT may modify a threshold attribute at any time. If the modification lowers the threshold
such that it has already been passed, the TCA is reported when the current value is next compared
with the threshold value. This comparison is specific to the ONU's architecture, so that the timing or
even the existence of a TCA during the current interval cannot be guaranteed.
Regardless of the origin of a given TCA, the ONU issues a second TCA at the end of the current
15-minute interval, cancelling the first. That is, each 15-minute interval begins with all previous
TCAs explicitly cleared via notifications to the OLT.
When a PM attribute is an average or a ratio, its value is computed only at the end of the interval. A
TCA on such an attribute can therefore be declared only at the end of the interval. The TCA is then
immediately cleared as the accumulator is reset for the next interval. The definition of a given PM
attribute may specify different or more detailed behaviour.
When a PM attribute is a high-water-mark, a TCA is declared when the monitored parameter equals
or exceeds the threshold value from below; conversely for a low-water-mark attribute. There is no
general definition of the mechanism to clear the TCA, nor specification of delay or hysteresis to
avoid TCA storms for a parameter fluctuating near the threshold value. These should be defined in
the specification of each PM attribute.
TCAs are reported in OMCI alarm messages. There is no overlap between TCA code points and
alarm code points, because a given ME class declares either alarms or TCAs, but not both.
MIB sync
The control block of a PM ME contains persistent data that can be set by the OLT. Setting the value
of a control block attribute therefore increments the MIB data sync attribute of the ONU data ME.
In addition, the control block attribute of a PM ME is included in a MIB upload. Other PM
attributes are transient and are not included in MIB uploads.
Template for the definition of a PM ME
Existing PM generally follows the outline below. Significant exceptions are discussed here; an
implementation is advised to be aware that the definitions of individual MEs and attributes may
contain other exceptions.
<Description>
Relationships
<Relationships>
Attributes
Managed entity ID: This attribute is discussed further in the separate clauses below.
540
Rec. ITU-T G.988 (10/2012)
Control block: This attribute is discussed further in the separate clauses below. In classical
PM, it is just a pointer to threshold data MEs.
Definition of the first PM accumulation attribute, in most cases a counter, in
other cases, an average, a high water-mark or a low water-mark. Four bytes is
the recommended size of a PM accumulation attribute, but definitions vary.
PM1:
PM2:
Definition of additional PM accumulation attributes, maximum not to exceed
14. There is no particular preference on the order in which parameters are
defined.
Actions
Notifications
Alarm
number
Threshold data counter #

(Note)
PM1
PM2
NOTE This number associates the TCA with the specified threshold value
attribute of the threshold data 1 managed entity.
The threshold crossing alert column lists thresholded attributes in order. It is not required that all
attributes be thresholdable. The alarm number column identifies a bit in the alarm bit map field of
the OMCI alarm message that is used to report TCAs. Alarm numbering starts at 0.
The threshold data counter column assigns threshold attributes of the threshold data 1 and if
required, the threshold data 2 MEs. In all cases, the assignment is monotonic, but existing PM
definitions may or may not skip a threshold attribute for each PM attribute that is to be thresholded.
In future PM definitions, it is recommended that threshold attributes be assigned sequentially,
without gaps. If, for example, the only thresholded PM attributes were the first, third and sixth in
order of PM ME definition, they would still be assigned threshold attributes 1, 2, 3.
I.4.1
Classical PM
Unneeded PM accumulation may impose unnecessary load on the ONU host processor and should
be avoided. In classical PM, parameter collection can be disabled only by deleting the PM ME.
In classical PM, the managed entity ID attribute takes the same value as the parent managed entity's
ME ID, so that no explicit pointer to the parent ME is required. The ME class of the parent is fixed
in the definition of the classical PM ME.
instance of a <parent managed entity class>. (R, Set-by-create) (mandatory)
(2 bytes)
Rec. ITU-T G.988 (10/2012)
541
In classical PM, the control block attribute is always a simple pointer to a threshold data ME, and is
designated as such. The attribute value may be set to a null pointer if no thresholding is desired. If
no assigned threshold number exceeds 7, it is the OLT's option whether to create a threshold data 2
ME or not. The template text reads as follows, depending on the highest threshold attribute
assigned:
Or:
I.4.2
Extended PM
In extended PM, the control block attribute is defined to be (R, W, Set-by-create) (mandatory) (16
bytes). The template for these 16 bytes is as follows:
Threshold data 1/2 ID: (2 bytes) The definition of this field is the same as for that in
classical PM.
NOTE When PM is collected on a continuously-running basis, rather than in 15minute intervals, counter thresholds should not be established. There is no
mechanism to clear a TCA, and any counter parameter may eventually be expected
to cross any given threshold value.
Parent ME class: (2 bytes) This field contains the enumerated value of the ME class of the
PM ME's parent, as defined in Table 11.2.4-1. Together with the parent ME
instance field, this permits a given PM ME to be associated with any OMCI
ME. The definition of an extended PM ME should list the allowed parent ME
classes.
Parent ME instance: (2 bytes) This field identifies the specific parent ME instance to
which the PM ME is attached.
Accumulation disable: (2 bytes) This bit field allows PM accumulation to be disabled; refer
to Table I.7.2-1. Bit value 0 enables PM collection. If bit 15 is set to 1, no
PM is collected by this ME instance. If bit 15 = 0 and any of bits 14..1 are set
to 1, PM collection is inhibited for the attributes indicated by the 1 bits.
Inhibiting PM collection does not change the value of a PM attribute, but if
PM is accumulated in 15-minute intervals, the value is lost at the next 15minute interval boundary.
Bit 16 is an action bit that always reads back as 0. When written to 1, it resets
all PM attributes in the ME, and clears any TCAs that may be outstanding.
Table I.4.2-1 Bit assignments in extended PM control block
Bit
Accumulation
disable
TCA disable
542
16
15
14
13
1
(LSB)
Global
clear
Global
disable
PM14
PM2
PM1
Global
disable
Th14
Th2
Th1
Rec. ITU-T G.988 (10/2012)
TCA disable: (2 bytes) Also clarified in Table I.4.2-1, this field permits
TCAs to be inhibited, either individually or for the complete managed entity
instance. As with the accumulation disable field, bit value 0 enables TCAs,
and setting the global disable bit overrides the settings of the individual
thresholds. Unlike the accumulation disable field, the bits are mapped to the
thresholds defined in the associated threshold data 1 and 2 ME instances.
When the global or attribute-specific value changes from 0 to 1, outstanding
TCAs are cleared, either for the ME instance globally or for the individual
disabled threshold. These bits affect only notifications, not the underlying
parameter accumulation or storage.
If the threshold data 1/2 ID attribute does not contain a valid pointer, this
field is not meaningful, since no TCAs are possible.
Control fields: (2 bytes) This field is a bit map whose values govern the
behaviour of the extended PM ME. Bits are assigned as follows:
Bit 1 (LSB) The value 1 specifies continuous accumulation, regardless
of 15-minute intervals. There is no concept of current and
historical accumulators; get and get current data (if
supported) both return current values. Accumulated values
are only reset by the clear flags, not by any timed or other
action. The value 0 specifies 15-minute accumulators
exactly like those of classical PM.
Bit 2
The value 0 specifies directionality, for example upstream
or downstream, or up/down in an [IEEE 802.1ag] sense
with respect to a bridge port. If this bit is meaningful, the
details are part of the definition of the extended PM ME.
Bits 3..16
Reserved. Starting from bit 16, and working downwards,
these bits may be used in the definition of individual
extended PM MEs. Continuing upwards from bit 3, these
bits may be used for additional purposes that pertain to all
extended PM MEs.
For example, in a VLAN extended PM ME, bits 16-15
could be used to match P bits, VID or both.
Reserved: (4 bytes) These bytes are available for customization in the
definition of each extended PM ME.
For example, in a VLAN extended PM ME, two of these bytes could be used
to specify TCI.
The other template boiler plate fields are revised in extended PM to read as follows:
To facilitate discovery, it is encouraged to identify instances sequentially
starting with 1. (R, Set-by-create) (mandatory) (2 bytes)
Interval end time: This attribute identifies the most recently finished 15-minute interval. If
continuous accumulation is enabled in the control block, this attribute is not
used and has the fixed value 0. (R) (mandatory) (1 byte)
Threshold data 1/2 ID: <same textual options as in classical PM>. Thresholding is not
advised for counter attributes if PM is accumulated continuously. (R, W, Setby-create) (mandatory) (2 bytes)
It is not expected that the PM accumulation policy will be changed in actual deployment practice,
and the behaviour of intervals, TCAs and accumulated history across a transition between
Rec. ITU-T G.988 (10/2012)
543
continuous and interval accumulation is not specified. It may be desirable to disable and clear PM at
such a transition.
The synchronize time action has no observable effect on PM that is accumulated continuously.
Counter PM attributes do not roll over in interval PM mode, but do roll over from maximum to zero
in continuous accumulation mode. PM attributes that record averages or ratios are undefined in
continuous accumulation mode. Both of these behaviours may be overridden by explicit
specification in the definition of a given extended PM ME.
544
Rec. ITU-T G.988 (10/2012)
Appendix II
G-PON mechanisms and services
(This appendix does not form an integral part of this Recommendation.)
NOTE When text in this clause refers to the IP host config data ME, or to an IP stack, it is understood to
include the IPv6 host config data ME, or an IPv6 stack, as modified suitably by the differences between IPv4
and IPv6.
This appendix describes mechanisms and services that are common to G-PON systems, as described
in [ITU-T G.984.x] and [ITU-T G.987.x].
II.1
Layer 2 data service according to [b-BBF TR-156]
II.1.1
Requirements base
[b-BBF TR-156] provides Broadband Forum's core set of requirements for layer 2 data service
functionality within a G-PON access node. [b-BBF TR-156] addresses three network service
architectures:
1)
1:1 VLANs Indicates a one-to-one mapping between user port and VLAN. The
uniqueness of the mapping is maintained in the G-PON access node and across the
aggregation network.
2)
N:1 VLANs Many-to-one mapping between user ports and VLAN. The user ports may be
located in the same or different G-PON access nodes.
3)
VLANs for business Ethernet services (VBES, also known as TLS) Transparent transport
of incoming frames as they arrive at the UNIs regardless of whether they are VLAN tagged,
priority tagged or untagged.
It is desirable to implement G-PON systems with at least the layer 2 OMCI common model
(L2-OCM) defined in this clause, which supports the requirements of [b-BBF TR-156]. A system
may also support additional OMCI layer 2 models or extend the common model.
This clause describes recommended provisioning models and message sequences to support
[b-BBF TR-156]. However, it is important to recognize that the OLT and ONU have a master-slave
relationship, with the OLT as master. Therefore, the OLT may choose to provision the ONU with
only a subset of the models described in this text or a subset of the functionality defined in
[b-BBF TR-156], and the ONU should act as commanded by the OLT. Only if the OLT requests
ONU actions that are beyond the capabilities represented here, is the OLT considered to be
performing outside of the scope of this text.
II.1.2
II.1.2.1
Layer 2 unicast data services

Single UNI OMCI provisioning model
The layer 2 OMCI common model (L2-OCM) is the minimum that should be supported by all
G-PON systems. It is based on the 1:MP model of Figure 8.2.2-7. This model combines MAC
bridging and IEEE 802.1p mapping functionality for a single UNI. Figure II.1.2.1-1 illustrates
L2-OCM applied to a single UNI ONU. The diagram assumes an Ethernet UNI, but the same
provisioning model can be used for other UNI types.
Rec. ITU-T G.988 (10/2012)
545
Traffic
descriptor
(downstream)
GEM
interworking
TP
VLAN
tagging
filter
802.1p
mapper
service
profile
MAC bridge
port filter
table data
MAC bridge
port config
data
Ext VLAN
tag
operation
config data
PPTP
Ethernet
UNI
Priority queue
A1
(downstream)
UNI-G
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 1
PQ A2
Traffic
descriptor
(upstream)
GEM port
network
CTP
GEM
interworking
TP
T-CONT
Priority queue
1 (upstream)
PQ 2
T-CONT
MAC bridge
port filter
pre-assign
table
Priority queue
A2
(downstream)
Priority queue
A3
(downstream)
Traffic
descriptor
(downstream)
PQ A1
MAC bridge
port config
data
Traffic
descriptor
(downstream)
MAC bridge
service
profile
Traffic
descriptor
(downstream)
MAC bridge
port config
data
Priority queue
A4
(downstream)
GEM port
network
CTP
GEM
interworking
TP
MAC bridge
port filter
table data
MAC bridge
port filter
pre-assign
table
VLAN
tagging
filter
GEM
interworking
TP
802.1p
mapper
service
profile
Traffic
descriptor
(downstream)
GEM
interworking
TP
Traffic
descriptor
(downstream)
GEM
interworking
TP
PQ A1
PQ A2
Traffic
descriptor
(upstream)
Priority queue
2 (upstream)
PQ 1
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 2
PQ A3
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 3
PQ A4
Traffic
descriptor
(upstream)
GEM port
network
CTP
T-CONT
Priority queue
3 (upstream)
T-CONT
Priority queue
4 (upstream)
PQ 4
G.988(12)_FII.1.2.1-1
Figure II.1.2.1-1 Single UNI, two VLANs with common priorities

Figure II.1.2.1-1 shows provisioning to provide upstream mapping of two VIDs and the
IEEE 802.1p priorities within those VIDs. With the VID selected by a VLAN tagging filter, the
upper part of the diagram provisions IEEE 802.1p priorities to two GEM ports, each going to a
single priority queue. In the lower part of the diagram, the other VID is provisioned to map
IEEE 802.1p priorities to four GEM ports, each going to a single priority queue.
Figure II.1.2.1-1 shows only four priority queues because this is the minimum requirement of
[b-BBF TR-156]. The diagram can easily be extended to six classes of traffic, the objective of
[b-BBF TR-156], by adding GEM port network CTPs, GEM interworking TPs, priority queues and
T-CONTs.
546
Rec. ITU-T G.988 (10/2012)
NOTE This clause is specific to [b-BBF TR-156], which contemplates only a single queue per T-CONT.
Multiple queues per T-CONT are discussed further in clause II.3.
Figure II.1.2.1-2 depicts another provisioning option using the L2-OCM. This provisioning treats
each of the two VLANs as having an implied priority that is beyond the scope of the IEEE 802.1p
priority bits; that is, the P-bit space of one VLAN does not correspond to the same P-bit priorities of
the other. The P bits of each VLAN are mapped separately to different queues, thence to different
T-CONTs. VID1 is mapped to one bridge port and IEEE 802.1p mapper, while VID2 is mapped to
another bridge port and mapper. Each IEEE 802.1p mapper maps P-bit values 2 and 3 (for example)
to separate priority queues, resulting in four distinct priority flows, both upstream and down. By
grooming traffic into separate T-CONTs, the option is available for the OLT to provide different
service levels, even for traffic with the same P-bit values.
Traffic
descriptor
(downstream)
Ext VLAN
tag
operation
config data
PPTP
Ethernet
UNI
Priority queue
A1
(downstream)
Priority queue
A2
(downstream)
Priority queue
A3
(downstream)
UNI-G
Priority queue
A4
(downstream)
VLAN
VID 1 tagging
filter
GEM
P bits = 2 interworking
TP
802.1p
mapper
service
profile
MAC bridge
port config
data
Traffic
descriptor
(downstream)
MAC bridge
GEM
port config
data
TP
MAC bridge
service
profile
Traffic
descriptor
(downstream)
GEM
MAC bridge P bits = 2 interworking
port config
TP
data
802.1p
mapper
service
profile
VLAN
VID 2 tagging
filter
Traffic
descriptor
(downstream)
GEM
TP
PQ A1
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 1
PQ A2
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 2
T-CONT
PQ A3
Traffic
descriptor
(upstream)
Priority queue
2 (upstream)
GEM port
network
CTP
PQ 3
T-CONT
PQ A4
Traffic
descriptor
(upstream)
Priority queue
3 (upstream)
GEM port
network
CTP
PQ 4
T-CONT
Priority queue
1 (upstream)
T-CONT
Priority queue
4 (upstream)
G.988(12)_FII.1.2.1-2
Figure II.1.2.1-2 Single UNI, two VLANs, VID-based priorities

II.1.2.1.1 T-CONT and GEM port usage
The common OMCI model uses four T-CONTs, each representing a single logical connection group
associated with an alloc-ID. To meet [b-BBF TR-156] requirements, each T-CONT transports a
single traffic class, and with only one priority queue. One queue per T-CONT relieves the ONU of
Rec. ITU-T G.988 (10/2012)
547
most of its upstream QoS responsibilities; the bandwidth allocation algorithm in the OLT governs
QoS in fine detail.
Each T-CONT ME is instantiated with its policy attribute set to the ONU's default; since only one
priority queue is associated with the T-CONT, the policy attribute should be treated as a "don't
care" by the OLT. Clause II.3 discusses QoS management when a T-CONT is served by more than
one queue.
Each T-CONT is associated with 1 to N GEM ports by way of its upstream priority queue. Each
GEM port is represented in the model by a GEM interworking TP and a GEM port network CTP.
The following provisioning considerations pertain to these MEs:
GEM interworking TP
The GEM port network CTP connectivity pointer attribute is set to point to the partner
GEM port network CTP ME.
The interworking option, service profile pointer, and GAL profile pointer attributes should
all be set according to the IEEE 802.1p mapper service option.
The interworking termination point pointer attribute is set to 0 and not used.
The direction attribute is set to 3 to indicate a bidirectional GEM port.
The priority queue pointer for the downstream attribute should point to the desired
downstream priority queue. However, downstream frames arriving at the GEM port are
conceptually routed through the IEEE 802.1p mapper and MAC bridge, where tagging and
filtering operations may be performed, rather than directly transferred to the downstream
priority queue. Therefore, it is important that the provisioning of the MAC bridge and the
priority queue pointer attribute agree on the destination UNI for downstream frames. The
consequences of inconsistent provisioning are not defined.
The traffic management pointer for upstream, traffic descriptor profile pointer for upstream,
and traffic descriptor profile pointer for downstream attributes should be supported. For
detailed information on the use of the traffic attributes, refer to clause II.3.
II.1.2.1.2 Classification and marking
The extended VLAN tagging operation data ME provides classification and marking of ingress
frames at the UNI. This includes the ability to add tags based on Ethertype and to set IEEE 802.1p
P-bit values based on DSCP.
II.1.2.1.3 MAC address filtering
Figure II.1.2.1-1 depicts a MAC bridge port filter pre-assign table ME and a MAC bridge port filter
table data ME associated with the ANI side MAC bridge port configuration data MEs. While these
MEs are automatically created by the ONU upon creation of all MAC bridge port configuration data
MEs, the diagram is simplified by showing only the ANI side MEs. These MEs are used in the
following manner (filtering applies to frames exiting the MAC bridge port):
The MAC bridge port filter pre-assign table ME filters frames based on predefined
addresses or Ethertype. The list of filter options is defined in clause 9.3.7.
The MAC bridge port filter table data ME filters frames based on specific MAC addresses.
MAC address learning should be disabled prior to the setting of table entries.
[b-BBF TR-156] requires support only for upstream MAC address filtering.
NOTE MAC address filtering is supported in all models (single UNI, multiple UNI, single and multiple
UNI with multicast) but is only shown in Figure II.1.2.1-1 to minimize the complexity of figures depicting
the more complex models.
548
Rec. ITU-T G.988 (10/2012)
II.1.2.1.4 Flow routing

Flow routing within the ONU is provisioned using a combination of the MAC bridge ME group and
the IEEE 802.1p mapper service profile.
The MAC bridge ME group supports flow routing based on VID, with the following provisioning
considerations:
With the exception of the MAC bridge port filter MEs, the L2-OCM diagram in
Figure II.1.2.1-1 is simplified to show only MAC bridge MEs that are created by the OLT.
The ONU automatically instantiates several additional MEs when a MAC bridge service
profile or MAC bridge port config data ME is created by the OLT. The ONU should
support these MEs for completeness of overall MAC bridge functionality.
The VLAN tagging filter data ME implements VID-based flow mapping. In cases where
VID flow mapping is not required, this ME need not be created, and only a single ANI side
MAC bridge port config data and a single IEEE 802.1p mapper are needed.
The MAC bridge model does not map subscriber data flows based on P-bits. This
functionality resides in the IEEE 802.1p mapper.
The IEEE 802.1p mapper service profile supports upstream flow routing based on IEEE 802.1p
priority bits, with the following provisioning considerations:
The TP pointer attribute should be set to null, as required for a bridging-mapping model.
The TP type attribute should be set to 0, to indicate that a bridging-mapping model is being
used.
II.1.2.1.5 Message flows
Figures II.1.2.1.5-1 to II.1.2.1.5-6 depict the core message flow used to create the L2-OCM. Each
figure represents a step within the flow. Each step may be performed multiple times to produce
multiple ME instances. It is recommended to follow the depicted ordering of steps and the ordering
of messages within those steps to ensure that no ME pointer attribute is populated prior to the
creation of its target ME. Since the GEM interworking TP ME and the IEEE 802.1p mapper service
profile ME point to each other, it is particularly important to create the IEEE 802.1p mapper service
profile ME with null interwork TP pointers for P-bit priority attributes. Only in step 5, after the
GEM interworking TP MEs have been created, are the mapper's attributes populated with pointers
to the MEs.
OLT
ONU
Create (GEM port network CTP)
Once per T-CONT
Create response
G.988(12)_FII.1.2.1.5-1
Figure II.1.2.1.5-1 L2-OCM message flow Step 1

OLT
ONU
Create (GAL Ethernet profile)
At least once
per ONU
Create response
Create (MAC bridge service profile)
Once per UNI
Create response
G.988(12)_FII.1.2.1.5-2
Rec. ITU-T G.988 (10/2012)
549
OLT
ONU
Create (802.1p mapper service profile)

Create response
Create (MAC bridge port config data)
The ONU automatically creates an instance of:
- MAC bridge port designation data
- MAC bridge port filter table data
- MAC bridge port bridge table data
Once per ANI-side

MAC bridge port
Create response
Create (VLAN tagging filter data)
Create response
G.988(12)_FII.1.2.1.5-3

OLT
ONU
Create (GEM interworking TP)
Once per GEM port
Create response
G.988(12)_FII.1.2.1.5-4

OLT
ONU
Set (802.1p mapper service profile (interwork pointer GEM IW TP))
Once per mapped

priority per 802.1p
mapper
Set response
G.988(12)_FII.1.2.1.5-5

OLT
ONU
The ONU automatically creates an instance of:
- MAC bridge port designation data
- MAC bridge port filter table data
- MAC bridge port bridge table data
Create response
Once per UNI
Create (extended VLAN tagging operation config data)

Create response
Set (extended VLAN tagging operation config data, tagging rules)
Set response
G.988(12)_FII.1.2.1.5-6

II.1.2.2
Multiple UNI OMCI provisioning model
The multiple UNI L2-OCM is an extension to the single UNI model shown in Figure II.1.2.1-1. As
illustrated in Figure II.1.2.2-1, the extension is accomplished by adding another instance of the
single UNI L2-OCM for each UNI. It is important to note that there are still the same number of
upstream queues and T-CONTs as in the single-UNI diagram.
550
Rec. ITU-T G.988 (10/2012)
For clarity of presentation, Figure II.1.2.2-1 does not include as many GEM ports per UNI as does
Figure II.1.2.1-1. However, the underlying functionality associated with each UNI is the same.
Rec. ITU-T G.988 (10/2012)
551
Traffic
descriptor
(downstream)
Ext VLAN
tag
operation
config data
PPTP
Ethernet
UNI
Priority queue
A1
(downstream)
Priority queue
A2
(downstream)
Priority queue
A3
(downstream)
UNI-G
GEM
interworking
TP
VLAN
tagging
filter
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
MAC bridge
port config
data
MAC bridge
port config
data
GEM
interworking
TP
Traffic
descriptor
(downstream)
MAC bridge
service
profile
Priority queue
A4
(downstream)
GEM
interworking
TP
MAC bridge
port config
data
802.1p
mapper
service
profile
Traffic
descriptor
(downstream)
GEM
interworking
TP
VLAN
tagging
filter
Traffic
descriptor
(downstream)
Ext VLAN
tag
operation
config data
PPTP
Ethernet
UNI
Priority queue
B1
(downstream)
Priority queue
B2
(downstream)
Priority queue
B3
(downstream)
UNI-G
Priority queue
B4
(downstream)
802.1p
mapper
service
profile
MAC bridge
port config
data
MAC bridge
port config
data
Traffic
descriptor
(downstream)
GEM
interworking
TP
Multicast
subscriber
config info
GEM
interworking
TP
MAC bridge
port config
data
Multicast
operations
profile
802.1p
mapper
service
profile
VLAN
tagging
filter
Traffic
descriptor
(downstream)
GEM
interworking
TP
Figure II.1.2.2-1 Multi-UNI L2-OCM

552
Rec. ITU-T G.988 (10/2012)
GEM port
network
CTP
PQ 1
PQ A2
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 2
PQ A3
Traffic
descriptor
(upstream)
Priority queue
2 (upstream)
GEM port
network
CTP
PQ 3
T-CONT
PQ A4
Traffic
descriptor
(upstream)
Priority queue
3 (upstream)
GEM port
network
CTP
PQ 4
PQ B1
Traffic
descriptor
(upstream)
PQ B2
GEM port
network
CTP
Traffic
descriptor
(downstream)
MAC bridge
service
profile
Traffic
descriptor
(upstream)
GEM port
network
CTP
GEM
interworking
TP
VLAN
tagging
filter
PQ A1
PQ B3
Priority queue
1 (upstream)
T-CONT
T-CONT
Priority queue
4 (upstream)
PQ 1
Traffic
descriptor
(upstream)
PQ 2
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 3
PQ B4
Traffic
descriptor
(upstream)
GEM port
network
CTP
T-CONT
PQ 4
G.988(12)_FII.1.2.2-1
II.1.2.2.1 T-CONT and GEM port usage

Multiple UNI L2-OCM adds support for additional UNIs without increasing the number of
T-CONTs used by a single UNI L2-OCM. However, an additional set of GEM ports distinguishes
the separate flows and allows per-UNI service level agreement (SLA) capability in the ONU. GEM
ports are provisioned in the same manner as described in clause II.1.2.1.1.
II.1.2.2.2 Classification and marking
Classification and marking are provisioned on a per-UNI basis in the same manner as described in
clause II.1.2.1.2.
II.1.2.2.3 Flow routing
Flow routing is provisioned for each UNI through the use of a distinct MAC bridge ME group and
set of IEEE 802.1p mappers, as described in clause II.1.2.1.4.
II.1.2.2.4 Message flows
Provisioning of multiple UNI ONUs is accomplished through additional iterations of the message
flow described in clause II.1.2.1.5.
II.1.3
Layer 2 multicast data services
Within a G-PON ONU, multicast and broadcast capabilities have two applications. The first
application is traditional IGMP-controlled (or unconditional) downstream multicast traffic. The
second is the transport of infrequent downstream broadcast frames arriving at the network-facing
interface of the OLT. This is sometimes referred to as incidental broadcast.
Both applications require provisioning of data plane functionality. In addition, traditional multicast
requires provisioning of control plane functionality. This clause describes provisioning of both data
and control planes.
II.1.3.1
Data plane
A G-PON ONU can support both upstream and downstream broadcast or multicast frames.
However, the OMCI has no special provision to support upstream broadcast or multicast.
In contrast, the OMCI accommodates downstream multicast and broadcast provisioning. This
accommodation takes into account the point-to-multipoint nature of G-PON, which shares a GEM
port across all ONUs on the PON for multicast, and another GEM port for broadcast. The sharing of
GEM ports increases the downstream efficiency of the PON by avoiding the need to replicate
frames destined for different ONUs. Likewise, multicast and broadcast GEM ports are common to
the UNIs of a given ONU.
Traffic sent over either of these GEM ports may be contained in a VLAN, and more than one
VLAN may be present. Multicast or broadcast VLANs may be segregated to different UNIs by
filtering at the ANI side MAC bridge port.
NOTE The MC operations profile includes the specification of VLANs, which may, in some cases, make
ANI-side filtering unnecessary.
II.1.3.1.1 Single UNI OMCI provisioning model

Figure II.1.3.1.1-1 is the relationship diagram for L2-OCM with the addition of the MEs required
for multicast/broadcast provisioning. As indicated by the dotted box in this diagram,
multicast/broadcast support is built upon the model for unicast provisioning through the addition of
two specialized GEM ports. One GEM port is used for multicast traffic and the other is used for
incidental broadcast traffic. These are both unidirectional downstream GEM ports.
In the OMCI provisioning model, the multicast GEM port is represented by a GEM port network
CTP ME connected to a multicast GEM interworking TP. The multicast GEM interworking TP is
Rec. ITU-T G.988 (10/2012)
553
then connected into the unicast model through a MAC bridge config data ME. Since no upstream
traffic flows through this GEM port, there is no need for an IEEE 802.1p mapper between the MAC
bridge port config data ME and the multicast GEM interworking TP.
In the OMCI model, the incidental broadcast GEM port is represented by a GEM network CTP ME
connected to a GEM interworking TP. The GEM interworking TP is then connected into the unicast
model through a MAC bridge port config data ME. Since no upstream traffic flows through this
GEM port, there is no need for an IEEE 802.1p mapper between the MAC bridge port and the GEM
interworking TP.
Associated with the MAC bridge port config data MEs connected to each GEM port are VLAN
tagging filters. These MEs filter downstream broadcast frames so that only frames destined for the
affected UNIs are allowed into the bridge. Since no upstream frames are delivered over the
multicast GEM port, MAC address filtering is not needed on the MAC bridge port associated with
the multicast GEM IW TP.
Because the multicast operations profile lists the VLANs accepted by the UNI, best practice in a
[b-BBF TR-156] environment is to omit the possible VLAN tagging filter on the multicast GEM
interworking TP.
554
Rec. ITU-T G.988 (10/2012)
Traffic
descriptor
(downstream)
Multicast
operations
profile
Ext VLAN
tag
operation
config data
Priority queue
A1
(downstream)
Priority queue
A2
(downstream)
PPTP
Ethernet
UNI
Priority queue
A3
(downstream)
UNI-G
Priority queue
A4
(downstream)
Multicast
subscriber
config data
MAC bridge
port config
data
GEM
interworking
TP
VLAN
tagging
filter
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
MAC bridge
port config
data
GEM
interworking
TP
Traffic
descriptor
(downstream)
MAC bridge
service
profile
GEM
interworking
TP
MAC bridge
port config
data
802.1p
mapper
service
profile
Traffic
descriptor
(downstream)
GEM
interworking
TP
VLAN
tagging
filter
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 1
PQ A2
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 2
PQ A3
Traffic
descriptor
(upstream)
Priority queue
2 (upstream)
GEM port
network
CTP
PQ 3
T-CONT
PQ A4
Traffic
descriptor
(upstream)
Priority queue
3 (upstream)
GEM port
network
CTP
PQ 4
Traffic
descriptor
(downstream)
VLAN
tagging
filter
MAC bridge
port config
data
PQ A1
GEM IW TP
(downstream
broadcast)
Traffic
descriptor
(downstream)
MAC bridge
port config
data
Multicast
GEM IW TP
Priority queue
1 (upstream)
T-CONT
T-CONT
Priority queue
4 (upstream)
PQ Ay
GEM port
network
CTP
T-CONT
null
PQ Ax
GEM port
network
CTP
null
G.988(12)_FII.1.3.1.1-1
Figure II.1.3.1.1-1 L2-OCM with multicast

II.1.3.1.1.1
Provisioning considerations
Both GEM port network CTP MEs are provisioned with the following considerations:
The direction attribute should be set to 2, indicating that the associated GEM port is
unidirectional downstream.
The T-CONT pointer attribute is not meaningful.
The traffic management pointer for the upstream attribute is not meaningful.
The traffic descriptor profile pointer for the upstream attribute is not meaningful.
Rec. ITU-T G.988 (10/2012)
555
The priority queue pointer for the downstream attribute is used as a template for all UNIs
that subscribe to this GEM port. Specifically, if this attribute points to priority queue 1 for
UNI N, then it implicitly refers to priority queue 1 for all affected UNIs.
The multicast GEM interworking TP ME is provisioned with the following considerations:
The interworking option attribute should be set to zero, indicating a "don't care".
The service profile pointer attribute is set to zero and not used.
The interworking termination point pointer attribute is set to zero and not used.
The PPTP counter attribute is set to 0xFF and not used.
The GAL profile pointer and GAL loopback configuration attributes are set to zero and not
used.
The GEM interworking TP ME that is used for incidental broadcast is provisioned with the
following considerations:
The interworking option attribute should be set to 6 to indicate broadcast.
The service profile pointer attribute should be set to zero.
The interworking termination point pointer attribute should be set to zero.
The GAL profile pointer attribute should be set to zero.
The GAL loopback configuration attribute should be ignored.

II.1.3.1.1.2
Message flows
Figure II.1.3.1.1.2-1 shows the message flow used to add multicast or incidental broadcast to the
model.
OLT
ONU
Create response
Once per
GEM port instance
Create (GEM interworking TP or multicast GEM interworking TP)

Create response
Create response
Once per bridge

Create response
OLT
ONU
Create response
Create response
Once per bridge

Create response
Create (GEM interworking TP)
Or multicast GEM
interworking TP
Create response
G.988(12)_FII.1.3.1.1.2-1
Figure II.1.3.1.1.2-1 Data plane provisioning
556
Rec. ITU-T G.988 (10/2012)
II.1.3.1.2 Multiple UNI OMCI provisioning model

Figure II.1.3.1.2-1 is the relationship diagram for multicast and incidental broadcast in an ONU
with multiple UNIs. The only notable difference between this diagram and the model of
Figure II.1.3.1.1-1 is that the multicast GEM port and the incidental broadcast GEM port are
associated with multiple bridges, thereby sharing a single multicast or broadcast flow across
multiple UNIs.
The operation of the model is functionally identical to that described in clause II.1.3.1.1.
Rec. ITU-T G.988 (10/2012)
557
Traffic
descriptor
(downstream)
Multicast
operations
profile
Ext VLAN
tag
operation
config data
Priority queue
A1
(downstream)
Multicast
subscriber
config info
Priority queue
A2
(downstream)
PPTP
Ethernet
UNI
Priority queue
A3
(downstream)
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
MAC bridge
port config
data
MAC bridge
port config
data
Traffic
descriptor
(downstream)
UNI-G
GEM
interworking
TP
MAC bridge
port config
data
VLAN
tagging
filter
MAC bridge
port config
data
Traffic
descriptor
(downstream)
MAC bridge
port config
data
Multicast
GEM IW TP
VLAN
tagging
filter
Ext VLAN
tag
operation
config data
VLAN
tagging
filter
Priority queue
B1
(downstream)
PPTP
Ethernet
UNI
Priority queue
B3
(downstream)
Traffic
descriptor
(downstream)
GEM
interworking
TP
802.1p
mapper
service
profile
Priority queue
B2
(downstream)
MAC bridge
port config
data
MAC bridge
port config
data
GEM
interworking
TP
Traffic
descriptor
(downstream)
UNI-G
Priority queue
B4
(downstream)
Multicast
subscriber
config info
Multicast
operations
profile
MAC bridge
port config
data
GEM
interworking
TP
802.1p
mapper
service
profile
VLAN
tagging
filter
Traffic
descriptor
(downstream)
GEM
interworking
TP
Rec. ITU-T G.988 (10/2012)
Traffic
descriptor
(upstream)
T-CONT
PQ 2
Traffic
descriptor
(upstream)
PQ 3
Priority queue
2 (upstream)
T-CONT
Traffic
descriptor
(upstream)
Priority queue
3 (upstream)
PQ 4
Priority queue
4 (upstream)
null
GEM port
network
CTP
null
PQ B1
Traffic
descriptor
(upstream)
PQ 1
PQ B2
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 2
PQ B3
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 3
PQ B4
Traffic
descriptor
(upstream)
GEM port
network
CTP
PQ 4
Figure II.1.3.1.2-1 Multi-UNI L2-OCM with multicast
558
Priority queue
1 (upstream)
PQ Ax
GEM port
network
CTP
Traffic
descriptor
(downstream)
MAC bridge
service
profile
PQ 1
T-CONT
PQ Ay
GEM port
network
CTP
Traffic
descriptor
(downstream)
MAC bridge
port config
data
Traffic
descriptor
(upstream)
T-CONT
GEM IW TP
(downstream
broadcast)
MAC bridge
port config
data
PQ A4
GEM port
network
CTP
GEM
interworking
TP
VLAN
tagging
filter
PQ A3
GEM port
network
CTP
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
PQ A2
GEM port
network
CTP
GEM
interworking
TP
MAC bridge
service
profile
Priority queue
A4
(downstream)
GEM port
network
CTP
GEM
interworking
TP
VLAN
tagging
filter
PQ A1
G.988(12)_FII.1.3.1.2-1
II.1.3.2
Control plane
Implementation of traditional multicast services also requires support for IGMP on the control
plane. The multicast subscriber config info ME and the multicast operations profile ME are used to
provision this support. As shown in Figure II.1.3.1.1-1, these MEs are associated with the MAC
bridge port config data ME on the UNI side of the OMCI model. The following considerations
should be used when provisioning these MEs:
Permitting multicast on a subscriber UNI does not require the existence of a multicast
subscriber config info ME. The default action for a bridge port and associated UNI is to
allow the forwarding of frames in the multicast address range. If desired, the blocking of
frames in the multicast address range is achieved through the use of the MAC bridge port
filter table data ME or MAC bridge port filter pre-assign table ME.
The dynamic access control list table and static access control list table attributes of the
multicast operations profile ME include fields for GEM port and VLAN. These should be
provisioned consistently with the multicast flow through its GEM port network CTP and
possible VLAN tagging filters. The consequence of inconsistent provisioning is undefined.
The ME type attribute of the multicast subscriber config info ME should be set to zero to
indicate an association with a MAC bridge port config data ME.
The IGMP version attribute of the multicast operations profile ME should be set to 3 to
indicate that the ONU will be using IGMP v3, as required by [b-BBF TR-156].
A bandwidth-based multicast service level agreement (SLA) can be implemented using the
max multicast bandwidth and bandwidth enforcement attributes in the multicast subscriber
config info ME in conjunction with the imputed group bandwidth field of the dynamic
access control list table in the multicast operations profile ME.
Support of multicast preview or paid preview functions also requires configuration in the control
plane. The multicast subscriber config info ME is used to provision this support, including the
forwarding of preview groups to UNIs when allowed, and otherwise blocking them.
II.2
Dual-managed ONUs
In many cases, the ONU is physically separated from the equipment connected at the ultimate UNI,
and the ONU is managed via the OMCI, while the UNI equipment is managed by other means. For
example, the ONU may be connected to an RG via an Ethernet or xDSL interface, with the ONU
managed by the OMCI and the RG managed by [BBF TR-069]. As another example, the ONU in a
PON-fed digital subscriber line access multiplexer (DSLAM) may be connected to the DSLAM via
an Ethernet interface, with the ONU managed by the OMCI and the DSLAM managed by the
SNMP. In these examples, the demarcation point between the two management domains is clear: it
is the Ethernet interface.
However, there are cases where the ONU and the UNI equipment are physically integrated into the
same device, and there may not be a physical interface between the two. A dual-managed ONU is
defined as two management domains that may control the same physical device. The virtual
Ethernet interface point (VEIP) ME is the data plane demarcation point between the two
management domains, with the OMCI managing everything from the virtual Ethernet interface
point to the ANI. The management protocol on the other side is not specified.
Rec. ITU-T G.988 (10/2012)
559
Generic
status
portal
Priority queue
A1
(downstream)
Traffic
descriptor
(downstream)
Multicast
operations
profile
Virtual
Ethernet
interface pt
Priority queue
A3
(downstream)
MAC bridge
port config
data
MAC bridge
port config
data
GEM
interworking
TP
GEM
interworking
TP
MAC bridge
port config
data
Priority queue
A4
(downstream)
MAC bridge
port config
data
MAC bridge
port config
data
MAC bridge
port config
data
PQ 1
T-CONT
Priority queue
1 (upstream)
Traffic
descriptor
(upstream)
T-CONT
PQ 2
Traffic
descriptor
(upstream)
PQ 3
Traffic
descriptor
(upstream)
Priority queue
2 (upstream)
T-CONT
Priority queue
3 (upstream)
PQ 4
Traffic
descriptor
(downstream)
PQ Ay
GEM port
network
CTP
GEM IW TP
(incidental
mcast)
Multicast
GEM IW TP
null
Priority queue
4 (upstream)
PQ Ax
GEM port
network
CTP
null
Traffic
descriptor
(upstream)
MAC bridge
service
profile
IP host
config data
Traffic
descriptor
(upstream)
T-CONT
Traffic
descriptor
(downstream)
TCP/UDP
config data
PQ A4
GEM port
network
CTP
GEM
interworking
TP
VLAN
tagging
filter
PQ A3
GEM port
network
CTP
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
PQ A2
GEM port
network
CTP
Traffic
descriptor
(downstream)
VLAN
tagging
filter
MAC bridge
service
profile
UNI-G
Traffic
descriptor
(downstream)
802.1p
mapper
service
profile
Multicast
subscriber
config info
Priority queue
A2
(downstream)
GEM port
network
CTP
GEM
interworking
TP
VLAN
tagging
filter
Ext VLAN
tag
operation
config data
PQ A1
MAC bridge
port config
data
GEM
interworking
TP
GEM port
network
CTP
PQ n
G.988(12)_FII.2-1
Figure II.2-1 Dual-managed ONU model

Figure II.2-1 shows an OMCI model for a dual-managed ONU/RG, which is an extension of the
layer 2 service in clause II.1. There are several important features of this model:
1)
As with a physical Ethernet, multiple traffic classes can flow across the virtual Ethernet
interface, and each traffic class has an associated priority queue. One implication of this is
that extra work may be involved to multiplex/de-multiplex data on both sides of the VEIP.
For example, in the upstream direction, the RG conceptually separates traffic by class for
queueing and scheduling, then merges all classes into a single stream to pass through the
VEIP; the ONU again separates traffic by class to direct to the appropriate upstream queue.
2)
The same number of virtual Ethernet interfaces are used as there would be physical
Ethernet interfaces between the OMCI domain and the non-OMCI domain if the domains
560
Rec. ITU-T G.988 (10/2012)
3)
4)
5)
6)
7)
existed on separate devices. For example, there is typically one virtual Ethernet interface
per RG.
The virtual Ethernet interface represents the termination of the ONU data plane, whereas
the associated IP host config data ME (IPHC) represents the termination of the ONU
management plane. The IPHC is the container for the IP address, mask, gateway and DNS
information in the OMCI domain, and in the dual-managed ONU, it may also be used to
establish or determine the same information in the non-OMCI domain. For a detailed
discussion of IPHC provisioning, refer to clause II.4.
The IPHC is conditionally required for the dual-managed ONU, depending on the IP stack
configuration in the integrated device. Three configurations are possible:
a) Dual stack, where each management domain contains a unique IP stack. An IPHC is
present for OMCI use if the ONU supports native IP-based services such as VoIP or IP
pseudo-wire. A separate IPHC exists for the non-OMCI management domain if IP
connectivity is to be provided by the OMCI.
b) Single stack, shared between the two domains. An IPHC exists if either the OMCI
domain provides native IP-based services or if the non-OMCI domain requires the
OMCI to set up its IP connectivity.
c) A single stack, used only by the non-OMCI domain. This case requires an IPHC only if
the non-OMCI domain needs the OMCI to establish its IP connectivity.
The presence of the virtual Ethernet interface ME provides an unambiguous way for the
ONU to represent its nature to the OLT during the OMCI MIB discovery process.
Not more than one generic status portal (GSP) may be created by the OLT per VEIP. The
generic status portal provides a way for the OLT to discover the status and configuration
information of a non-OMCI management domain within an ONU. This ME contains two
table attributes: status document table and configuration document table. The OLT reads
these tables to obtain an XML representation of the non-OMCI management domain status
and configuration. Whenever the text in this table changes, and after a soak interval, the
ONU issues an AVC to the OLT. The rate at which AVCs are issued is controlled by the
AVC rate control attribute.
The ONU automatically creates a UNI-G for each VEIP.
The ONU automatically creates physical ports (PPTPs) and their associated UNI-Gs that
are visible and manageable only via the OMCI. As an option, the ONU may also create
PPTP/UNI-G pairs that are either dedicated to a non-OMCI domain or that may flexibly be
assigned to either management domain by the OLT. If the ONU does not automatically
create such MEs, they must be created by other means, which lie beyond the scope of this
Recommendation. The OLT cannot create them via the OMCI.
The capability of the UNI-G/PPTP is advertised by the ONU in the management capability
attribute of the UNI-G ME. If a UNI-G/PPTP is assignable to a specific domain, the OLT
can set the UNI-G non-OMCI management identifier to assign the PPTP/UNI-G to a
non-OMCI domain.
The dual-managed ONU OMCI data plane model is provisioned in the same way as exemplified in
clause II.1.2.
Rec. ITU-T G.988 (10/2012)
561
II.3
Traffic management
II.3.1
Requirements and techniques
II.3.1.1
Introduction
G-PON contains a number of features related to QoS, such as policing, shaping, queueing and
scheduling. These features can be applied to a variety of different QoS architectures such as
diffserv, metro Ethernet and [b-BBF TR-101]. This clause exemplifies how to map G-PON QoS
features to diffserv or metro Ethernet services.
II.3.1.2
Diffserv over G-PON
[b-IETF RFC 2475] outlines the diffserv, or differentiated services, model for providing QoS
(quality of service). The diffserv model specifies that traffic is classified and conditioned (metered,
shaped, policed and/or re-marked) at the edge of the QoS domain and then queued and scheduled
for forwarding at each node in the interior of the QoS domain based on the per-hop behaviour of the
class. This relative QoS on a per-hop basis instead of a network-wide basis is a fundamental
property of the diffserv model.
[b-IETF RFC 2475] defines the basic framework for diffserv; additional RFCs define the behaviour
of the most commonly used traffic classes, expedited forwarding (EF) in [IETF RFC 3246] and
[b-IETF RFC 3247], and assured forwarding (AF) in [IETF RFC 2597].
AF includes the concept of drop precedence, by which traffic can be admitted and marked in such a
way that traffic will be dropped in a prescribed precedence within a class when congestion occurs.
AF defines four classes, each with three drop precedence levels. With AF, it is important that
packets within a class not be reordered.
To implement diffserv, traffic must be classified and policed/marked at the ingress and egress of the
QoS domain. A marker function that can be used for diffserv is specified in [b-IETF RFC 4115], the
two-rate three colour marker system (trTCM). The trTCM marker function has two associated rates,
the committed information rate (CIR) and the excess information rate (EIR).A dual token bucket
algorithm is used for this colour marking. If the packet length is less than the number of tokens in
the committed token bucket, the packet is declared green; else if the packet length is less than the
number of tokens in the excess token bucket, the packet is declared yellow; otherwise, the packet is
declared red. These three colours are mapped to the three drop precedences as an example, green
traffic could be marked with drop precedence 1, with yellow traffic marked with either drop
precedence 2 or 3. During times of congestion, the ONU drops yellow packets with a higher
probability than green packets. In G-PON, the peak information rate (PIR) is equal to the sum of the
CIR and EIR.
EF is intended for constructing low-latency and low-loss services, in that it is assumed that packets
marked with the EF class can pre-empt other traffic within limits. EF can be implemented with a
simple priority queue, where the output of the EF priority queue is given priority over other queues,
but where the input to the EF priority queue is governed by a token bucket to prevent starvation of
the other queues. As with AF, it is important that EF class packets not be reordered.
Assuming the domain edge is the ONU, each diffserv CoS (class of service) should be assigned its
own T-CONT. In this way, the OLT can schedule grants to provide fair access to the shared G-PON
bandwidth. For a given ONU, flows from different users but within the same CoS should be policed
separately and then placed in the same queue. OLTs should assign bandwidth using the extended
bandwidth assignment model for DBA as described in [ITU-T G.984.3] and [ITU-T G.987.3].
T-CONTs containing flows from the same class but from different ONUs should be assigned the
same priority at the OLT, but should be assigned weights proportional to the cumulative data rate of
those flows.
562
Rec. ITU-T G.988 (10/2012)
Figure II.3.1.2-1 shows an example of the distribution of upstream functionality between the ONU
and the OLT for a diffserv architecture.
i
Pi
Network
facing side
1
WFQ
sched
T-CONT A
Other
ONUs
(EF)
GEM
ports
User facing side

Mark/police
Mark/police
Mark/police
Strict
priority
sched
2
OLT ONU
T-CONT B
Mark/police
WFQ
sched
User 1 (EF)
...
User N (EF)
User 1 (AF3)
...
User N (AF3)
T-CONT C
Other
ONUs
(AF)
Mark/police
Mark/police
User 1 (AF2)
Tag/
classify
/map
User 1
...
User N
...
User N (AF2)
T-CONT D
3
WFQ
sched
Mark/police
Other
ONUs
(BE)
Mark/police
User 1 (BE)
...
User N (BE)
G.988(12)_FII.3.1.2-1
NOTE 1 WFQ weights should be configurable.

NOTE 2 WFQ and strict scheduling implemented with extended bandwidth assignment DBA.
Figure II.3.1.2-1 Block diagram example of diffserv upstream QoS for G-PON
The L2-OCM provisioning model defined in clause II.1 supports diffserv. In this model, the traffic
descriptor ME is used to specify the treatment of each traffic class in the ONU. The following
considerations should be used when provisioning the traffic descriptor:
For EF traffic, the CIR and PIR attributes should be set to the CIR of the EF traffic profile.
For AF traffic, the CIR attribute should be set to the CIR of the AF traffic profile. The PIR
attribute should be set to the sum of the CIR and EIR of the AF traffic profile.
For BE traffic, the CIR attribute should be set to the CIR of the BE traffic. The PIR
attribute should be set to the sum of the CIR and EIR of the BE traffic profile.
The colour mode attribute should be set to 1 to indicate a colour aware traffic flow.
The ingress colour marking and egress colour marking attributes should be set to 7 to
indicate DSCP AF drop precedence marking.
II.3.1.3
Metro Ethernet over G-PON
[b-MEF 10.2] describes an Ethernet virtual service (EVS), which is a layer 2 connection between
customer edge devices. In the MEF model, the edge of the QoS domain is defined at the ONU UNI,
where the marking/policing function is carried out. [b-MEF 10.2] does not define any specific perhop behaviour. Instead, it focuses on end-to-end service level specifications in terms of delay, delay
variation and packet delivery ratio. In this architecture, it is assumed that the UNI is a customerfacing [IEEE 802.3] (Ethernet) interface on the ONU.
The traffic management defined by [b-MEF 10.2] employs a two-rate, three-colour policer, which is
identical to [b-IETF RFC 4115] if the MEF 10.2 variable CF is set to 0. The two rates are CIR and
EIR (excess information rate), and are defined for both ingress frames and egress frames. If the
frame (ingress or egress) length is less than the number of tokens in the committed token bucket, the
frame is declared green; else if the frame length is less than the number of tokens in the excess
Rec. ITU-T G.988 (10/2012)
563
token bucket, the frame is declared yellow; otherwise, the frame is declared red. This policing takes
place at the UNI.
According to [b-MEF 10.2], traffic marked green is to be delivered according to the service level
specification, traffic marked yellow may be delivered, but is not bound to the service level
specification, and traffic marked red is to be dropped.
[b-MEF 10.2] does not specify the means by which an Ethernet virtual connection (EVC) is
designated within a service provider's network. However, this appendix recommends using
[IEEE 802.1ad] double VLAN tags: C tags for customer use and S tags for service provider use.
At the UNI, a VLAN S-tag is added to or translated on ingress frames (from the customer) and P
bits are set appropriately. The S tag is removed or translated from egress frames (towards the
customer). The mapping to S tags should be one per EVC.
II.3.1.3.1 Provisioning considerations
Each S-tag P-bit value (class of service) should be assigned its own T-CONT. In this way, the OLT
can schedule grants to provide fair access to the shared G-PON bandwidth. For a given ONU, flows
from different users but within the same class of service should be policed separately and then
placed in the same queue. OLTs should assign bandwidth using the extended bandwidth assignment
model for DBA ([ITU-T G.984.3] and [ITU-T G.987.3]). At the OLT, T-CONTs containing flows
from the same class but from different ONUs should be assigned the same priority, but should be
assigned weights proportional to the cumulative data rate of those flows.
The DEI bit should indicate that yellow frames are eligible for discard. Red frames should be
dropped in the ONU and never forwarded to the OLT. It is important that frames not be reordered.
Therefore, all traffic for a given CoS (both green and yellow) must be kept in a single logical queue.
During times of congestion, the ONU will drop yellow packets with a higher probability than green
packets.
The L2-OCM provisioning model defined in clause II.1 supports [b-MEF 10.2]. In this model, the
traffic descriptor ME is used to describe the behaviour of each traffic class in the ONU. The
following considerations should be used when provisioning the traffic descriptor:
For each EVC, the CIR and PIR attributes should be set to the appropriate values for that
EVC.
The colour mode attribute should be set to 1 to indicate a colour-aware traffic flow.
The ingress colour marking and egress colour marking attributes should be set to 2 to
indicate DEI drop precedence marking.
II.3.2
Traffic management in [b-BBF TR-156]
This clause is a high-level mapping from the traffic management text of [b-BBF TR-156] to the
OMCI. In this clause, numbers in brackets (e.g., [R-x]) indicate the corresponding requirement
number in [b-BBF TR-156].
NOTE 1 The [b-BBF TR-156] text is paraphrased in this clause. In case of inconsistencies between this
clause and [b-BBF TR-156], [b-BBF TR-156 ]takes precedence.
NOTE 2 The details in [b-BBF TR-156] refer to [ITU-T G.984.x]. The same requirements largely pertain
to ITU-T G.987 systems.
In this clause, traffic management is defined to comprise the following components: 1) traffic
classification, 2) rate limiting, 3) queueing, 4) scheduling and 5) T-CONT assignment.
[b-BBF TR-156] assumes that there will always be a broadband network gateway (BNG) and
possibly an Ethernet aggregation node on the network side of an OLT, and a residential gateway
(RG) on the user side of an ONU. Although the models are similar, this clause does not consider
G-PON-fed DSLAMs.
564
Rec. ITU-T G.988 (10/2012)
The high-level architectural view considered in this clause is given in Figure II.3.2-1 (from
[b-BBF TR-156]). The OLT and ONU are regarded as a distributed access node. It is possible for
the ONU and RG to be integrated.
NSP1
/BNG
Ethernet
NSP2
L2TP
NSP3
ASP1
Regional
broadband network
Access network
L2TS
Access node
IP QoS
IP
BNG
Eth
agg
OLT
User1
ODN
ONU
IP QoS
V
A10
S/R
RG
U
R/S
User2
Customer prem network

RAN
G.988(12)_FII.3.2-1
Figure II.3.2-1 High-level architecture

II.3.2.1
Traffic classification
Downstream, GEM ports are used to differentiate between traffic classes for a particular user port.
Each GEM port identifies a specific traffic class going to a specific UNI on a specific ONU.
Therefore, a given GEM port carries no more than one traffic class [R-6, R-7].
In the upstream direction, the ONU must support deriving VLAN priority (P-bit) markings based on
the user port, VID, received P-bits and Ethertype [R-48], and the ONU should support deriving P
bits based on user port, VID and received DSCP value [R-49]. The ONU must support mapping
traffic flows into GEM ports based on the user port, VLAN ID or VLAN priority [R-51].
The OLT and ONU must support at least four traffic classes [R-46], and should support at least six
[R-47].
II.3.2.2
Rate limiting
The ONU and OLT must support rate limiting of IGMP messages received from user ports on a
multicast VLAN [R-87].
The ONU and OLT must support rate limiting of CFM (connectivity fault management) Ethernet
OAM messages arriving on a user port; the rate must be configurable per port [b-BBF TR-101]
[R-268]. CFM provisioning is symmetric: the expected message receive rate is equal to the message
transmit rate. High message rates may interfere with traffic or overload the ONU processor and are
to be used judiciously.
II.3.2.3
Queueing
During periods of queue congestion, the ONU and OLT must be capable of dropping (not queueing)
packets marked as drop eligible, with a probability higher than that of packets not marked as drop
eligible. Drop eligibility (drop precedence) can be indicated either by VLAN priority bits [R-54], or
by the DEI bit (802.1ad) [R-55]. These packets may have drop eligibility marked externally (e.g.,
by the BNG or RG).
The OLT must support one downstream queue per traffic class per PON, and at least four traffic
classes [R-58]. Likewise, the OLT must provide one upstream queue per network-facing port for
each of at least four traffic classes [R-66]. The OLT should support six traffic classes in each
direction [R-62], [R-68].
Rec. ITU-T G.988 (10/2012)
565
The ONU must support a downstream queue per user-facing port for each of at least four traffic
classes [R-56]. The ONU must provide an upstream queue for each of at least four traffic classes
[R-57]. The ONU should support at least six traffic classes [R-60], [R-61].
The OLT must and the ONU should support setting the maximum size/depth of all queues [R-73].
II.3.2.4
Scheduling
At a minimum, [b-BBF TR-156] requires strict priority scheduling among queues. In the
downstream direction, the OLT must support strict priority scheduling among at least four queues
for each PON [R-63], and the ONU must support strict priority scheduling among at least four
queues for each user-facing port [R-63]. In the upstream direction, the OLT must support strict
priority scheduling among at least four queues for each network-facing port [R-70].
Weighted scheduling among queues is an objective. The OLT and ONU should support scheduling
of queues according to their assigned priority and weight, with the following conditions: 1) multiple
queues may be assigned to the same priority, 2) queues assigned the same priority must be
scheduled according to a weighted algorithm, and 3) weights must be assigned through provisioning
[R-65], [R-72]. Non-empty queues at the same priority receive capacity in proportion to their
weights.
The OLT must support the basic traffic descriptor parameters RF, RA, RM, and AB as specified in
[ITU-T G.984.3] [R-44]. The OLT must support the extended traffic descriptor parameters Pi and i
as specified in [ITU-T G.984.3] [R-45], which are used to implement the strict priority and
weighted scheduling of T-CONTs. These parameters must be configurable [R-44], [R-45]. The
OLT must support T-CONT types 1, 2, 3 and 4 [R-59].
NOTE T-CONT type numbering is purely a documentation convenience. In actual use, the T-CONT type
is not represented by any provisioned attribute on the PON.
The ONU-G ME must at least support traffic management option 0 (priority controlled).
II.3.2.5
T-CONT support
By providing a T-CONT for each traffic class, the ONU must support four upstream traffic classes
[R-67], and should support six [R-69].
II.3.2.6
OMCI model
The following OMCI MEs and attributes support the functionality of this clause:
Priority queue
Related port: For upstream, the first two bytes point to the associated T-CONT, and the last
two bytes are "don't care" ([b-BBF TR-156] specifies only one priority queue for each
T-CONT, which performs no scheduling). For downstream, the first two bytes point to the
slot and port of the specific downstream port, and the last two bytes indicate the strict
priority associated with this priority queue.
Traffic scheduler pointer: Set to the default null pointer.
Weight: For upstream, this attribute should remain at the default value of 1 ([b-BBF
TR-156] specifies only one priority queue for each T-CONT, which performs no
scheduling). For downstream, this attribute should be set to the weight associated with this
priority queue, or set to 1 if weighted scheduling is not used.
Packet drop queue thresholds: These are used to implement the BBF TR-156 drop
eligibility (drop precedence) requirements.
Packet drop max_p
566
Queue drop w_q

Drop precedence colour marking: Must be set either to one of the PCP modes or to DEI.
Rec. ITU-T G.988 (10/2012)
ONU-G
Traffic management option: Read-only, defined by the ONU architecture. 0 indicates

priority-controlled mode. Even if the value is 2, indicating the ability to perform in either
priority or rate-controlled mode, [b-BBF TR-156] uses only the priority-controlled mode.
T-CONT
Policy: This value is a "care." [b-BBF TR-156] specifies only one priority queue for each
T-CONT, which performs no scheduling.
Figures II.3.2.6-1 and II.3.2.6-2 give examples of the downstream and upstream traffic management
functionality.
OLT
ONU-1
PON 1
S/R
UNI 1
U
R/S
Scheduler
Scheduler
Assign to
queues
according
to GEM port
Classifier
UNI n
(same as above)
PON n
(same as above)
ONU n
(same as above)
G.988(12)_FII.3.2.6-1
Figure II.3.2.6-1 Downstream functionality example
Rec. ITU-T G.988 (10/2012)
567
OLT
PON 1
ONU-1
S/R
R/S
T-CONT A
T-CONT B
V
Classifier
T-CONT C
Scheduler
T-CONT D
Classifier
PON n
(same as
above)
ONU n
(same as above)
G.988(12)_FII.3.2.6-2
Figure II.3.2.6-2 Upstream functionality example

II.3.3
Beyond [b-BBF TR-156]
There are non-BBF TR-156 applications where it is desirable to have multiple queues per T-CONT
and to have scheduling between these queues. One example would be the MDU (multiple dwelling
unit) ONU, where there are multiple UNIs, each of which serves a different subscriber. The service
provider may wish to configure the ONU such that no single UNI within the ONU consumes more
than its fair share of the bandwidth assigned to a given traffic class. This could be done for a given
traffic class by giving each UNI a separate queue, then using some form of weighted scheduling
(like WRR, weighted round robin) to schedule traffic from the queues into the T-CONT for that
traffic class.
Another example would be where the service provider assigns a VLAN to a T-CONT, but wishes to
give a different priority to different flows within that T-CONT. This could be done by mapping
specific P-bit values within that VLAN to different queues, then using strict priority to schedule
traffic from the queues into the T-CONT for that VLAN. As a specific example, P-bits value 1
could be mapped to one queue, P-bits value 3 could be mapped to another queue, and strict priority
could be used to schedule between the two queues. From the OLT's point of view, all traffic in this
T-CONT would be a single traffic class that could be governed by a VLAN-level SLA.
This clause describes the best practice for implementing scheduling among multiple queues
associated with a given T-CONT. Only a single level of scheduling is considered; hierarchical
scheduling is not considered. The clause considers only two scheduling disciplines for each
multi-queue T-CONT:
1)
Strict priority scheduling: The queues are served in the specified priority order. This
corresponds to the strict priority value of the scheduling policy attribute.
2)
Weighted scheduling: Back-logged (non-empty) queues are served in proportion to their
specified weights. This corresponds to the WRR value of the scheduling policy attribute.
Prior to 2009, the OMCI specified a fixed set of priority queue MEs and traffic scheduler MEs
associated with each T-CONT ME, assuming these resources were fixed in the ONU's architecture.
In 2009, a flexible means of mapping between queues, schedulers and T-CONTs was added,
allowing a pool of queues to be attached to any scheduler and T-CONT in the same slot. The first
568
Rec. ITU-T G.988 (10/2012)
part of this clause describes the best practice for using the fixed method. The second part of this
clause describes the flexible alternative.
For legacy reasons, the fixed method is the default the ONU must have a factory default
configuration of queues/schedulers/T-CONTs that would be usable by an OLT that only supports
the fixed method, and the OLT must work with ONUs that only support the fixed method. The
flexible method is considered an extension of the fixed method, and may be used when supported
by both the ONU (as indicated by the QoS configuration flexibility attribute in the ONU2-G ME)
and the OLT.
II.3.3.1
Default practice Fixed queue/scheduler/T-CONT
The default ONU architecture assumes a fixed set of priority queue MEs and traffic scheduler MEs
associated with each T-CONT ME. The pointers between traffic scheduler MEs and T-CONT MEs
are fixed, but the priority queue MEs can be provisioned to point either to the associated T-CONT
or to one of the associated traffic schedulers. The scheduling policy of each T-CONT ME and each
traffic scheduler ME is fixed. It is not assumed that all T-CONTs have the same number of priority
queue MEs and traffic scheduler MEs. The OLT must determine the ONU's queue configuration
and connect the GEM port network CTP MEs accordingly.
Not all T-CONTs in an ONU must support these scheduling capabilities. However, in order to be
interoperable, any T-CONT that supports the scheduling capabilities of this clause must have at
least two priority queue MEs and one of the two following configurations:
1)
Traffic scheduler not present: Only a single scheduling discipline is supported, as
determined by the T-CONT policy attribute. The priority queue MEs are connected directly
to the T-CONT ME.
2)
Traffic scheduler present: The traffic scheduler ME and T-CONT ME must have opposite
policy attributes, meaning that one has the strict priority policy and the other has WRR.
Both scheduling disciplines are therefore supported. Priority queue MEs can be connected
to either the traffic scheduler ME or directly to the T-CONT ME to determine the
scheduling discipline.
Furthermore, to be interoperable, the read-only parameter values described in the following clauses
are required.
II.3.3.1.1 ONU provisioning considerations
The MEs used in this clause for traffic scheduling are the priority queue, traffic scheduler and
T-CONT.
Figure II.3.3.1.1-1 shows an example of a T-CONT with three queues and no traffic scheduler. Each
queue is directly connected to the T-CONT ME. The scheduling discipline is determined from the
policy attribute of the T-CONT ME, in this case weighted (policy = WRR).
Rec. ITU-T G.988 (10/2012)
569
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
T-CONT
(WRR)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
G.988(12)_FII.3.3.1.1-1
Figure II.3.3.1.1-1 Example of weighted scheduling with three queues per T-CONT
and no traffic scheduler, queues connected directly to T-CONT
Figure II.3.3.1.1-2 shows an example of a T-CONT with four queues and a traffic scheduler.
Because each queue is connected to the traffic scheduler, the scheduling discipline is determined
from the policy attribute of the traffic scheduler ME, in this case weighted (policy = WRR).
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Traffic
scheduler
(WRR)
T-CONT
(HOL)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
GEM port
network CTP
Priority
queue
G.988(12)_FII.3.3.1.1-2
Figure II.3.3.1.1-2 Example of weighted scheduling with four queues per T-CONT
and traffic scheduler, queues connected to traffic scheduler
Figure II.3.3.1.1-3 shows an example of a T-CONT with four queues and a traffic scheduler ME.
Because each queue is directly connected to the T-CONT ME, the scheduling discipline is
determined from the policy attribute of the T-CONT ME, in this case strict priority.
570
Rec. ITU-T G.988 (10/2012)
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Traffic
scheduler
(WRR)
T-CONT
(HOL)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
GEM port
network CTP
Priority
queue
G.988(12)_FII.3.3.1.1-3
NOTE The traffic scheduler performs no function in this example. It is shown to illustrate components that may be present as
inbuilt features of the ONU architecture.
Figure II.3.3.1.1-3 Example of strict priority scheduling with four queues per T-CONT
and traffic scheduler, queues connected directly to T-CONT
Priority queue ME
Each priority queue ME has a fixed priority and a configurable weight. The OLT can configure
each priority queue ME to either point to the associated traffic scheduler ME or to point directly to
the associated T-CONT ME.
For an upstream queue, the related port attribute is read-only by default and is divided into two
parts: 1) the ME ID of the associated T-CONT, and 2) the priority of the queue. To support strict
priority scheduling between multiple queues associated with a T-CONT, each queue must have a
different priority.
The weight attribute is read-write, and is used to provide weighted scheduling between the queues
associated with a T-CONT. Non-empty queues at a given priority receive capacity in proportion to
their weights.
The traffic scheduler pointer attribute is read-write and is provisioned to either point to the
associated traffic scheduler ME (if present) or to the associated T-CONT ME (null pointer value).
The value of this attribute as a function of the desired scheduling discipline is shown in
Table II.3.3.1.1-1. During normal operation, either all priority queues associated with a T-CONT
should be mapped to the traffic scheduler ME (if present) or all should be mapped to the T-CONT
ME. During provisioning, there may be a temporary period where some of the priority queues
associated with a T-CONT are mapped to the traffic scheduler and some are mapped to the
T-CONT, in which case the ONU's behaviour is undefined.
The traffic scheduler pointer attribute value is a "don't care" for priority queues that are not in use,
i.e., that are not connected to GEM port network CTP MEs.
Rec. ITU-T G.988 (10/2012)
571
Table II.3.3.1.1-1 Value of priority queue traffic scheduler pointer attribute

to achieve desired scheduling discipline
Desired
scheduling
discipline
T-CONT
policy
Traffic scheduler
present?
Traffic scheduler
policy
Priority queue traffic

scheduler pointer
attribute
Strict
Strict priority
Don't care
Don't care
T-CONT (null)
Strict
WRR
Yes
Strict priority
Traffic scheduler
Weighted
WRR
Don't care
Don't care
T-CONT (null)
Weighted
Strict priority
Yes
WRR
Traffic scheduler
Traffic scheduler ME
By default, the traffic scheduler ME has a fixed scheduling policy and fixed pointers and a
configurable priority/weight. If the traffic scheduler is present, the following are its attribute
settings. Flexible configuration is discussed in clause II.3.3.2.
The T-CONT pointer attribute is read-only, and always points to the associated T-CONT.
The traffic scheduler pointer attribute is read-only and within the scope of this clause is
always null, because hierarchical scheduling is out of scope.
The policy attribute is read-only, and within the scope of this clause is always the
"opposite" of the T-CONT ME, i.e., one must be WRR and the other must be strict priority.
The priority/weight attribute is read-write, and within the scope of this clause its value is a
"don't care," with a suggested value of zero.
T-CONT ME
The policy attribute is read-only and is always either WRR or strict priority.
II.3.3.1.2 OLT provisioning considerations
In the default case, the OLT must learn the priority of each queue and the association between each
queue and a T-CONT priorities and associations cannot be provisioned. If it wishes to support the
policy option opposite to that built into the T-CONT itself, the OLT must determine whether a
traffic scheduler ME is associated with this T-CONT. The OLT must provision the ONU such that
the priority queue/traffic scheduler (if present)/T-CONT ME group is properly connected (via a
GEM interworking TP and GEM port network CTP) to the appropriate IEEE 802.1p mapper service
profile and MAC bridge port config data MEs, and that the queues are connected to the scheduler
providing the desired policy.
Strict priority scheduling
If the service requires strict priority scheduling between queues, the OLT must discover a T-CONT
ME that has a sufficient number of associated priority queue MEs and either supports the strict
priority scheduling policy itself or has a traffic scheduler ME that supports such a policy. For this
T-CONT, each required priority queue ME is connected, according to its read-only priority
attribute, to the GEM port network CTP associated with that priority. Each required priority queue
ME is also connected to the associated T-CONT ME or traffic scheduler ME with strict priority
policy, as shown in Table II.3.3.1.1-1. Any unused queues are left unconnected.
Weighted scheduling
If the service requires weighted scheduling between queues, then the OLT must discover a T-CONT
ME that has a sufficient number of associated priority queue MEs and either supports the WRR
scheduling policy itself or has a traffic scheduler ME that supports such a policy. For this T-CONT,
the OLT provisions the weight of each required priority queue ME. Each required priority queue
572
Rec. ITU-T G.988 (10/2012)
ME is connected to the GEM port network CTP associated with that weight. Each required priority
queue ME is connected to the associated T-CONT ME or traffic scheduler ME with WRR policy, as
shown in Table II.3.3.1.1-1. Any unused queues are left unconnected.
II.3.3.2
Alternative practice Flexible queue/scheduler/T-CONT
In this alternative method, the QoS configuration flexibility attribute in the ONU2-G ME allows
simplification of the provisioning of single-level scheduling. The queues are no longer fixed to a
particular T-CONT and set of traffic scheduler MEs, but rather can be flexibly associated with any
T-CONT or traffic scheduler ME in the same slot. Furthermore, the scheduling policy for the
T-CONT and traffic scheduler MEs is no longer fixed but can be modified during provisioning.
Finally, the priority of priority queues may be provisionable.
II.3.3.2.1 ONU provisioning considerations
The MEs used in this clause for traffic scheduling are the ONU2-G, priority queue and the
T-CONT. The traffic scheduler ME is not used.
Figure II.3.3.2.1-1 shows an example of a T-CONT with four flexible queues, each directly
connected to the T-CONT ME. As a function of the QoS configuration flexibility attribute in the
ONU2-G ME, these queues are assumed to be taken from a pool of queues with flexible pointers,
meaning they can point to any traffic scheduler or T-CONT ME in the same slot. The scheduling
discipline is selected from the policy attribute of the T-CONT ME, in this example, weighted
(policy = WRR).
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
T-CONT
(WRR)
Selectable policy
Priority
queue
GEM port
network CTP
Traffic
descriptor
(upstream)
GEM port
network CTP
Priority
queue
G.988(12)_FII.3.3.2.1-1
Pool of queues with

flexible pointers
Figure II.3.3.2.1-1 Example system of weighted scheduling with four flexible queues
ONU2-G ME
The QoS configuration flexibility attribute of the ONU2-G ME indicates whether the ONU supports
flexible priority queue and traffic scheduler pointers, flexible traffic scheduler and T-CONT
scheduling policies, or flexible queue priority. Specifically:
1)
If bit 1 is set, the priority queue ME may point to any T-CONT ME in the same slot.
2)
If bit 2 is set, the priority queue ME may point to any traffic scheduler ME in the same slot.
Rec. ITU-T G.988 (10/2012)
573
3)
4)
5)
6)
If bit 3 is set, the traffic scheduler ME can point to any T-CONT in the same slot.
If bit 4 is set, the traffic scheduler ME policy attribute is read-write.
If bit 5 is set, the T-CONT ME policy attribute is read-write.
If bit 6 is set, the priority queue ME priority field is read-write.
For the single-level scheduling in the rest of this clause, it is assumed that bits 1, 5 and 6 are set, and
bits 2, 3 and 4 are "don't care".
Priority queue ME
Each priority queue ME has a configurable priority and weight. The OLT can configure each
priority queue ME to point to any traffic scheduler ME or any T-CONT ME in the same slot.
The related port attribute is divided into two parts for upstream traffic: 1) the ME ID of the
associated T-CONT, which should be set to the desired T-CONT in a given slot; and 2) the priority
of the queue. To support strict priority scheduling between multiple queues, each queue must have a
different priority.
The weight attribute is read-write, and is used to provide weighted scheduling between the queues
associated with a T-CONT.
The traffic scheduler pointer attribute is read-write and is provisioned to either point to the
associated traffic scheduler ME or to the associated T-CONT ME (null pointer value). The value of
this attribute should be set to zero (null), indicating that this queue is mapped to the T-CONT
indicated by the related port attribute. During provisioning, there may be a temporary period where
some of the priority queues associated with a T-CONT are mapped to a traffic scheduler and some
are mapped to the T-CONT, in which case the ONU's behaviour is undefined. The traffic scheduler
pointer attribute value is a "don't care" for priority queues that are not in use, i.e., that are not
connected to GEM port network CTP MEs.
T-CONT ME
The policy attribute is read/write and must be either WRR or strict priority according to the required
service.
II.3.3.2.2 OLT provisioning considerations
The OLT selects the desired priority queue MEs from the pool, and connects them to the desired
T-CONT. It also sets the policy of this T-CONT to conform to the scheduling policy required by the
service. The OLT provisions the ONU such that the priority queue/T-CONT ME group is properly
connected (via a GEM interworking TP and GEM port network CTP) to the appropriate
IEEE 802.1p mapper service profile and MAC bridge port config data MEs.
Strict priority scheduling
If the service requires strict priority scheduling between queues, the OLT selects a T-CONT ME
and sets its policy attribute to strict priority. The OLT also selects the required number of priority
queues from the pool, and provisions each with a different priority. Each required priority queue
ME is connected to the GEM port network CTP associated with that priority. Each required priority
queue ME is also connected to the associated T-CONT ME. Any unused queues are left
unconnected.
Weighted scheduling
If the service requires weighted scheduling between queues, the OLT selects a T-CONT ME and
sets its policy attribute to WRR. The OLT also selects the required number of priority queues from
the pool, and provisions the weight of each required priority queue. Each required priority queue is
connected to the GEM port network CTP associated with that weight. Each priority queue ME is
also connected to the associated T-CONT ME. Any unused queues are left unconnected.
574
Rec. ITU-T G.988 (10/2012)
II.3.4
ONU architectural considerations
Depending on the trade-off between the complexity and the number of supported features, the ONU
can have various traffic management options. Examples of traffic management implementation in
the ONU are described in this clause. This clause also indicates how the MIB defined in clause 9 is
used for each implementation.
It should be pointed out that the ONU traffic management is not limited to these examples. ONU
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 affects the OMCI. In fact, it is difficult for the specification given in this Recommendation to
keep up with technological and feature innovations. It is envisioned that vendor-specific managed
entities will be needed to manage the traffic management related functions in the ONU.
II.3.4.1
Priority queue configuration
When the focus is on low complexity implementation, the ONU uses the priority-controlled
upstream traffic method. This configuration is used when the traffic management option attribute in
the ONU-G ME is 0 (priority controlled). In this case, the ONU has no traffic contract or QoS
awareness. The ONU is configured by the OLT with a priority for each connection for both
directions.
Theoretically, policing is needed at every multiplexing point, including the ONU. A system with the
policing function has to monitor the traffic volume entering the network from all active connections
to ensure that the agreed parameters are not violated and to deploy a frame discard or tag policy. In
the priority queue implementation, the policing function is moved to the OLT, where it protects the
core network. The PON is protected by the PON MAC via the DBA process. The PON MAC
manages all connections from a T-CONT as a whole. Essentially, the PON MAC isolates T-CONTs
from each other.
As such, CPEs sharing one T-CONT may have to regulate their own connection streams to maintain
quality. A CPE sending out more traffic on one connection will do so at the expense of other
connections established via the same T-CONT. In single-user ONUs, this may well be appropriate.
II.3.4.2
Explicit traffic scheduler configuration
In slightly more complex implementations, ONUs may implement some level of traffic scheduling
within each T-CONT. These are described using priority queues and one or more levels of traffic
scheduler MEs. The arrangement of priority queues and traffic schedulers is determined by the
ONU architecture, and is by default not controllable by the OLT. Flexible scheduler configuration is
one of the options that may be indicated by the ONU2-G managed entity.
Figure II.3.4.2-1 exemplifies one possible configuration of traffic schedulers. Two diffserv groups
are shown, each with all three classes of traffic. Within each group, two AF queues share weighted
access to upstream bandwidth. Traffic in each diffserv group is then strictly prioritized, and finally
offered to a weighted scheduler for arbitration across groups.
Rec. ITU-T G.988 (10/2012)
575
Figure II.3.4.2-1 Hierarchical scheduling example

II.3.4.3
Traffic descriptor configuration
An alternative method of controlling traffic in ONUs is to provide traffic descriptors to the ONU,
and leave the details of honouring and enforcing these contracts to the ONU implementation. This is
controlled using traffic descriptor MEs. This method makes the theoretical assumption that a
work-conserving scheduling methodology is used. In this configuration, traffic is shaped to conform
to PIR and PBS in the traffic descriptor ME. This configuration is used when the traffic
management option attribute in the ONU-G ME is 1 (rate controlled).
II.3.4.4
Priority and rate controlled configuration
Another method of controlling traffic in ONUs is to provide not only priority control with traffic
scheduling, but also traffic descriptors. This is controlled using traffic descriptor, priority queue and
traffic scheduler MEs. This method makes the theoretical assumption that a work-conserving
scheduling methodology is used. In this configuration, traffic is policed to conform to PIR and PBS,
and may be marked green or yellow according to CIR/CBS/PIR/PBS in the traffic descriptor ME.
This configuration is used when the traffic management option attribute in the ONU-G ME is 2
(priority and rate controlled).
[ITU-T G.987.1] requires that a multi-UNI ONU be able to serve some UNIs with strict priority and
others with rate-based control scheduling.
II.3.4.5
Flexible assignment
By default, priority queues and traffic schedulers are assigned to T-CONTs by the ONU
architecture in a fixed configuration, which may not be altered. It is also possible that the ONU
implements its QoS components in such a way that they may be flexibly reassigned (Note). ONU
flexibility is signalled to the OLT by means of the QoS configuration flexibility bit map attribute of
the ONU2-G managed entity.
NOTE Given the slot-port model of ONU equipment, which appears among other places in the managed
entity identifiers of T-CONT, physical path termination points, the traffic scheduler, and the related port
attribute of the priority queue managed entity, it is not anticipated that implementation flexibility would
extend across slots. Accordingly, the OMCI restricts flexibility to be only within a slot, and does not permit
flexible assignment across slots.
576
Rec. ITU-T G.988 (10/2012)
II.4
Voice services
Provisioning of native voice services on an ONU is accomplished through the use of a common set
of MEs along with the MEs specific to a particular VoIP signalling protocol. These MEs are
grouped as follows:
Common VoIP MEs

IP host config data
TCP/UDP config data
VoIP config data
VoIP voice CTP
VoIP media profile
RTP profile data
PPTP POTS UNI
SIP specific MEs

SIP user data
SIP agent data
VoIP app service profile
ITU-T H.248 specific MEs

MGC config data.
The OMCI VoIP MIB allows for one or multiple subscribers per SIP user agent (UA). It is also
possible to provision one or multiple UAs per IP address. The extended VLAN tagging operation
configuration data ME is used to provision layer 2 tag operations for a MAC bridge port config data
ME. If multiple UAs using the same IP address are provisioned, all such UAs must share the same
VLAN because there is a one-to-one relationship between a MAC bridge port config ME and an IP
host config data ME.
II.4.1
VoIP capability discovery
The OLT discovers support of VoIP capabilities by interrogating the ONU's MIB. Support of VoIP
in general is indicated by the existence of a VoIP config data ME. Further interrogation of attributes
contained in the VoIP config data ME will lead to the discovery of the specific signalling protocols
and provisioning methods supported by the ONU. The number of voice ports available on an ONU
is indicated by the number of PPTP POTS UNI MEs that exist.
II.4.2
VoIP common provisioning
The following considerations pertain to provisioning the common VoIP MEs:
IP host config data The ONU creates one IP host config data ME for each IP stack
instance. A single IP address is supported with each instance. The IP host config data ME
contains a group of IP parameter attributes (IP address, mask, etc.) that are set by the OLT
if these parameters are statically provisioned. The parameters may also be obtained
dynamically via DHCP.
The IP host config data ME contains a read-only group of current IP parameter attributes,
which display the IP parameters that are actually used by the IP stack.
Rec. ITU-T G.988 (10/2012)
577
578
The IP options attribute is used to control the behaviour of the IP stack and IP parameter
provisioning. The OLT may set the IP address, mask, gateway, primary or secondary DNS
attributes only when the enable DHCP bit is set to disable. If the OLT sets one of these
attributes when DHCP is enabled, the ONU accepts and stores the attribute value, but the IP
stack does not use those values until the DHCP option is disabled. Likewise, the value is
not reflected in the associated current attribute until the DHCP option is disabled. To
determine the parameter values actually in use by the IP stack, the OLT should get the
current IP parameter attributes, not the writeable IP parameter attributes.
It is considered best practice to disable the IP stack prior to modifying the IP parameters
with the OMCI. In this manner, the IP stack will have a complete coherent set of IP
parameters when it is re-enabled.
TCP/UDP config data The OLT creates a TCP/UDP config data ME for each TCP or
UDP port associated with an IP host config data ME. The OLT may choose to use the port
number as the ME ID, but the OLT must ensure that overlapping TCP and UDP port
number assignments create no naming conflict. The IP host pointer attribute must be set to
point to the IP host config data ME that is associated with this TCP/UDP port. The
TOS/diffserv field attribute is used in conjunction with an extended VLAN tagging
operation configuration data ME to mark IP frames with the desired VID and P bits. The
extended VLAN tagging operation configuration data ME is associated with the MAC
bridge port config data ME that points to the IP host config data ME. Since the extended
VLAN tagging operation configuration data ME only supports mapping DSCP to P bits,
only a single VID can be used for VoIP frames. This means that signalling frames and
bearer frames must share a VLAN, although they can have different P bits.
VoIP config data The VoIP config data ME is automatically created by the ONU. The
OLT reads the available signalling protocols attribute to determine the signalling protocols
supported by the ONU. The OLT performs a set on the signalling protocol used attribute to
select one of the available signalling protocols. The available VoIP configuration methods
attribute is read by the OLT to determine the provisioning methods that are supported by
the ONU. The OLT performs a set on the VoIP configuration method used attribute to
select one of the available configuration methods. If [BBF TR-069] or IETF sipping are
selected, the OLT need not perform any further actions to provision voice services. If the
configuration file retrieval method is selected, the OLT must set the VoIP configuration
address pointer to point to a network address ME that provides a retrieval address for the
configuration file. Actions required when a proprietary provisioning method is selected are
beyond the scope of this Recommendation.
VoIP voice CTP The OLT creates the VoIP voice CTP as the last step in basic voice
services provisioning. The VoIP voice CTP uses three pointer attributes to tie a POTS port
(PPTP POTS UNI) to a signalling protocol (SIP user data ME or MGC config data ME)
and bearer channel (VoIP media profile ME). In addition, the OLT may set the signalling
code attribute to select the POTS line type.
VoIP media profile The OLT creates the VoIP media profile ME to provision the
parameters used for voice encoding. The voice service profile pointer and RTP profile
pointer attributes must point to the MEs associated with this set of encoding parameters.
RTP profile data The OLT creates the RTP profile data ME to provision parameters
defining the RTP streams used to carry encoded voice. Since RTP ports are assigned
dynamically, no TCP/UDP port config data ME is associated with the RTP streams. The
MAC bridge port config data ME associated with the IP host config data used by the
signalling stack is the L2-L3 interworking point for RTP streams. Any L2 marking of RTP
frames should be provisioned using the extended VLAN tagging operation configuration
data ME associated with the MAC bridge port config data ME. The DSCP mark attribute of
the RTP profile data ME is used in conjunction with the tagging ME to arrive at unique tags
Rec. ITU-T G.988 (10/2012)
II.4.3
for RTP frames. The DTMF events attribute is only meaningful if the OOB DTMF attribute
of the VoIP media profile ME is enabled.
Voice service profile This ME is created by the OLT to define parameters associated with
the carrying of voice over a packet network. It includes the capability to define tone and
ringing patterns of considerable complexity, including the playback of files such as verbal
announcements and ring tones.
PPTP POTS UNI This ME is automatically created by the ONU for each POTS port. The
interworking TP pointer attribute is not meaningful in the context of VoIP and is left as a
null pointer.
SIP provisioning
The following considerations apply to provisioning the SIP MEs:
SIP user data The SIP user data ME is created by the OLT to define the parameters
associated with a single subscriber. The username/password attribute points to the data used
for subscriber authentication, not SIP agent authentication. The release timer attribute has a
default value of 10 seconds. If the release timer attribute is set to zero, the ONU uses its
internal default release timer value. This may or may not be the same as the attribute default
of 10 seconds and is not discoverable by the OLT.
SIP agent config data The SIP agent config data ME defines parameters associated with a
SIP user agent. The proxy server address pointer attribute points to a large string ME; no
authentication is associated with this address. Proxy server authentication is performed
through the use of the SIP registrar attribute which may or may not point to the same
address as the proxy server address pointer attribute. The TCP/UDP pointer attribute points
to the TCP/UDP config data ME that defines the port to be used by the SIP signalling
protocol.
Network dial plan table The network dial plan table ME is optionally created by the OLT
if a dial plan other than the ONU's default is required. When it receives the create
command, the ONU returns an unknown managed entity result-reason code if it does not
support dial plans beyond the default. There is no mechanism for the OLT to discover the
default dial plan of an ONU.
VoIP feature access codes The VoIP feature access codes ME is optionally created by the
OLT if feature access codes other than the ONU's default are required. When it receives the
create command, the ONU returns an unknown managed entity result-reason code if it does
not support VoIP feature access codes beyond the default. There is no mechanism for the
OLT to discover the default feature access codes of an ONU.
VoIP application service profile The VoIP application service profile ME is optionally
created by the OLT if provisioning of VoIP features is required. When it receives the create
command, the ONU returns an unknown managed entity result-reason code if it does not
support VoIP feature provisioning. There is no mechanism for the OLT to discover the
default VoIP features of an ONU.
II.4.4
ITU-T H.248 provisioning
The following considerations apply to provisioning the ITU-T H.248 MEs:
MGC config data The MGC config data ME is created by the OLT to provision the
parameters associated with an ITU-T H.248 media gateway. The primary MGC and
secondary MGC attributes point to network address MEs that contain IP addresses and may
contain port numbers for the media gateway controller. These port numbers are not
necessarily the same as the media gateway port number defined in the TCP/UDP port
config data ME. The default port used for the media gateway controller depends on the
value contained in the message format attribute.
Rec. ITU-T G.988 (10/2012)
579
II.4.5
II.4.5.1
Message flows
SIP provisioning flow
Figure II.4.5.1-1 depicts the provisioning flow for a basic SIP service. To assist in overall clarity,
the provisioning of optional MEs is not included, nor is the provisioning of the various ME
pointers.
OLT
ONU
Get (VoIP config data [avail VoIP config, avail signalling])
Get response (VoIP config data)
The OLT verifies that the ONU supports the OMCI and
SIP based on returned attribute values. This is typically
performed as a part of ONU discovery but is
shown here as a separate action for completeness.
Set (IP host config [IP options = DHCP])
The ONU is now provisioned to use DHCP for obtaining
IP attributes. The ONU may immediately begin
contacting a DHCP server.
Create (TCP/UDP config data)
Set (VoIP config data [VoIP config method = OMCI, signalling protocol used = SIP])
Create (large string [SIP proxy server address])
Create (authentication security [])
Create (network address [])
Create (SIP agent config data [])
Set (SIP agent config data [TCP/UDP pointer = TCP/UDP config data])
Create (large string [SIP user part AOR])
Create (SIP user data)
Create (RTP profile data)
Create (voice service profile)
Create (VoIP media profile)
If the OLT provisions a codec in the VoIP media
profile that is not supported by the ONU, the
ONU returns a parameter error.
Create (VoIP voice CTP)
Basic SIP provisioning is now complete. Specific
features may be provisioned using attributes in
the VoIP application service profile ME
G.988(12)_FII.4.5.1-1
Figure II.4.5.1-1 SIP provisioning flow
580
Rec. ITU-T G.988 (10/2012)
II.4.5.2
ITU-T H.248 message flow
Figure II.4.5.2-1 depicts the provisioning flow for ITU-T H.248 service. To assist in overall clarity,
the explicit provisioning of the various ME pointers is not included.
ONU
OLT
Get (VoIP config data [avail VoIP config, avail signalling])
Get response (VoIP config data)
The OLT verifies that the ONU supports the OMCI and
ITU-T H.248 based on returned attribute values. This is
typically performed as a part of ONU discovery but is
shown here as a separate action for completeness.
Set (IP host config [IP options = DHCP])
The ONU is now provisioned to use DHCP to obtain

IP attributes. The ONU may immediately begin
contacting a DHCP server.
Create (TCP/UDP config data)
Set (VoIP config data [VoIP config method = OMCI, signalling protocol used = ITU-T H.248])
Create (large string [Media gateway controller address])
Create (authentication security [])
Create (network address [])
Once for
primary,
once for
secondary.
Create (MGC config data [])

Create (RTP profile data)
Create (voice service profile)
Create (VoIP media profile)
If the OLT provisions a codec in the VoIP media
profile that is not supported by the ONU,
the ONU returns a parameter error.
Create (VoIP voice CTP)
ITU-T H.248 provisioning is now complete.
G.988(12)_FII.4.5.2-1
Figure II.4.5.2-1 ITU-T H.248 provisioning flow

II.4.6
Voice service in a dual-managed ONU
In addition to supporting full voice service provisioning, the OMCI also supports ONUs that use a
method other than the OMCI to manage voice services. This clause describes the techniques that are
used for supporting a non-OMCI managed voice service.
II.4.6.1
Common provisioning
The following considerations apply to provisioning the common VoIP MEs for a non-OMCI
managed voice service:
IP host config data The ONU creates the IP host config data ME for each IP stack
instance. Attributes in this ME provide the IP parameters used for the non-OMCI
management interface. There is no direct relation between this ME and VoIP provisioning.
Rec. ITU-T G.988 (10/2012)
581
II.4.6.2
TCP/UDP config data The OLT creates a TCP/UDP config data ME for the port used by
the non-OMCI management interface. There is no direct relation between this ME and
VoIP provisioning.
VoIP config data The VoIP config data ME is automatically created by the ONU when it
supports a native voice service. The OLT reads the available VoIP configuration methods
attribute to discover the voice service management methods supported by this ONU. The
OLT performs a set on the VoIP configuration method used attribute to select the
non-OMCI method to be used by the ONU. The OLT may optionally set the VoIP
configuration address pointer attribute to a network location from which the ONU will
receive its voice provisioning parameters. The OLT also optionally sets the retrieve profile
attribute to indicate to the ONU that it must retrieve the provisioning parameters for the
voice service. The ONU uses the VoIP configuration state attribute to indicate the state of
voice service provisioning. The ONU uses the profile version attribute to indicate the
version of the voice service parameter set that it is currently using.
VoIP voice CTP Not used
VoIP media profile Not used
RTP profile data Not used
Voice service profile Not used
PPTP POTS UNI Used in the same manner as described in clause II.4.2.
SIP provisioning
When an ONU supports non-OMCI provisioning of SIP, it automatically creates a SIP config portal
ME. This ME contains a single table attribute: the configuration text table. The OLT reads this table
to obtain a textual representation of the SIP configuration in use on the ONU. Whenever the text in
this table changes, the ONU issues an AVC to the OLT. The format of the text contained within the
table is not defined but should be human-readable.
II.4.6.3
ITU-T H.248 provisioning
When an ONU supports non-OMCI provisioning of ITU-T H.248, it automatically creates an

ITU-T H.248 config portal ME. This ME contains a single table attribute: the configuration text
table. The OLT reads this table to obtain a textual representation of the ITU-T H.248 configuration
in use on the ONU. Whenever the text in this table changes, the ONU issues an AVC to the OLT.
The format of the text contained within the table is not defined but should be human-readable.
582
Rec. ITU-T G.988 (10/2012)
Appendix III
This appendix is intentionally left blank
Rec. ITU-T G.988 (10/2012)
583
Bibliography
[b-ATIS-0300231]
ATIS-0300231.2013, Layer 1 In-Service Transmission Performance

Monitoring.
[b-ATIS-0600403]
ATIS-0600403.1999 (R2012), Network and Customer Installation

Interfaces DS1 Electrical Interfaces.
[b-ATIS-0600413]
ATIS-0600413.2009, Network to Customer Installation Interfaces

Asymmetric Digital Subscriber Line (ADSL) Metallic Interface.
[b-BBF TR-101]
Broadband Forum TR-101 (2006), Migration to Ethernet based DSL

aggregation.
[b-BBF TR-156]
Broadband Forum TR-156 (2012), Using GPON Access in the context

of TR-101.
<http://www.broadband-forum.org/technical/download/TR-156_Issue-3.pdf>
[b-Floyd]
Floyd, S., and Jacobson, V. (1993), Random early detection gateways

for congestion avoidance. IEEE/ACM Transactions on Networking,
Vol. 1, No. 4, August, pp. 397-413.
[b-IEEE P1904.1]
IEEE P1904.1, Standard for Service Interoperability in Ethernet

Passive Optical Networks (SIEPON).
[b-IETF RFC 2460]
IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6)

Specification.
[b-IETF RFC 2463]
IETF RFC 2463 (1998), Internet Control Message Protocol

(ICMPv6) for the Internet protocol Version 6 (IPv6) Specification.
[b-IETF RFC 2475]
IETF RFC 2475 (1998), An Architecture for Differentiated Services.
[b-IETF RFC 2516]
IETF RFC 2516 (1999), A Method for Transmitting PPP Over

Ethernet (PPPoE).
[b-IETF RFC 2571]
IETF RFC 2571 (1999), An Architecture for Describing SNMP

Management Frameworks.
[b-IETF RFC 2698]
IETF RFC 2698 (1999), A Two Rate Three Color Marker.
[b-IETF RFC 2710]
IETF RFC 2710 (1999), Multicast Listener Discovery (MLD) for

IPv6.
[b-IETF RFC 3232]
IETF RFC 3232 (2002), Assigned Numbers: RFC 1700 is Replaced

by an On-line Database.
[b-IETF RFC 3247]
IETF RFC 3247 (2002), Supplemental Information for the New

Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior).
[b-IETF RFC 3315]
IETF RFC 3315 (2003), Dynamic Host Configuration Protocol for

IPv6 (DHCPv6).
[b-IETF RFC 3418]
IETF RFC 3418 (2002), Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP).
[b-IETF RFC 3621]
IETF RFC 3621 (2003), Power Ethernet MIB.
[b-IETF RFC 3736]
IETF RFC 3736 (2004), Stateless Dynamic Host Configuration

Protocol (DHCP) Service for IPv6.
[b-IETF RFC 3926]
IETF RFC 3926 (2004), FLUTE File Delivery over Unidirectional

Transport.
584
Rec. ITU-T G.988 (10/2012)
[b-IETF RFC 4115]
IETF RFC 4115 (2005), A Differentiated Service Two-Rate, ThreeColor Marker with Efficient Handling of in-Profile Traffic.
[b-IETF RFC 4291]
IETF RFC 4291 (2006), IP Version 6 Addressing Architecture.
[b-IETF RFC 4541]
IETF RFC 4541 (2006), Considerations for Internet Group

Management Protocol (IGMP) and Multicast Listener Discovery
(MLD) Snooping Switches.
[b-IETF RFC 4861]
IETF RFC 4861 (2007), Neighbor Discovery for IP Version 6 (IPv6).
[b-IETF RFC 4862]
IETF RFC 4862 (2007), IPv6 Stateless Address Autoconfiguration.
[b-IETF RFC 5462]
IETF RFC 5462 (2009), Multiprotocol Label Switching (MPLS) Label

Stack Entry: EXP Field Renamed to "Traffic Class" Field.
[b-IETF RFC 5942]
IETF RFC 5942 (2010), IPv6 Subnet Model: The Relationship

between Links and Subnet Prefixes.
[b-IETF RFC 6106]
IETF RFC 6106 (2010), IPv6 Router Advertisement Options for DNS
Configuration.
[b-MEF 10.2]
Metro Ethernet Forum MEF10.2 (2009), Ethernet Services Attributes

Phase 2.
[b-PKT-SP-EC-MGCP]
CableLabs, PKT-SP-EC-MGCP-I11-050812 (2005), PacketCable

Network-Based Call Signaling Protocol Specification.
Rec. ITU-T G.988 (10/2012)
585
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
Terminals and subjective and objective assessment methods
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, 2013

T Rec G.988 201210 I!!pdf e

Uploaded by

Copyright:

Available Formats

T Rec G.988 201210 I!!pdf e

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

T Rec G.988 201210 I!!pdf e

Uploaded by

Copyright:

Available Formats

I n t e r n a t i o n a l

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

ONU management and control interface (OMCI)

Recommendation ITU-T G.988

ITU-T G-SERIES RECOMMENDATIONS

Recommendation ITU-T G.988

ITU-T G.988 (2010) Amd. 1 2011-04-13

ITU-T G.988 (2010) Amd. 2 2012-04-22

ITU-T G.988 (2010) Cor. 1

Rec. ITU-T G.988 (10/2012)

INTELLECTUAL PROPERTY RIGHTS

Rec. ITU-T G.988 (10/2012)

Abbreviations and acronyms ........................................................................................

Reference model and terms ..........................................................................................

Requirements of the management interface specification ............................................

Protocol-independent MIB for the OMCI ....................................................................

MIB description ............................................................................................................

This clause is intentionally left blank ...........................................................................

ONU management and control protocol .......................................................................

Rec. ITU-T G.988 (10/2012)

Baseline and extended messages ....................................................................

Annex A OMCI message syntax and common features .......................................................

Annex B OMCI in ITU-T G.984 and ITU-T G.987 systems ................................................

Annex C OMCI in Ethernet PON systems ...........................................................................

Appendix I OMCI common services ....................................................................................

Appendix II G-PON mechanisms and services.....................................................................

Appendix III This appendix is intentionally left blank .........................................................

Rec. ITU-T G.988 (10/2012)

Recommendation ITU-T G.988

GEM adaptation layers

Ethernet services, including MAC bridged LAN

circuit emulation service

Recommendation ITU-T E.164 (2005), The international public

Recommendation ITU-T G.704 (1998), Synchronous frame structures used at

Recommendation ITU-T G.722.1 (2005), Low-complexity coding at 24 and

Recommendation ITU-T G.722.2 (2003), Wideband coding of speech at

Recommendation ITU-T G.723.1 (2006), Dual rate speech coder for

Recommendation ITU-T G.728 (1992), Coding of speech at 16 kbit/s using

Recommendation ITU-T G.729 (2007), Coding of speech at 8 kbit/s using

Recommendation ITU-T G.784 (2008), Management aspects of synchronous

Recommendation ITU-T G.826 (2002), End-to-end error performance

Recommendation ITU-T G.983.2 (2005), ONT management and control

Recommendations ITU-T G.984.x-series, Gigabit-capable passive optical

Recommendation ITU-T G.984.3 (2008), Gigabit-capable Passive Optical

Recommendation ITU-T G.984.4 (2008), Gigabit-capable passive optical

Recommendation ITU-T G.984.6 (2008), Gigabit-capable passive optical

Recommendation ITU-T G.986 (2010), 1 Gbit/s point-to-point Ethernet-based

Recommendations ITU-T G.987 .x-series, 10 Gigabit-capable passive optical

Recommendation ITU-T G.987 (10/2010), 10-Gigabit-capable passive optical

Recommendation ITU-T G.987.1 (2010), 10-Gigabit-capable passive optical

Recommendation ITU-T G.987.3 (2010), 10-Gigabit-capable passive optical

Recommendation ITU-T G. 992.1 (1999), Asymmetric digital subscriber line

Recommendation ITU-T G.992.2 (1999), Splitterless asymmetric digital

Recommendation ITU-T G. 992.3 (2009), Asymmetric digital subscriber line

Recommendation ITU-T G. 992.4 (2002), Splitterless asymmetric digital

Recommendation ITU-T G. 992.5 (2009), Asymmetric digital subscriber line 2

Recommendation ITU-T G.993.1 (2004), Very high speed digital subscriber

Recommendation ITU-T G.994.1 (in force), Handshake procedures for digital