Open RAN    

 

 

 

eCPRI

Like CPRI, eCPRI is also a communication interface between DU and RU (e.i, interface between Radio Unit and PHY protocol stack) as illustrated below.

Followings are the list of details that I am going to cover in this note.

Why eCPRI ?

We have been using CPRI for a long time. Why we need another technology (i.e, eCPRI) now ? There are some reasons commonly mentioned about this as listed below.

  • Data Rate : As you might have noticed, whenever a new communication technology comes out one of the most critical feature of the technology is said to be 'High Data Rate'. CPRI can carry pretty high data rate. With the latest CPRI option, it can carry around 25 Gbps with CPRI option 10 (See this note). But with 5G we get to need even higher throughput. I think early stage of 5G throughput requirement, CPRI may be OK in terms of data rate but it will be getting more and more difficult to meet the required data rate with CPRI.
  • Compatibility/Interoperability among vendors : As far as I remember, many people in the industry was excited to have a common specification when early CPRI concept was being discussed. But somehow it ended up with vendor specific at least in some part of the implementation. Of course, there were a lot of commonalities because there is a common specification for CPRI, but the final implementation was not 100% compatiple/interoperable among vendors. It is expected that eCPRI would become more strict in terms of compability. It is highly likely to be highly compatible since PHY/MAC media is based on eithernet. This can help to reduce vendor lock-in and promote competition.
  • Lower Bandwidth Requirements: eCPRI supports more efficient compression and decompression of data, which reduces the amount of bandwidth required for transmission. This can help to reduce costs and enable more efficient use of network resources.
  • Distributed Architecture: eCPRI supports a more distributed network architecture, allowing for more flexibility in the placement of radio equipment. This can help to optimize network performance and reduce latency.
  • Scalability: eCPRI supports greater scalability than CPRI, making it easier to add new radio units and expand the network. This can be particularly useful in rapidly growing networks or in areas with high user demand.
  • Lower Latency: eCPRI supports lower latency than CPRI, which is particularly important for real-time applications such as voice and video. This can help to improve the quality of the user experience.

Challenges and Limitations

No new technology comes without any challenges and limitation. Same goes for eCPRI. We can think of some challenges and limitation of eCPRI as follows. I think most of these limitation / challenges will be overcome as time goes on and eCPRI gets more widely adopted. However, some (e.g, Data Security) would stay longer as challenges.

  • Complexity: eCPRI is a complex technology that requires specialized skills and knowledge to design, implement, and maintain. This can increase the cost of deployment and make it more difficult for smaller operators to adopt.
  • Interoperability: While eCPRI is designed to be more interoperable than CPRI, there may still be compatibility issues between equipment from different vendors. This can create challenges for operators looking to integrate equipment from multiple sources.
  • Cost: While eCPRI can be cost-effective in the long run, there are initial deployment costs associated with upgrading to the technology. This can be a challenge for operators who are already operating on tight budgets.
  • Limited backward compatibility: eCPRI is not backward compatible with CPRI, which means that operators may need to replace their existing infrastructure in order to adopt the technology. This can be costly and time-consuming.
  • Data Security: eCPRI requires that the data be transmitted over the public internet, which may pose a security risk. It is important for operators to ensure that appropriate security measures are in place to protect the data from unauthorized access or interception.

eCPRI Protocol Stack

< eCPRI Specification - Figure 6: eCPRI protocol stack over IP / Ethernet >

          PTP : Precision Time Protocol

eCPRI Physical Medium and Data Rate

< eCPRI Specification - Table 3: Common Ethernet interface types for the given use cases  >

Splits and Data Rate

< eCPRI Specification - Figure 32: PHY layer and eCPRI splits >

 

< eCPRI Specification - Table 16: PHY layer splits bit rate estimations for the example use case above  >

eCPRI Transport Structure

Theoretically eCPRI can be embedded into various types of transport (PHY/MAC) media, but it is likely that ethernet would be the most common transport for eCPRI. In this structure, eCPRI packets gets embedded into the payload part of etherent frame as shown below.

In order for this kind of ethernet communication to meet the eCPRI requirement, it should meet the stringent timing and sync specification required by eCPRI. So there might be cost issue and some degree of compatibility challenges with ethernet cards

 

eCPRI Common Header Structure

As shown in the diagram, eCPRI packet is made up of two parts : eCPRI Common Header and eCPRI Payload. The structure of the eCPRI Common Header and eCPRI Message Type contained in the common header is shown in the diagram.

eCPRI Frame Structure

Following diagram shows the structure of Message Header for each of the message type.

The way you interpreted this diagram is like this : (This is only a few example. you can interpret the diagram as in the following example)

  • The message header of IQ Data is composed of two fields : PC_ID and SEQ_ID.  The length of PC_ID is 2 bytes and the length of SEQ_ID is 2 bytes.
  • The message header of Real-Time Control Data is composed of two fields : RTC_ID and SEQ_ID.  The length of RTC_ID is 2 bytes and the length of SEQ_ID is 2 bytes

O-RAN Transport Frame over eCPRI

The O-RAN Transport Frame over eCPRI  serves as a foundational element in the O-RAN architecture, providing a standardized and efficient mechanism for transporting data between the O-DU  and O-RU across the fronthaul interface in 5G networks. Built upon Ethernet framing with an eCPRI header, this transport framework supports the segmentation and encapsulation of both C-Plane and U-Plane data and they enables flexible and interoperable communication. The C-Plane frame is designed for low-latency control signaling and carries critical instructions such as scheduling commands and beamforming parameters, ensuring real-time coordination of radio functions. The U-Plane frame transports high-bandwidth IQ (In-phase and Quadrature) data, facilitating the transfer of symbol-level information for both uplink and downlink transmissions.

Header Structure of Transport Fame

The header structure of the eCPRI Transport Frame forms a critical component of the O-RAN architecture, providing a robust and standardized framework for encapsulating and routing data across the fronthaul interface between the O-DU and O-RU  in 5G networks. Built atop Ethernet frames, this header structure integrates seamlessly with the eCPRI protocol, incorporating essential fields such as message type, protocol version, payload size, and sequence number, which collectively enable precise identification, ordering, and management of C-Plane and U-Plane traffic. The header supports the efficient transmission of C-Plane control instructions, such as scheduling and beamforming commands, while facilitating the high-bandwidth delivery of U-Plane IQ data, with optional IP/UDP encapsulation enhancing interoperability and flexibility. This well-defined header structure not only ensures low-latency and reliable data exchange but also aligns with O-RAN’s commitment to scalability, vendor neutrality, and support for diverse functional splits like Cat A and Cat B in open radio access networks.

Followings are the descriptions of each field based on O-RAN.WG4.CUS.0-R003-v15.00 : Clause 5.1.3.2

ecpriVersion (eCPRI protocol revision)

This parameter indicates the eCPRI protocol version. This parameter is part of the eCPRI common header.

  • Value range: {0001b=eCPRI version 1.0, 1.1, 1.2 and 2.0, where the interpretation of the eCPRI message shall follow the eCPRI specification versions up to 2.0; 0000b and 0010b-1111b=Reserved for future eCPRI protocol revisions}.
  • Type: unsigned integer.
  • Field length: 4 bits.
  • Default Value: 0001b (eCPRI version 1.0, 1.1, 1.2 and 2.0).

ecpriReserved (eCPRI reserved)

This parameter is reserved for eCPRI future use. This parameter is part of the eCPRI common header.

  • Value range: {001b-111b=Reserved}.
  • Type: unsigned integer.
  • Field length: 3 bits.
  • Default Value: 000b (reserved fields should always be set to all zeros).

ecpriConcatenation (eCPRI concatenation indicator)

This parameter indicates when eCPRI concatenation is in use (allowing multiple eCPRI messages in a single Ethernet payload). This parameter is part of the eCPRI common header.

  • Value range: {0b=No concatenation, 1b=Concatenation}.
  • Type: binary bit.
  • Field length: 1 bit.
  • Default Value: 0b (no concatenation).

ecpriMessage (eCPRI message type)

This parameter indicates the type of service conveyed by the message type. This parameter is part of the eCPRI common header. In the present document, only values "0000 0000b" and "0000 0010b" and "0000 0101b" are used.

  • Value range:
    • 0000 0000b = IQ data message
    • 0000 0010b = Real-time control data message
    • 0000 0101b = transport network delay measurement message (see clause 4.4.4.4 for full message format)
    • other values not recognized within the present document.
  • Type: unsigned integer.
  • Field length: 8 bits.
  • Valid Values: 0x0 (U-Plane data) or 0x2 (C-Plane data) or 0x5 (network delay measurement messages).

ecpriPayload (eCPRI payload size)

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. This parameter is part of the eCPRI common header.

  • Value range: {0000 0000 0000 0000b-1111 1111 1111 1111b}.
  • Type: unsigned integer.
  • Field length: 16 bits.

ecpriRtcid / ecpriPcid (real time control data / IQ data transfer message series identifier)

The ecpriRtcid and ecpriPcid, functions as eAxC identifiers (eAxC_ID). eAxC ID uniquely identify C-Plane and U-Plane data flows between the O-DU and O-RU in an O-RAN setup. eAxC extends the CPRI AxC concept to support multiple bands and component carriers. An eAxC_ID can handle mixed numerologies if supported via M-Plane, allowing a single ID for diverse channels like PRACH, or require unique IDs per numerology if not supported, with uniqueness enforced within an O-RU’s endpoints of the same direction. The O-DU may reuse eAxC_IDs across O-RUs, but M-Plane ensures only configured interfaces transfer messages, and some O-RUs limit independent sequence checking for DL and UL under the same eAxC_ID, necessitating distinct IDs or shared sequencing for compatibility, while configurable sequence checking can be disabled via M-Plane, affecting fragmentation and error reporting.

  • Definition & Purpose
    • eAxC_ID (Extended Antenna-Carrier ID) is used to identify C-Plane (ecpriRtcid) and U-Plane (ecpriPcid) data flows.
    • It is similar to CPRI's AxC (Antenna-Carrier) value, extended to support multiple bands and component carriers.
    • Multiple O-DU processors can contribute to a single eAxC_ID.
  • Handling Mixed Numerologies
    • An endpoint may support mixed numerologies, indicated via M-Plane parameters.
    • Section Type 3 messages are used to select numerologies (frameStructure) from the capability list.
    • A single eAxC_ID may be shared among different numerologies (frameStructure, cpLength, timeOffset, freqOffset) and PRACH.
    • If an endpoint does not support mixed numerologies, it assigns a unique eAxC_ID to each numerology.
  • O-RU Endpoint & Fronthaul Interfaces
    • The eAxC_ID assigned to an O-RU’s endpoint must be unique within the O-RU for the same direction (Tx or Rx).
    • An O-RU endpoint may be associated with multiple physical and virtual fronthaul interfaces (Ethernet ports and VLANs).
    • However, a single eAxC_ID cannot be used for different endpoints.
    • The O-RU design restricts which interfaces can be used for C-Plane and U-Plane messages, enforced via M-Plane configuration.
  • eAxC_ID Assignment in O-DU and O-RU
    • The O-DU may use the same eAxC_ID for different O-RUs.
    • However, eAxC_IDs within an O-RU must be unique for the same direction.
    • eAxC_IDs assigned to one FHM (Fronthaul Manager) must be unique in the same direction.
  • eAxC_ID is specific to:
    • eCPRI Message Type = 2 (C-Plane)
    • eCPRI Message Type = 0 (U-Plane)
  • One eAxC contains only one spatial stream at a time, meaning:
    • One beam per subcarrier at any given time.
    • If precoding is performed in the O-RU, each eAxC contains one layer at a time.
    • Exception:
      • In Tx Diversity (TxD, LTE TM2), a single eAxC (one ecpriRtcid and ecpriPcid) represents all TxD layers.
  • Limitations & Compatibility Considerations
    • Some O-RUs do not support independent sequence checkers for:
      • C-Plane messages describing U-Plane DL
      • C-Plane messages describing U-Plane UL
    • This limitation is signaled via M-Plane
    • If the O-RU or O-DU only supports older M-Plane versions, interoperability must be ensured manually through off-line discussions.
  • Interoperability Strategies for Sequence Checkers
    • To avoid sequence checker issues, O-DUs should:
      • Use different eAxC_IDs for U-Plane DL and U-Plane UL.
      • Use a shared sequence generator for both DL and UL messages.
  • Sequence Number Checking & Configuration
    • Some O-DUs do not support sequence number generation or checking.
    • The O-RU may expose an M-Plane feature called SEQ-ID-CHECKING-CONFIGURABLE.
    • If supported, the O-DU can request the O-RU to disable sequence number checking by setting seq-id-checking-disabled = true.
    • When sequence checking is disabled:
      • RX_SEQID_ERR and RX_SEQID_ERR_C counters are not updated.
      • Radio transport layer fragmentation (Clause 5.5.3) is not possible.
  • Network Operator Considerations
    • If an O-RU does not support SEQ-ID-CHECKING-CONFIGURABLE, network operators using such O-RUs must ensure:
      • O-DUs can interoperate with O-RUs using non-standardized solutions.
      • This may require manual configuration or off-line discussions.
  • eAxC_ID Subfields and Bit Allocation
    • eAxC_ID Composition
      • DU_Port_ID[4 bits]  – Identifies processing units at the O-DU (e.g., baseband cards).
      • BandSector_ID[4 bits]  – Aggregated cell identifier distinguishing bands and sectors.
      • CC_ID[4 bits]  – Identifies Component Carriers.
      • RU_Port_ID[ bits]  – Represents logical flows such as:
        • Data layers or spatial streams.
        • Separate numerologies (e.g., PRACH).
        • Signaling channels with special antenna assignments (e.g., SRS).
    • Bit Allocation and Configuration
      • The assignment of DU_Port_ID, BandSector_ID, CC_ID, and RU_Port_ID is controlled by O-DU via the M-Plane.
      • The O-RU does not need to interpret bit-level allocation within these fields.
      • The bitwidth of each subfield is flexible and set via M-Plane messaging.
      • The Service Management and Orchestration (SMO) function ensures:
        • Proper assignment of bitwidths.
        • Full 16-bit utilization (including padding if needed).
    • Key Properties
      • Dynamic Field Allocation: The M-Plane dynamically configures each subfield size based on network needs.
      • Scalability: Allows different O-RUs to optimize bit usage for different deployments.
      • Value Range: {0000 0000 0000 0000b - 1111 1111 1111 1111b} (16-bit full range).

ecpriSeqid (message identifier)

The ecpriSeqid provides unique identification and ordering across two levels for data exchange between the O-DU and O-RU in an O-RAN setup. The first level, the Sequence ID, occupies the first octet and increments independently for U-Plane (DL and UL) and C-Plane (DL and UL) message streams within each eAxC, ensuring proper sequencing and reordering of messages, while the second level, the Subsequence ID, uses the second octet to manage radio-transport-level fragmentation of U-Plane messages, featuring a 7-bit Subsequence counter and an E-bit to mark the last fragment. C-Plane messages do not support fragmentation, setting the Subsequence ID to zero with the E-bit to one, whereas application-layer fragmentation offers an alternative by keeping messages within payload limits, also setting Subsequence ID to zero and E-bit to one. The Sequence ID is uniquely generated by the fronthaul transmitter (O-DU or O-RU) per eAxC, with independent generators for C-Plane DL and UL, though some O-RUs may lack independent sequence checkers, prompting O-DUs to use a shared sequence generator for interoperability within the same eAxC_ID when needed.

  • Purpose & Function
    • Provides unique message identification and ordering at two levels:
      • Sequence ID – Ensures message ordering within an eAxC message stream.
      • Subsequence ID – Handles fragmentation and reordering when messages are split across multiple packets.
  • Sequence ID
    • First octet of the ecpriSeqid parameter.
    • Manages ordering of messages independently for each U-Plane and C-Plane direction:
      • U-Plane eAxC DL
      • U-Plane eAxC UL
      • C-Plane eAxC DL
      • C-Plane eAxC UL
    • Increments and wraps independently for each stream.
    • Used to:
      • Verify that all messages are received.
      • Reorder messages that arrive out of sequence.
  • Subsequence ID
    • Second octet of ecpriSeqid.
    • Used when radio-transport fragmentation occurs (eCPRI or IEEE-1914.3).
    • Structure:
      • 7-bit Subsequence Counter – Increments from zero for each fragment.
      • 1-bit E-bit (End Indicator):
        • Set to "0" for all fragments except the last one.
        • Set to "1" for the final fragment in a sequence.
    • C-Plane messages do not allow fragmentation, so:
      • Subsequence ID = 0
      • E-bit = 1
  • Fragmentation Methods
    • Radio-Transport-Level Fragmentation:
      • Splits large messages into multiple fragments when message size exceeds protocol limits.
      • Uses Subsequence ID for tracking and reordering fragments.
    • Application-Layer Fragmentation:
      • The application ensures transport messages fit within payload size.
      • If used, Subsequence ID is always "0", and E-bit is "1".
  • Key Implications
    • (a) Sequence ID is unique per eAxC:  Different eAxC_IDs generate independent Sequence IDs.
    • (b) Sequence ID is generated by the fronthaul interface transmitter: Can be in either the O-DU or O-RU.
    • (c) Independent sequence generators for C-Plane messages: A C-Plane message for U-Plane DL has a separate sequence generator from a C-Plane message for U-Plane UL.
  • O-RU Compatibility Considerations
    • Some O-RUs do not support independent sequence checkers for:
      • C-Plane messages describing U-Plane DL and UL within the same eAxC_ID.
    • To interoperate with such O-RUs, O-DUs can:
      • Use separate eAxC_IDs for U-Plane DL and U-Plane UL.
      • Use a shared sequence generator for both.

C-Plane Transport Frame

Following illustration is based on ORAN-WG4.CUS.0-v03.00 and O-RAN.WG4.CUS.0-R003-v15.00

The high level descriptions on each section type is as follows :

< O-RAN.WG4.CUS.0-R003-v15.00 : Table 7.3.1 1: Section Types >

Section Type

Target Scenario

Remarks

0

Unused Resource Blocks or symbols in Downlink or Uplink

Indicates to the O-RU that certain Resource Blocks or symbols will not be used (idle periods, guard periods). Likewise, there are no associated U-Plane messages containing IQ data for this Section Type. The purpose is to inform the O-RU that transmissions may be halted during the specified idle interval for e.g. power-savings or to provide an interval for calibration.

1

Most DL/UL radio channels (NOTE)

Here "most" refers to channels not requiring time or frequency offsets such as are needed for mixed-numerology channels.

2

Reserved for future use

3

PRACH and mixed-numerology channels (NOTE)

Channels requiring time or frequency offsets or different-than-nominal SCS values.

4

Slot Configuration Control

Slot configuration for multiple eAxC_IDs with one or multiple Section Type 4 configuration commands.

5

UE scheduling information (ueld assignment to section)

Provides scheduling information for uelds.

6

Channel information

Sends UE-specific channel information from the O-DU to the O-RU.

7

LAA

Messages communicated between O-DU and the O-RU in both directions to configure LBT for PDSCH/DRS transmission and to report the LBT outcome.

8

ACK/NACK Feedback

Sent from the O-RU to the O-DU, providing ACK/NACK feedback for section descriptions in C-Plane messages.

9-255

Reserved for future use

NOTE: When PRACH has the same numerology as other UL channels, Section Type 1 can alternatively be used by O-DU for PRACH signaling. In this case, O-RU is not expected to perform any PRACH specific processing.

The detailed packet structure of each section type are described in O-RAN.WG4.CUS.0-R003-v15.00 - 7.4 Section Type elements

U-Plane Transport Frame

Following illustration is based on ORAN-WG4.CUS.0-v03.00 and O-RAN.WG4.CUS.0-R003-v15.00

The high level descriptions on each section type is as follows :

< O-RAN.WG4.CUS.0-R003-v15.00 : Clause 8.3 >

Section Type

Target Scenario

Remarks

0

Idle or Guard Periods

No U-Plane messages are associated with this section type.

1

Most Downlink and Uplink Physical Radio Channels

Common Header Fields: dataDirection (1 bit), payloadVersion (3 bits), filterIndex (4 bits), frameId (8 bits), subframeId (4 bits), slotID (6 bits), symbolId (6 bits).
Section Header Fields: sectionID (12 bits), rb (1 bit), symInc (1 bit), startPrbu (10 bits), numPrbu (8 bits), udCompHdr (8 bits), reserved (1 byte), udCompLen (16 bits), sReSMask1 (12 bits), sReSMask2 (12 bits).
PRB Fields: udCompParam (0, 8, or 16 bits), iSample (1-16 bits), qSample (1-16 bits).

3

PRACH and Mixed-Numerology Channels

Uses same timing header, section header, and PRB fields as Section Type 1.

4

Slot Level Configuration

No U-Plane messages are associated with this section type.

5

UE Scheduling Information

Uses same timing header, section header, and PRB fields as Section Type 1.

6

Channel Information for Specific UE ID

No U-Plane messages are associated with this section type.

7

Listen-Before-Talk (LBT) Procedure

No U-Plane messages are associated with this section type.

8

ACK/NACK Feedback and Wake-up Ready Indication

No U-Plane messages are associated with this section type.

eCPRI Log Example

The sample log is from eCPRI - Wireshark

 

Example 01 >

 

[Frame 1] - IQ Data

Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000000000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000000000 seconds

    [Time delta from previous captured frame: 0.000000000 seconds]

    [Time delta from previous displayed frame: 0.000000000 seconds]

    [Time since reference or first frame: 0.000000000 seconds]

    Frame Number: 1

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x10000014

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: IQ Data (0x00)

        Payload Size: 20

    eCPRI Payload: 12:34:87:65:0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

        PC_ID: 0x1234

        SEQ_ID: 0x8765

        User Data: 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

Data (26 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 22 33 44 55                     ......"3DU

    Data: 0000000000000000000000000000000000000000000022334455

    [Length: 26]

This eCPRI packet is encapsulated within a standard Ethernet frame, the packet leverages eCPRI to manage the transport of IQ data for the U-Plane, featuring a header that ensures proper message identification and ordering, while the payload carries compressed IQ data critical for real-time processing.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10000014, signifying its adherence to O-RAN standards.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "IQ Data" (0x00), denoting U-Plane IQ data transfer.
  • A payload size of 20 bytes is specified, accompanied by a sequence ID (ecpriSeqid) of 0x8765, which supports message ordering within the eAxC stream.
  • The payload contains 26 bytes of user data in hexadecimal format (e.g., 00 00 00 00 00 00 22 33 44 55 ... "3DU"), representing compressed IQ data for transmission.

 

[Frame 2] - Bit Sequence

Frame 2: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000001000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000001000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000001000 seconds]

    Frame Number: 2

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x10010014

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Bit Sequence (0x01)

        Payload Size: 20

    eCPRI Payload: 12:34:87:65:0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

        PC_ID: 0x1234

        SEQ_ID: 0x8765

        User Data: 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

Data (26 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 22 33 44 55                     ......"3DU

    Data: 0000000000000000000000000000000000000000000022334455

    [Length: 26]

This packet is encapsulated within a standard Ethernet frame, the packet utilizes eCPRI to convey control or configuration data, featuring a header that ensures message identification and ordering, while the payload carries bit sequence information critical for synchronizing or managing radio operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:000010 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10001014, signifying its alignment with O-RAN standards.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Bit Sequence" (0x01), indicating a control or synchronization message, distinct from IQ data.
  • A payload size of 20 bytes is specified, accompanied by a sequence ID (ecpriSeqid) of 0x8765, which supports message ordering within the eAxC stream.
  • The payload contains 26 bytes of user data in hexadecimal format (e.g., 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00), representing a bit sequence used for timing or alignment purposes.

 

[Frame 3] - Real-Time Control Data

Frame 3: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000002000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000002000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000002000 seconds]

    Frame Number: 3

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x10020014

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Real-Time Control Data (0x02)

        Payload Size: 20

    eCPRI Payload: 12:34:87:65:0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

        RTC_ID: 0x1234

        SEQ_ID: 0x8765

        User Data: 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

Data (26 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 22 33 44 55                     ......"3DU

    Data: 0000000000000000000000000000000000000000000022334455

    [Length: 26]

The packet is encapsulated within a standard Ethernet frame, the packet leverages eCPRI to deliver C-Plane messages, featuring a header that ensures message identification and ordering, while the payload carries control information essential for coordinating radio functions in real-time 5G operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:000200 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10002014, signifying its alignment with O-RAN standards for real-time control.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Real-Time Control Data" (0x02), indicating a C-Plane control message.
  • A payload size of 20 bytes is specified, accompanied by a sequence ID (ecpriSeqid) of 0x8765, which supports message ordering within the eAxC stream.
  • The payload contains 26 bytes of user data in hexadecimal format (e.g., 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00), representing control data such as scheduling or beamforming commands.

 

[Frame 4] - Real-Time Control Data

Frame 4: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000003000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000003000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000003000 seconds]

    Frame Number: 4

    Frame Length: 68 bytes (544 bits)

    Capture Length: 68 bytes (544 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x10030018

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Generic Data Transfer (0x03)

        Payload Size: 24

    eCPRI Payload: 12:34:56:78:87:65:43:21:0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

        PC_ID: 0x12345678

        SEQ_ID: 0x87654321

        User Data: 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00

Data (26 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 22 33 44 55                     ......"3DU

    Data: 0000000000000000000000000000000000000000000022334455

    [Length: 26]

The packet is.encapsulated within a standard Ethernet frame, the packet utilizes eCPRI to facilitate the transfer of C-Plane real-time control data, featuring a header that ensures message identification and ordering, while the payload carries generic control information critical for managing radio operations in a 5G network.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:000300 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10003018, signifying its alignment with O-RAN standards for generic data transfer.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Generic Data Transfer" (0x03), indicating a C-Plane message for control purposes.
  • A payload size of 24 bytes is specified, accompanied by a sequence ID (ecpriSeqid) of 0x87654321, which supports message ordering within the eAxC stream.
  • The payload contains 26 bytes of user data in hexadecimal format (e.g., 0f:0e:0d:0c:0b:0a:09:08:07:06:05:04:03:02:01:00), representing generic control data for radio configuration or synchronization.

 

[Frame 5] - Remote Memory Access

Frame 5: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000004000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000004000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000004000 seconds]

    Frame Number: 5

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1004001c

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Remote Memory Access (0x04)

        Payload Size: 28

    eCPRI Payload: 11:00:22:33:05:04:03:02:01:00:00:10:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:

        Remote Memory Access ID: 0x11

        0000 .... = Read/Write: Read (0x0)

        .... 0000 = Request/Response: Request (0x0)

        Element ID: 0x2233

        Address: 05:04:03:02:01:00

        Data Length: 16

        User Data: ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00

Data (18 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 33   .............."3

0010  44 55                                             DU

    Data: 000000000000000000000000000022334455

    [Length: 18]

The packet is encapsulated within a standard Ethernet frame, the packet leverages eCPRI to facilitate remote memory operations, featuring a header that ensures message identification and management, while the payload carries data for reading or writing to specific memory addresses, supporting configuration or diagnostic functions in 5G network operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:000400 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10004001c, signifying its alignment with O-RAN standards for remote memory access.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Remote Memory Access" (0x04), indicating a message for memory read/write operations.
  • A payload size of 28 bytes is specified, detailing a Remote Memory Access ID of 0x11, an operation type of "Read/Write: Read Request" (0x00), an Element ID of 0x2233, and an Address of 05:04:03:02:01:00.
  • The payload contains 18 bytes of user data in hexadecimal format (e.g., ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00), representing the data associated with the memory access request.

[Frame 10] - One-Way Delay Measurement

Frame 10: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000009000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000009000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000009000 seconds]

    Frame Number: 10

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1005002a

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: One-Way Delay Measurement (0x05)

        Payload Size: 42

    eCPRI Payload: 11:00:00:00:45:b1:11:49:1c:41:78:f4:00:00:00:00:00:b7:80:00:dd:dd:dd:dd:

        Measurement ID: 0x11

        Action Type: Request (0x00)

        Time Stamp: 00:00:45:b1:11:49:1c:41:78:f4

            Seconds: 1169232201s

            Nanoseconds: 474052852ns

        Compensation Value: 12025856 = 183.500000ns

        User Data: dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd:dd

Data (4 bytes)

The packet  carries the eCPRI-specific structure for a One-Way Delay Measurement message. Encapsulated within a standard Ethernet frame, the packet leverages eCPRI to perform latency measurements, featuring a header that ensures message identification and management, while the payload carries timestamp and measurement data critical for assessing fronthaul delay in 5G network operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:000900 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10005002a, signifying its alignment with O-RAN standards for delay measurement.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "One-Way Delay Measurement" (0x05), indicating a message for latency assessment.
  • A payload size of 42 bytes is specified, detailing a Measurement ID of 0x11, an Action Type of "Request" (0x00), a Time Stamp of 00:00:45:b1:11:49:1c:41:78:f4 (11692322016 nanoseconds), and a Compensation Value of 474052852ns.
  • The payload contains 4 bytes of dummy data (e.g., dd:dd:dd:dd:dd:dd:dd:dd), serving as padding for the delay measurement message.

 

[Frame 11] - Remote Reset

Frame 11: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000010000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000010000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000010000 seconds]

    Frame Number: 11

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1006000a

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Remote Reset (0x06)

        Payload Size: 10

    eCPRI Payload: 11:22:00:06:05:04:03:02:01:00

        Reset ID: 0x1122

        Reset Code Op: Reserved (0x00)

        User Data: 06:05:04:03:02:01:00

Data (36 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0020  22 33 44 55                                       "3DU

    Data: 000000000000000000000000000000000000000000000000000000000000000022334455

    [Length: 36]

The packet carries the eCPRI-specific structure for a Remote Reset message. Encapsulated within a standard Ethernet frame, the packet utilizes eCPRI to initiate a reset operation on the remote unit, featuring a header that ensures message identification and management, while the payload carries minimal data to trigger the reset process, supporting maintenance and recovery functions in 5G network operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:001000 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10006000a, signifying its alignment with O-RAN standards for remote reset operations.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Remote Reset" (0x06), indicating a message to initiate a reset on the target unit.
  • A payload size of 10 bytes is specified, with a Remote Reset ID of 0x1122, identifying the specific reset operation.
  • The payload contains 36 bytes of user data in hexadecimal format (e.g., 06:05:04:03:02:01:00), representing minimal data required to trigger the reset process.

 

[Frame 16] - Event Indication

Frame 16: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000015000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000015000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000015000 seconds]

    Frame Number: 16

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1007000c

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Event Indication (0x07)

        Payload Size: 12

    eCPRI Payload: 11:00:33:01:ff:ff:00:00:aa:aa:aa:aa

        Event ID: 0x11

        Event Type: Fault(s) Indication (0x00)

        Sequence Number: 51

        Number of Faults/Notifications: 1

        #1: Element: ff:ff:00:00:aa:aa:aa:aa

            Element ID: Fault/Notification applicable for all Elements (0xffff)

            0000 .... = Raise/Cease: Raise a fault (0x0)

            .... 0000 0000 0000 = Fault/Notification: General Userplane HW Fault (0x000)

            Additional Information: 0xaaaaaaaa

Data (34 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 33   .............."3

0020  44 55                                             DU

    Data: 00000000000000000000000000000000000000000000000000000000000022334455

    [Length: 34]

The packet carries the eCPRI-specific structure for an Event Indication message. Encapsulated within a standard Ethernet frame, the packet leverages eCPRI to report event notifications, featuring a header that ensures message identification and management, while the payload carries details of faults or status changes, supporting monitoring and fault management in 5G network operations.

  • The packet is encapsulated within an Ethernet II frame, with source and destination MAC addresses (e.g., WandelGol_88:4e:ff and WandelGol_00:00:00) identifying the network endpoints, captured on February 13, 2019, at 10:36:46:015000 Eastern Standard Time.
  • The eCPRI protocol is indicated by a protocol revision field of 0x10007000c, signifying its alignment with O-RAN standards for event indication.
  • The eCPRI header includes a reserved field set to zero, a protocol version of 1, and a message type of "Event Indication" (0x07), indicating a message for reporting events or faults.
  • A payload size of 12 bytes is specified, detailing an Event ID of 0x11, an Event Type of "Fault(s) Indication" (0x00), a Sequence Number of 51, and an Element ID of 0xffff (applicable to all elements).
  • The payload contains 34 bytes of user data, including a Raise/Cease indication (0x00 for Raise), a Fault/Notification type (0x0000 for General Userplane HW Fault), and additional information (0xaaaaaaaa), representing the fault event details.

 

[Frame 17] - Event Indication

Frame 17: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000016000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000016000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000016000 seconds]

    Frame Number: 17

    Frame Length: 64 bytes (512 bits)

    Capture Length: 64 bytes (512 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1007000c

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Event Indication (0x07)

        Payload Size: 12

    eCPRI Payload: 11:02:33:01:ff:fe:24:00:aa:aa:aa:aa

        Event ID: 0x11

        Event Type: Notification(s) Indication (0x02)

        Sequence Number: 51

        Number of Faults/Notifications: 1

        #1: Element: ff:fe:24:00:aa:aa:aa:aa

            Element ID: Vendor specific usage (0xfffe)

            0010 .... = Raise/Cease: Reserved (0x2)

            .... 0100 0000 0000 = Fault/Notification: Unknown message type received (0x400)

            Additional Information: 0xaaaaaaaa

Data (34 bytes)

 

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 33   .............."3

0020  44 55                                             DU

    Data: 00000000000000000000000000000000000000000000000000000000000022334455

    [Length: 34]

 

[Frame 18] - Event Indication

Frame 18: 41 bytes on wire (328 bits), 41 bytes captured (328 bits)

    Encapsulation type: Ethernet (1)

    Arrival Time: Feb 13, 2019 10:36:46.000017000 Eastern Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1550072206.000017000 seconds

    [Time delta from previous captured frame: 0.000001000 seconds]

    [Time delta from previous displayed frame: 0.000001000 seconds]

    [Time since reference or first frame: 0.000017000 seconds]

    Frame Number: 18

    Frame Length: 41 bytes (328 bits)

    Capture Length: 41 bytes (328 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:ecpri:data]

Ethernet II, Src: WandelGo_88:4e:ff (00:80:16:88:4e:ff), Dst: WandelGo_00:00:00 (00:80:16:00:00:00)

    Destination: WandelGo_00:00:00 (00:80:16:00:00:00)

        Address: WandelGo_00:00:00 (00:80:16:00:00:00)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        Address: WandelGo_88:4e:ff (00:80:16:88:4e:ff)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: eCPRI (0xaefe)

evolved Common Public Radio Interface

    eCPRI Common Header: 0x1107000c

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...1 = C-Bit: 1

        Message Type: Event Indication (0x07)

        Payload Size: 12

    eCPRI Payload: 11:00:33:01:ff:ff:00:00:aa:aa:aa:aa

        Event ID: 0x11

        Event Type: Fault(s) Indication (0x00)

        Sequence Number: 51

        Number of Faults/Notifications: 1

        #1: Element: ff:ff:00:00:aa:aa:aa:aa

            Element ID: Fault/Notification applicable for all Elements (0xffff)

            0000 .... = Raise/Cease: Raise a fault (0x0)

            .... 0000 0000 0000 = Fault/Notification: General Userplane HW Fault (0x000)

            Additional Information: 0xaaaaaaaa

evolved Common Public Radio Interface

    eCPRI Common Header: 0x10070004

        0001 .... = Protocol Revision: 1

        .... 000. = Reserved: 0

        .... ...0 = C-Bit: 0

        Message Type: Event Indication (0x07)

        Payload Size: 4

    eCPRI Payload: 11:01:33:00

        Event ID: 0x11

        Event Type: Fault(s) Indication Acknowledge (0x01)

        Sequence Number: 51

        Number of Faults/Notifications: 0

Data (3 bytes)

 

0000  22 33 44                                          "3D

    Data: 223344

    [Length: 3]

Reference