5G xHaul design with SR MPLS


A 5G xHaul setup, consisting of two routers at the aggregation layer, two others at the pre-aggregation layer, and, lastly, nine routers at the access layer, was created. L3VPN testing was performed in between access routers. When best-effort traffic exceeded the uplink capabilities of the access node, excess packets were dropped from the best-effort queue only on the oversubscribed interface in the outgoing direction. Meanwhile, the DSCP value CS6 was mapped to the EXP value 6, which allows the next hop to classify incoming MPLS packets as either BE or low-latency. The reverse direction exhibited the same behavior.
VPWS tests also made use of a priority bit (802.1p) mapped into EXP 6 for high-priority traffic; as a result, any drops during congestion happened, and acceptable latency performance was confirmed. Traffic between the access node and pre-aggregation node carries both low-latency (digital antenna traffic – eCPRI) as well as regular business internet traffic (BE). eCPRI traffic is often sent as Ethernet. Hence, classification based on 802.1p bits, as well as remarking of the outgoing MPLS EXP, is required. We measured less than 26 µs one-way latency between four xHaul endpoint combinations, which confirms the full fitness of these combinations for fronthaul ("High75" in the O-RAN Alliance WG9 transport requirements specification). In total, 87.5 % of the tested combinations exhibited latency below 100 µs, so they were fit for the "High100" category for standard New Radio performance. The remaining 12.5% of the combinations showed less than 200 µs latency - still good for midhaul but difficult for fronthaul connections. Following this, a grandmaster clock source was connected to the aggregation routers while the access routers were acting 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 precise time synchronization was held throughout the xHaul network.

Latency ClassMax. One-way Frame Delay PerformanceUse case
High2525 µsUltra-low latency performance
High7575 µsFor full NR performance with fiber lengths in 10km range
High100100 µsFor standard NR performance with fiber lengths in 10km range
High200200 µsFor installations with fiber lengths in 30km range
High500500 µsLarge latency installations > 30 km
Medium1 msUser Plane (slow) & C&M Plane (fast)
Low100 msControl & Management Plane

Table 35: Fronthaul One-way Delay requirements

Key Elements for the test:

  • ITU-T G.8275.1 Telecom Profile for Clock Synchronization
  • Packet Classification based on DSCP field for routed traffic and COS field for L2 traffic
  • IEEE 802.1CM TSN Profile A for Fronthaul to prioritize eCPRI traffic
  • Prioritization of PTP packets

Test Procedure includes following items:

  • Provide  network-wide time synchronization with G.8275.1 profile
  • Send multiple best-effort, as well as low-latency flows, heavily oversubscribing the 5G xHaul network

As a result, make sure that:

  • Clock synchronization is not affected by oversubscription
  • One-way latency of eCPRI streams is kept in the budget of 100 usec
Figure 89

Figure 89: 5G xhaul over SR-MPLS

AccessAggregationPre-AggregationTraffic Generator

Arista 7280R3,
Arrcus S9600-72XC,
Ciena 5134,
Ericsson Router6678,
H3C CR16000-M1A,
Huawei  NetEngine 8000 M14,
Juniper ACX7024,
Keysight IxNetwork,
Nokia 7730 SXR-1x-44s

Juniper PTX10002-36QDD,
Nokia 7250 IXR-e2

Arrcus S9600-72XC,
Ciena 8140 Coherent Metro Router

Keysight IxNetwork

Table 36: 5G xHaul design with SR MPLS - IS-IS