Hello, friend!
OMCI messages are strictly limited in length and format. Specifically, the length is consistently 53 bytes and the length of the OMCI data unit is 48 bytes.
GEM Header: includes GEM payload, GEM port ID, payload type indicator (PTI), and header error control (HEC).
Transaction Correlation Identifier: The value of this field must be the same in a request and the response to this request. The highest order of this field indicates the priority of an OMCI message. Value 0 indicates a low priority and value 1 indicates a high priority.
Message type:
DB: a destination bit, which is consistently 0.
AR: an acknowledge request, indicating whether an OMCI message requires the response from the peer end. Value 0 indicates that the response is not required and value 1 indicates that the response is required.
AK: acknowledgement, indicating whether an OMCI message is a response. Value 0 indicates not and value 1 indicates yes.
MT: message type, which supports up to 32 message types, including Create, Delete, Set, Get, and MIB upload. In ITU-T Recommendation G.984.4, message types 4 through 28 are used and other message types are reserved.
Device identifier: The value of this field is consistently 0xA.
Message Identifier: a 2-byte entity or instance ID.
Message Contents: packet payload.
OMCI trailer: Two bytes are consistently 0, two bytes are packet length 0x28, and four bytes are CRCs.
The OLT controls the ONT using the OMCI. The OMCI protocol allows the OLT to:
Establish and release connections with the ONT.
Manage the UNIs on the ONT.
Request configuration information and performance statistics.
Autonomously inform the system administrator of events, such as link failures.
The OMCI protocol runs over a GEM connection between the OLT controller and the ONT controller. The GEM connection is established during ONT initialization. The OMCI protocol is asynchronous: the OLT controller is the master and the ONT controller is the slave. A single OLT controller using multiple protocol instances over separate control channels can control multiple ONTs.
The OLT manages the ONT using OMCI in the following aspects:
Configuration management: Controls and identifies the ONT, and collects data from and provides data to the ONT.
Fault management: Supports limited fault management. Most of the operations are limited to failure indication.
Performance management: Collects and queries performance statistics.
Security management: Enables/Disables downstream encryption.
Establishing the ONU management and control channel (OMCC)
Upon initialization, the ONU creates a virtual OMCI T-CONT, an OMCC structure that contains an OMCI queue, a placeholder for an alloc-ID attribute, and going beyond the definition of an ordinary T-CONT, a placeholder for an OMCI port-ID attribute.
During activation, the ONU receives a PLOAM message from the OLT indicating the assignment of the ONU-ID. The ONU populates the alloc-ID attribute of its virtual OMCI T-CONT with the ONU-ID. This makes the alloc-ID for OMCI the same as the assigned 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 should not be possible to de-allocate the default alloc-ID with an assign_alloc-ID type 255 message.

Upon completion of ONU activation in 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 populates the OMCI port-ID attribute of the OMCC structure based on that message and responds back to the OLT with an acknowledgment.
In 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.
Thanks!