Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Solution and Validation Key Parameters

The test network consists of Fronthaul, Midhaul, Backhaul, and Service Edge segments. Refer to .

  • Fronthaul segment: Uses a spine-leaf access topology, connecting to redundant HSR (AG1.1/1.2) nodes, which also handle 4G pre-aggregation and 5G HSR functions. The pre-aggregation AG1 nodes provide connectivity for O-DUs and include additional emulated access insertion points (RT) for scalability.
  • Midhaul and Backhaul segments: These are represented by ring topologies and serve aggregation and core roles, but they are not the focus of this discussion.
Figure 1: 5G Fronthaul Lab Topology A diagram of a computer Description automatically generated

Supported Platforms and Positioning

Table 1: Supported Platforms and Positioning
Platform Device Junos OS Release
DUT Platforms ACX7100-48L, ACX7509, ACX7100-32C Junos OS Evolved 22.3R1-S1.2
Helper Platforms MX204, MX480, PTX1000, MX10003 Junos OS 22.3R1.2/R1.7

Solution Validation Goals

The main goal is to validate that the ACX7100 and ACX7509 platforms can meet the CoS performance requirements for maintaining the reliability and quality of critical 5G Fronthaul traffic between the RU and the DU. Our secondary objective is to verify that the CoS behaviors remain consistent across the mobile backhaul (MBH) topology and other devices at different capture points.

CoS Functionality Goals

For this JVD, we validated CoS operations and functionalities to determine if the topology can deliver the following goals:

  • Classify traffic based on DSCP, 802.1p, and EXP with Packet Loss Priority (PLP) high and low.
  • Preserve QoS codepoints end to end for inner and outer tags.
  • Support ingress classification using Fixed and Behavior Aggregate styles.
  • Create at least six forwarding classes and six queues (all featured platforms support eight)
  • Create and configure two priority queues, one with strict-high priority and the other with low priority. Schedule these queues based on a specified percentage of bandwidth allocation (transmit rate) and buffers. The strict-high priority queue is prioritized ahead of the low priority queue.
  • The port shaper inherits and scales configured scheduling characteristics.
  • Rewrite operations, based on queue assignment, support 802.1p, DSCP, and EXP.
  • For dual-tagged frames, the rewrite operation only affects the outermost tag, leaving the inner tag intact.
  • Latency budgets in scenarios where the network is not congested and is offering a line rate below 100%, the strict-high queue, which has a higher priority, remains within the following latency budget:
    • O-RU-to-O-DU latency equates to averaging ≤10µ per device (≤6µs single DUT).
    • RU-to-SAG latency ≤10ms (expected ≤150µ).
    • Enhanced Common Public Radio Interface (eCPRI) Type 5 One Way Delay Measurement ≤6µ per device.

We also validated how the CoS network manages congestion scenarios including the following key objectives for 5G architectures:

  • Preserve critical eCPRI Fronthaul traffic
  • Maintain traffic priorities across shared links
  • Maintain traffic priorities within and between VPN services that share common links
  • Detect eCPRI Type 7 event indication errors when the network experiences congestion
  • Maintain consistent CoS and resiliency across negative stress conditions (enabled/disable control and data plane daemons, add/delete configurations, and so on.)

Another goal was to identify any limitations, anomalies, and open problem reports (PRs) that were discovered during the validation stages. Whenever possible, we addressed and fixed these PRs, and then validated the fixes as part of the test execution to ensure that everything was functioning as intended.

Solution Validation Non-Goals

Non-goals represent protocols outside the scope of this JVD:

  • Latency validation under congestion scenarios.
  • Multifield classification to forwarding class mapping.
  • Custom drop profiles weighed random early detection (WRED).
  • Temporal transmit rate or buffer (elastic buffer is used).
  • Underlay/Overlay validation other than those specified in the Solution Goals section.
  • Failover and convergence scenarios.
  • End-to-End Timing and Synchronization Distribution: Synchronous Ethernet, IEEE1588v2.
  • SLA Monitoring: RFC 2544, Y.1564, TWAMP, Active Assurance.
  • Telemetry, Management, and Automation.

Failure Scenarios

  • The validation covers the following failure scenarios:
  • Injected failure events (including eCPRI type)
  • Link congestion
  • Queue congestion
  • Process restart