5G xHaul design with SRv6

The 5G xHaul design implementation using SRv6 aims to simplify transport network operations, enhance scalability, and improve the integration of fronthaul, midhaul, and backhaul components. This use case explores SRv6 as a unified architecture while validating its multi-vendor interoperability.
        
Latency Requirements and Classification in 5G xHaul:
    
The O-RAN Working Group 9 (WG9) defines latency thresholds for transport networks, ensuring compliance with strict latency constraints required for fronthaul deployments. These latency budgets must be adhered for optimal performance.
For instance, achieving standard NR performance requires a maximum one-way latency of 100 µs between the O-RU (O-RAN Radio Unit) and O-DU (O-RAN Distributed Unit), as outlined in O-RAN WG9 XTRP-REQ v01.00 ("Xhaul Transport Requirements", November 2020 [19] Table 3).

Our test focused on verifying whether  SRv6 could meet the stringent latency requirement of eCPRI-based fronthaul traffic between the RU and DU, even under network congestion.
The Access nodes implemented traffic classification using Ethernet Priority Code Point (PCP) bits and IPv6 Traffic Class (TC) field to ensure deterministic QoS enforcement in a congested 5G xHaul network. These classification mechanisms were essential for prioritizing latency-sensitive fronthaul traffic, such as eCPRI and PTP synchronization packets(PCP=5, TC=EF Expedited Forwarding), while allowing best-effort traffic to be handled appropriately (PCP=0, TC= CS0 Default Forwarding).
 Furthermore, our test adopted EEE 802.1CM Time-Sensitive Networking (TSN) Profile A to ensure low-latency, high-reliability transport for eCPRI traffic in a congested 5G xHaul network.  

We used  IxNetwork Fronthaul Traffic emulation to generate realistic  RU-DU eCPRI traffic, measuring key performance indicators such as packet loss, latency, and delay variation. The O-DU was configured with two 100MHz FR1 carriers, with a  30KHz subcarrier spacing and block floating point compression method with IQ bit width set to 9 while the  ORAN Fronthaul Wizard helped establish  U-plane and C-plane traffic, mimicking real-world eCPRI patterns.
     
The links between the access and pre-aggregation segments were 10Gbps, which was intentionally used to create congestion and evaluate how TSN Profile A handles traffic prioritization.
This testbed carried fronthaul traffic over L2VPN services, while background traffic was transported over L3VPN services at  96% line rate. Due to the additional  SRv6 header overhead in the core, the background traffic approached 10Gbps, effectively utilizing the network's full capacity
Additionally,  PTP (Precision Time Protocol) synchronization was monitored to verify the stability of timing across the transport network.

Despite network congestion, the fronthaul traffic carried over SRv6 L2VPN services experienced no packet loss. Also, the latency remained within the acceptable range of 20.05 µs- 29.7 µs O-RU ->O-DU direction and 20.07 µs- 24.250 µs  O-DU ->O-RU direction.
The following Table shows the delay values for all the test pairs for access and Pre aggregation nodes:

While these measurements give us the raw fronthaul router latency, we must also consider the fiber latency budget to determine compliance with O-RAN latency classes. Light propagation in fiber is approximately 4.9 μs per kilometer (https://www.m2optics.com/blog/bid/70587/Calculating-Optical-Fiber-Latency), and this latency directly contributes to the total E2E delay budget.
Each latency class's total end-to-end (E2E) latency budget is split between the fiber latency and the access + pre-aggregation router latency. For example:
High75 allows a total of 75 µs, with 49 µs consumed by fiber (assuming a 10 km fiber length), leaving a 26 µs budget for router latency.
High100 has a 100 µs E2E budget, with 49 µs fiber latency and a remaining 51 µs router budget.
High200 allows for 200 µs in total, with 147 µs allocated to fiber latency (for 30 km fiber length), leaving 53 µs for router latency.

The following table summarizes our measured results and maps them to the corresponding O-RAN latency classes based on the defined budgets

PTP synchronization remained stable throughout the test, with no timing disruptions or packet loss observed. The background traffic over L3VPN experienced packet loss due to congestion, demonstrating that TSN Profile A prioritization effectively prioritized time-sensitive fronthaul traffic.

Our tests confirmed that even under heavy network oversubscription, with multiple best-effort and eCPRI flows generated simultaneously, clock synchronization remained stable, ensuring reliable timing for fronthaul operations. Additionally, the one-way latency of eCPRI streams consistently met the required limits, staying within the 26 µs and 51 µs budgets defined by O-RAN WG9.