Source-linked AI summary
5G fronthaul-latency and jitter studies of CPRI over ethernet
Divya Chitimalla, Koteswararao Kondepu, Luca Valcarenghi, Massimo Tornatore, Biswanath Mukherjee
TL;DR
CoE could make mobile fronthaul more cost-efficient and reconfigurable, but its ability to meet stringent delay and jitter requirements remains under scrutiny. This study evaluates CoE using FPGA-based experiments and simulations and proposes scheduling Ethernet flows to reduce jitter. In an illustrated schedule, the proposed approach removes inter-packet delay variation for a flow.
Problem
Whether Ethernet can support mobile fronthaul's stringent delay and jitter requirements remains under scrutiny, including a 100 μs delay limit and a 65 ns jitter limit.
Source: §I · p. 2Method
The study evaluates CoE delay and jitter using FPGA pre-synthesis experiments and simulations, and proposes an exhaustive-search scheduler for IEEE 802.1Qbv Ethernet traffic.
Source: §I · p. 2Results
In an illustrated schedule, the flow's jitter is zero because its packets have no variance in inter-packet delay.
Source: §IV · p. 4Takeaways & Limitations
CoE can leverage existing Ethernet interfaces and switching equipment as a cost-efficient mobile-fronthaul solution.
Source: §I · p. 1
Abstract
from arXiv · showhide
Common Public Radio Interface (CPRI) is a successful industry cooperation defining the publicly available specification for the key internal interface of radio base stations between the radio equipment control (REC) and the radio equipment (RE) in the fronthaul of mobile networks. However, CPRI is expensive to deploy, consumes large bandwidth, and currently is statically configured. On the other hand, an Ethernet-based mobile fronthaul will be cost-efficient and more easily reconfigurable. Encapsulating CPRI over Ethernet (CoE) is an attractive solution, but stringent CPRI requirements such as delay and jitter are major challenges that need to be met to make CoE a reality. This study investigates whether CoE can meet delay and jitter requirements by performing FPGA-based Verilog experiments and simulations. Verilog experiments show that CoE encapsulation with fixed Ethernet frame size requires about tens of microseconds. Numerical experiments show that the proposed scheduling policy of CoE flows on Ethernet can reduce jitter when redundant Ethernet capacity is provided. The reduction in jitter can be as large as 1 {\mu}s, hence making Ethernet-based mobile fronthaul a credible technology.
I. INTRODUCTION
CoE could offer a cost-efficient, reconfigurable Ethernet fronthaul, but must meet stringent delay and jitter requirements. This study evaluates CoE and proposes scheduling Ethernet traffic to reduce jitter.
I. INTRODUCTION
- CPRI's expense, difficult switching-equipment design, and stringent delay and jitter requirements motivate a cost-efficient, reconfigurable fronthaul.The cited passage notes that these requirements can be satisfied only with high-speed fronthaul solutions such as optical links.Source: §I · p. 1
- CoE can leverage existing Ethernet interfaces and switching equipment, while Ethernet supports scalable, reconfigurable topologies for mobile fronthaul.The study's considered split places layer 1 and above in the REC and RF functionality in the RE.Source: §I · pp. 1–2
- Ethernet fronthaul must meet CPRI requirements including delay within 100 µs and jitter within 65 ns, leaving CoE's suitability under scrutiny.The study considers the physical-layer functional split, which transports IQ samples between the RE and REC.Source: §I · pp. 1–2
- Prior work left Ethernet-fronthaul jitter unquantified experimentally or in simulation, and did not detail when scheduled traffic can achieve less than 65 ns.The study addresses these gaps with a performance evaluation of CoE delay and jitter.Source: §I · p. 2
- The study evaluates CoE delay and jitter and proposes an exhaustive-search scheduler using IEEE 802.1Qbv to reduce jitter in scheduled Ethernet traffic.Its evaluation combines FPGA pre-synthesis experiments with simulations.Source: §I · p. 2
ERNET (COE) M
The study models CoE delay by accounting for Ethernet-header transmission and switch forwarding, then uses those quantities to assess total overhead and fronthaul distance.
ERNET (COE) M
- Total CoE overhead combines Ethernet-header transmission delay with switch hop delay, modeled for a worst-case store-and-forward switch.The header contribution depends on the number of Ethernet frames; the study fixes Ethernet header length at 44 bytes.Source: ERNET (COE) M · p. 4
- Using 10G Ethernet, the study computes CoE parameters for CPRI options 1–6 (614.4–6144.0 Mb/s) with 1250-byte and 1500-byte Ethernet payloads; reported hop delays are for a single hop.Source: ERNET (COE) M · p. 4
- The distance calculation subtracts total CoE overhead from a 246 μs round-trip-time allowance and divides by 10 μs/km fiber propagation delay.The study considers multi-hop paths in which each hop corresponds to an Ethernet switch.Source: ERNET (COE) M · p. 4
IV. JITTER STUDY OF COE
The study defines worst-case packet-to-packet jitter and proposes periodic fixed-timeslot scheduling of CoE flows to reduce it. Its example shows that proper scheduling can eliminate jitter.
IV. JITTER STUDY OF COE
- Assigning fixed timeslots to each CoE flow is proposed to reduce Ethernet-fronthaul jitter; the scheduling pattern repeats over its shortest interval, L_S.The example multiplexes three flows on a 10 Gbps interface.Source: §IV · p. 4
- Worst-case jitter is the largest across flows of each flow’s maximum minus minimum receiver packet delay.The delay is measured at the REC receiver.Source: §IV · p. 4
- 1.6 µs is flow 1’s example jitter; proper scheduling reduces it to zero by removing inter-packet delay variance.The example’s highest and lowest inter-packet delays are 2.4 µs and 0.8 µs.Source: §IV · p. 4
A. CoE
In the illustrated three-flow case, every C-FIT flow order produces zero jitter. C-FIT considers flow orders and selects a schedule with the lowest jitter, while FAT resolves conflicts by assigning available slots.
A. CoE
- FAT resolves conflicts by moving packets to the first available timeslot, while C-FIT tries flow orders and selects the schedule with lowest jitter.C-FIT combines schedules using sliding offsets before moving any remaining conflicts to the nearest open slot.Source: A. CoE · p. 6
- For the example, FAT assigns flow 1 slots at 0, 1.6, 3.2, and 4.8 µs, flow 2 at 0.8 and 4.0 µs, and flow 3 at 2.4 µs.For flow order {1 > 2 > 3}, C-FIT produces the same schedule.Source: A. CoE · p. 6
- Zero jitter results from all C-FIT flow orders in the illustrated scenario, though the number of orders grows exponentially with flow count.The authors state complexity is not a major concern because fronthaul switches multiplex a limited number of flows.Source: A. CoE · p. 6
ALGORITHM 1: BASIC-OFFSET ALGORITHM
The basic-offset algorithm constructs a periodic Ethernet schedule for synchronized CoE flows. It uses packet transmission times and a common scheduling interval to place packets in timeslots.
ALGORITHM 1: BASIC-OFFSET ALGORITHM
- The algorithm takes synchronized CoE flows as input and outputs their schedule on the Ethernet link.It first calculates each flow’s packet transmission time.Source: ALGORITHM 1: BASIC-OFFSET ALGORITHM · p. 6
- The scheduling length L_S is the lowest common multiple of packet transmission periods, establishing the interval over which the schedule repeats.The algorithm also calculates the number of timeslots for each flow within L_S.Source: ALGORITHM 1: BASIC-OFFSET ALGORITHM · p. 6
- For each flow, the algorithm places packet start and end times using its offset and packet transmission period.The packet interval is recorded in a matrix for the flow’s schedule.Source: ALGORITHM 1: BASIC-OFFSET ALGORITHM · pp. 6–7
MATCOMBINE SUBROUTINE
matcombine merges two input schedules into a non-conflicting schedule, first trying a shifted placement and then relocating conflicts.
MATCOMBINE SUBROUTINE
- matcombine takes two schedules and initializes a combined matrix sized to hold both schedules.It starts with the longer schedule and uses the other as the temporary schedule.Source: MATCOMBINE SUBROUTINE · p. 7
- It shifts the temporary schedule by multiples of T_ETS to seek a non-conflicting placement.If this succeeds, the shifted schedule is copied into the combined matrix.Source: MATCOMBINE SUBROUTINE · p. 7
- If shifting fails, conflicting packets are moved to the nearest open timeslot that can fit them.Non-conflicting packets are copied into the combined schedule first.Source: MATCOMBINE SUBROUTINE · p. 7
end ALGORITHM 3: FIRST AVAILABLE TIMESLOT (FAT) FOR BENCHMARK
The section evaluates CoE encapsulation delay and describes a first-available-timeslot benchmark that constructs non-conflicting packet schedules. Delay varies with CPRI line rate, Ethernet payload size, and the number of Ethernet switches crossed.
end ALGORITHM 3: FIRST AVAILABLE TIMESLOT (FAT) FOR BENCHMARK
- The FAT benchmark takes a basic-offset flow schedule as input and returns a non-conflicting CoE packet schedule by placing packets in available timeslots.Its combine procedure adds non-conflicting packets and searches for an open timeslot that fits each conflicting packet.Source: end ALGORITHM 3: FIRST AVAILABLE… · p. 7
A. Ethernet Encapsulation Delay
- The encapsulation evaluation uses PRBS data, Verilog HDL, and ModelSim to assess delay across CPRI line rates and Ethernet payload sizes.The study also relates delay to fronthaul distance.Source: A. Ethernet Encapsulation Delay · p. 7
- The Ethernet MAC overhead is 19.2 ns per frame, yielding 11.8 μs across 615 frames for CPRI option 1.The Verilog evaluation generates data continuously, including during header generation.Source: A. Ethernet Encapsulation Delay · p. 7
- Encapsulation delay decreases as CPRI line rate increases and as Ethernet payload size decreases; additional switch hops reduce supported fronthaul distance.The distance results use a 1250-byte Ethernet payload and account for store-and-forward delay at each switch.Source: A. Ethernet Encapsulation Delay · p. 7, Figure 6 · p. 8
B. Jitt
The section examines jitter as Ethernet load and flow count vary, and includes comparisons of scheduled CoE traffic. The supplied passages report load-ratio inflection points for figures covering different flow counts.
B. Jitt
- For 1–3 flows, Figure 11 identifies an acceptable-jitter inflection point at Ethernet load ratio 0.35.The figure concerns jitter versus load and line-rate ratio.Source: B. Jitt · p. 9, Figure 11 · p. 9
- For six flows, Figure 12 reports an acceptable-jitter inflection point at load ratio 0.36.The surrounding passage also describes jitter as increasing with load ratio.Source: B. Jitt · p. 9, Figure 12 · p. 9
VI. CONCLUS
The conclusion presents CoE over Ethernet as an alternative for mobile fronthaul and discusses scheduling CoE flows to reduce jitter.
VI. CONCLUS
- The conclusion presents CoE over Ethernet as a possible stepping stone for mobile fronthaul.It frames Ethernet as an alternative to CPRI.Source: §VI · p. 9
- The section discusses scheduling CoE flows over Ethernet, including comb-fitting and a FAT algorithm.Source: §VI · p. 9
- The reported findings mention jitter reduction with the proposed scheduling and slight delay in a multi-hop setting.Source: §VI · p. 9
REFERE ENCES
The references include a Cisco visual-networking resource and research citations concerning mobile fronthaul and Cloud RAN.
REFERE ENCES
- A Cisco visual-networking resource appears in the references as citation [2].Source: REFERE ENCES · p. 9
- Another reference fragment concerns architecture for fronthaul and optical networking.Source: REFERE ENCES · p. 9
- The bibliography includes a cited work titled “Cloud RAN for Mobile” followed by a conference reference.Source: REFERE ENCES · p. 9