s Ethernet/IP-based. Connectivity options include cus- tom frame format, eCPRI or RoE. Ethernet-based I/Q transport depends on time-sensitive networking capabilities in the Ethernet standard (not discussed in this document) to guaran- tee frame timing. As shown in the Fig. 2-37, different options in the RoE/eCPRI standards allow for map- ping of split option 7 to standardized formats. Standardization efforts (e.g., xRAN Fronthaul Working Group) are ongoing to define Ethernet/packet format across eCPRI and RoE. For illustrative purposes, Fig. 2-38 shows the protocol mapping for eCPRI or IEEE1914.3, including optional UDP/IP layers. TCP or SCTP is not considered a realistic protocol option given the strict requirements for latency that do not leave physical time for Ack/Nack and retransmission protocol support. The eCPRI7 standard protocol layering relies on UDP/IP/Ethernet addressing for source/ destination routing. Time synchronization is provided through standard IP mechanisms such as IEEE1588. OAM and control and management also rely on standard IEEE/Ethernet mechanisms. Both RoE and eCPRI use a custom header including a flow identifier (RoE) or physical channel ID (eCPRI) to define the antenna/port/flow/link that bits are carried for. Assuming large payload/frame sizes to be supported (few KB/OFDM frame), the dozens of bytes of Ethernet and protocol framing overhead constitute a very small percentage efficiency loss. Ethernet overheads for packetization and synchronization are estimated to be ~ 10%. The eCPRI protocol is explicitly designed with strict separation of User and Control Planes in mind, allowing for a efficient hardware or software implementation like shown in Fig. 2-39. Chapter 2 System components, requirements, and interfaces 87 Packet Switched Circuit Switched RoE/1904.3 eCPRI OBSAI Structure Structure IQ Samples Bit sequences Native aware agnostic Split Option 7/8 Split Option 1-6 Split Option 8 Frequency Domain I/Q Domain I/Q Split Option 8 Split Option 7 FIGURE 2-37 Ethernet-based sample tran