There are some conventions which are expected of the RIC components to use so that the RMR messages they send/receive make sense to the other components.

Payload

The payload of the RMR message related to sending on receiving E2 messages should be just the ASN.1 encoded E2 message. Any other information that needs to be communicated between the sender and receiver should be encoded in the RMR header fields (meid, subid, etc).

NOTE: The X2 setup request message communicated between the E2 Manager and E2 Termination is an exception to this rule since it carries both the X2 SETUP REQUEST payload and the IP address and port of the eNB/gNB.

Message Type

The message type header field (mtype) should be populated based on message type coding documented here: RIC message types

Subscription ID

The subscription id header field (sub_id) identifies the subscription for routing purposes. The value of the sub_id is the "RIC Request Sequence Number" in the "RIC Request ID" (section 9.2.901 in the E2AP spec).

When E2 Termination receives an E2 message from the SCTP connection, it should populate the RMR.sub_id using the "RIC Request Sequence Number" in the "RIC Request Id" of the E2 message.
When the Subscription Manager is used, it will assign its own "RIC Request ID" (and thus, "RIC Request Sequence Number") into the subscription request and the sub_id of the resulting subscription request is this new sequence number. Similarly, any RIC INDICATION messages related to the subscription will carry the "RIC Request ID" and sub_id as assigned by the Subscription Manager.
When the Subscription Manager is not used, the sub_id will match the "RIC Request Sequence Number" as originally assigned by the xApp.

The MEID
The value used for meid is the "Global gNB ID" as defined by 3GPP (example: "NYN0001246")

Transaction ID
A component originating a new transaction within the RIC (e.g., E2 Termination receiving a message from SCTP) should assign a transaction id in the RMR message. Any component that receives this message and sends a new message belonging to the same logical transaction, should copy the transaction id from the received message to the message being sent. This allows the original request and eventual final response messages to be matched and the control loop latency of the RIC to be measured.