5G xHaul design with SR MPLS

1

(% class="row" %)

2

(((

3

(% class="col-xs-12 col-sm-7 test-report-content" %)

(((

----

This setup emulates a realistic 5G xHaul transport network, supporting both fronthaul and midhaul traffic types in a converged environment. The goal is to validate the ability of SR-MPLS-based designs to meet stringent latency and synchronization requirements for time-sensitive 5G services, particularly for eCPRI-based fronthaul and business traffic over the same infrastructure. The scenario reflects typical deployments in operator networks where differentiated QoS and precise timing are critical for maintaining service quality across access, pre-aggregation, and aggregation layers. We created a 5G xHaul setup consisting of two routers at the aggregation layer, two others at the pre-aggregation layer, and nine at the access layer. We implemented L3VPNs between access routers and validated their functionality by checking route distribution and forwarding behavior. When best-effort traffic exceeded the uplink capabilities of the access node, DUTs dropped excess packets from the best-effort queue only on the oversubscribed interface in the outgoing direction. Meanwhile, we mapped the DSCP value CS6 to the EXP value 6, which allows the next hop to classify incoming MPLS packets as either best effort or low latency. The reverse direction exhibited the same behavior.

8

During VPWS testing, we marked high-priority traffic using the 802.1p priority bit, which was mapped to EXP 6. Under congestion, only lower-priority traffic experienced drops, while latency for high-priority traffic remained within acceptable limits. Traffic between the access and pre-aggregation nodes carries low latency (digital antenna traffic – eCPRI) and regular business internet traffic (BE). Routers often send eCPRI traffic as Ethernet. Hence, classification based on 802.1p bits and the outgoing MPLS EXP remarking is required. We measured less than 26 µs one-way latency between four xHaul endpoint combinations, confirming their suitability for fronthaul use as defined by the 'High75' category in the O-RAN Alliance WG9 transport requirements. 87.5 % of the tested combinations exhibited latency below 100 µs, so they fit the "High100" category for standard New Radio performance. The remaining 12.5% of the combinations showed less than 200 µs latency - still suitable for midhaul but difficult for fronthaul connections. Following this, we connected a grandmaster clock source to the aggregation routers, while the access routers acted as Boundary Clocks, measuring the Precision Time Protocol (PTP) Time Error (TE) values at the access layer. These TE values continued in Class C limit ITU-T G.8275.1 while the traffic was congested, showing that DUTs can hold precise time synchronization throughout the xHaul network.

9

10

11

(% class="table-bordered" %)

12

|=Latency Class|=Max. One-way Frame Delay Performance|=Use case

13

|High25|25 µs|Ultra-low latency performance

14

|High75|75 µs|For full NR performance with fiber lengths in 10km range

15

|High100|100 µs|For standard NR performance with fiber lengths in 10km range

16

|High200|200 µs|For installations with fiber lengths in 30km range

17

|High500|500 µs|Large latency installations > 30 km

18

|Medium|1 ms|User Plane (slow) & C&M Plane (fast)

19

|Low|100 ms|Control & Management Plane

20

21

Table 35: Fronthaul One-way Delay requirements

22

23

24

To evaluate the 5G xHaul design, we ensured compliance with ITU-T G.8275.1 for clock synchronization and applied IEEE 802.1CM TSN Profile A to prioritize fronthaul eCPRI traffic. Packet classification was conducted using DSCP for routed traffic and 802.1p (CoS) for Layer 2 traffic, with specific prioritization for PTP packets. The testing procedure involved configuring network-wide time synchronization following the G.8275.1 Telecom Profile, then injecting a mix of best-effort and low-latency flows to significantly oversubscribe the xHaul network. As a result, we confirmed that clock synchronization was maintained despite traffic congestion and that the DUTs kept one-way latency for eCPRI streams below 100 μs, as required for fronthaul performance.

25

26

[[Figure 89: 5G xhaul over SR-MPLS>>image:434086832804724737_SRMPLS-23-5gxhaul-Generic-1-v1.png||alt="Figure 89" width="550"]]

27

28

29

(% class="table-bordered" %)

30

|=Access|=Aggregation|=Pre-Aggregation|=Traffic Generator

31

|(((

32