- uint8_t ecpri_concat:1; /**< This parameter indicates when eCPRI concatenation is in use
- (allowing multiple eCPRI messages in a single Ethernet payload).
- NOTE: This parameter is part of the eCPRI common header. */
- uint8_t ecpri_resv:3; /**< This parameter is reserved for eCPRI future use.
- NOTE: This parameter is part of the eCPRI common header. */
- uint8_t ecpri_ver:4; /**< This parameter indicates the eCPRI protocol version.
- NOTE: This parameter is part of the eCPRI common header. */
- uint8_t ecpri_mesg_type:8; /**< This parameter indicates the type of service conveyed by
- the message type. NOTE: This parameter is part of the eCPRI
- common header. NOTE: In this version of the specification,
- only values "0000 0000b" and "0000 0010b" and "0000 0101b" are used. */
- rte_be16_t ecpri_payl_size:16; /**< This parameter is the size in bytes of the payload part
- of the corresponding eCPRI message. It does not include any padding bytes
- following the eCPRI message. The maximum supported payload size is 216-1,
- but the actual size may be further limited by the maximum payload size of
- the underlying transport network. NOTE: This parameter is part of the
- eCPRI common header. */
-
- rte_be16_t ecpri_xtc_id; /**< 3.1.3.1.6 This parameter is a component_eAxC identifier (c_eAxC ID) and
- identifies the specific data flow associated with each C-Plane (ecpriRtcid) or
- U-Plane (ecpriPcid) message. It is the analog of CPRI's "AxC" (antenna-carrier)
- value so is designated here as "eAxC" ("e" for "extended" to accommodate multiple
- bands and multiple component carriers). In addition, the "eAxC" is divided into
- "component eAxC" parts (c_eAxC) because multiple lls-CU processors may contribute
- to a single eAxC and must be identified for correct data routing. */
-
- struct ecpri_seq_id ecpri_seq_id; /**< This parameter provides unique message identification and ordering on
- two different levels. The first octet of this parameter is the Sequence ID, which is used to identify ordering of
- messages within an eAxC message stream. The Sequence ID field increments and wraps independently for each U-Plane
- eAxC DL, U-Plane eAxC UL, C-Plane eAxC DL, and C-Plane eAxC UL, even if they share the same eAxC ID.
- The Sequence ID is used to verify that all messages are received and also to reorder messages that are received out of order.
- The second octet of this parameter is the Subsequence ID. The Subsequence ID is used to verify ordering and implement
- reordering when radio-transport-level (eCPRI or IEEE-1914.3) fragmentation occurs.
- Radio-transport (eCPRI or IEEE-1914.3) fragmentation is a method of splitting U-plane messages containing one or
- more sections whose length exceeds the maximum packet or message length of the underlying protocol.
- The Subsequence ID field consists of a 7 bit Subsequence counter and a single bit field, called E-bit.
- The Subsequence number increments starting from zero for each fragment of a U-plane message. The E bit
- is used to indicate the last message of the radio-transport level fragments. It is always set to zero
- except for the last message of the U-plane fragment. In the case of C-plane messages radio-transport
- fragmentation is not allowed, therefore the Subsequence ID shall be set to zero, and the E bit set to one.
- See Section 3.1.4 for a description of the fragmentation process.
- NOTE: As an alternative to radio-transport-level fragmentation, application fragmentation can be implemented.
- In this case the application can take the responsibility to ensure all transport messages are not too long
- (fit within the necessary transport payload size). When this "application layer fragmentation" is used,
- the subsequence identifier shall always be set to "0", and the E-bit set to "1" (See Section 3.1.4). */
-