Results Summary and Analysis

Congestion Scenarios

The validation includes a variety of congestion scenarios, which are outlined in the Test Objectives section. Congestion constitutes one or more conditions where traffic exceeds the configured scheduler transmit rate, shaped rate, or port speed and results in an expected traffic loss. The major objective is to ensure critical priority traffic is uninterrupted even during periods of congestion and that during congestion, high-priority delay-sensitive traffic is given preference.

During key congestion events, the following observations are recorded. For more information, see the full test report:

• Low-latency queue (FC-LLQ) is serviced ahead of strict-high, high, medium-high, medium-low, and low priority queues and given preferential treatment to preserve the latency budget. FC-LLQ does not exceed the defined allowance when a shaping rate is configured.
• Strict-high queue (FC-SIGNALING) is serviced ahead of high, medium-high, medium-low, and low queues. FC-SIGNALING does not exceed the defined allowance when a shaping rate is configured.
• High queue (FC-CONTROL) is serviced ahead of medium-high, medium-low, and low queues. FC-CONTROL does not exceed the defined allowance when a shaping rate is configured.
• Medium-high queue (FC-REALTIME) is serviced ahead of medium-low and low queues. FC-REALTIME does not exceed the defined allowance when a shaping rate is configured.
• Low-priority queues (FC-HIGH, FC-MEDIUM, and FC-LOW) are serviced based on configured transmit rate percentages of the remaining port speed. Low-priority queues are serviced as WFQ when operating in excess of the transmit rate and bandwidth is available.
• Low-priority remainder queue (FC-BEST-EFFORT) is serviced only when unused bandwidth is available based on the intentionality of the scheduler configuration.
• During high congestion periods, queues operating within their configured bandwidth (in-profile) are guaranteed without packet drops.
• Critical eCPRI or ORAN traffic flows are assigned to priority queues and meet the given SLAs.
• Scheduler percentages correctly inherit the configured port-shaper as port speed.
• Queue shaping rate is deducted from total port speed with transmit-rates applied to the remaining bandwidth.
• Priority hierarchies are honored across and within VPN services that share common links.
• Traffic is transmitted up to 99% port speed under normal conditions where multi-level priorities are validated.
• Latency results are always measured in microseconds (µs).

Latency Budget Validation

5G xHaul infrastructure defines strict latency budgets, particularly in the fronthaul segment. O-RAN WG9 technical specification (O-RAN.WG9.XTRP-REQ-v01.00) for transport requirements provides guidelines for a maximum one-way latency budget of 100µs for the fronthaul. This budget includes latency incurred by the fiber runs at approximately 4.9µs/km and transit nodes. The objective of the JVD is to deliver a solution with latency performance within the acceptable range from O-RU to O-DU, approximately ≤10µs per node. The ACX7000 platforms selected for CSR and HSR roles are shown to consistently achieve an average transit latency of ≤4-6µs. In addition, the ability to preserve an objective latency budget for priority flows during conditions of congestion. This is a significant paradigm shift from the requirements of earlier 4G architectures.

When measuring a traffic delay, there should not be any traffic dropping from the queue under test since this invalidates the goal of capturing transit latency. The best measure of individual device performance is shown by the standalone topology 1. Additional topologies provide key insight into the overall network performance. Three permutations for each CSR and HSR device type are validated.

Topology 1a: ACX7024

Topology 1a (Figure 3) is used to validate the performance of the ACX7024 platform in the CSR role. The test equipment emulates O-RU and O-DU devices and does not include self-latency. For each scenario, the results are provided across different frame sizes with either continuous or burst traffic patterns. Latency is measured in microseconds (µs).

Figure 3: Topology 1a ACX7024 Standalone DUT

The following table describes the ACX7024 performance when traffic is sent only to the low-latency queue without background traffic. No queues are congested during this time.

The following table includes continuous background traffic up to 99%-line rate with encapsulation overhead considerations for Topology 1a with ACX7024. The performance of the low-latency queue (FC-LLQ) is measured in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. In these scenarios, lower priority queues are also maintained below 10µs average latency goal.

The following table includes burst traffic type rather than continuous for Topology 1a with ACX7024, measuring the performance of the low-latency queue (FC-LLQ) in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. In these scenarios, lower priority queues are also maintained well below the 10µs average latency goal.

For the next table, observe the impact on the LLQ when creating congestion to the point of traffic discarding in the oversubscribed strict-high queue. The intentionality of the LLQ design prevents such scenarios from disrupting the low-latency queue. From the results, you can observe that the average latency budget is ≤6µs and well below the goal of 10µs.

Topology 1b: ACX7100-32C

In Topology 1b, the same test scenarios are executed while moving to the HSR role with the examination of ACX7100-32C performance. Once again, the test equipment emulates O-RU and O-DU without self-latency. There is no physical CSR. In this case, the performance of the single HSR device is captured. For each scenario, the results are provided across different frame sizes with either continuous or burst traffic patterns. Latency is measured in microseconds (µs).

Figure 4: Topology 1b ACX7100-32C Standalone DUT

The following table describes the Topology 1b ACX7100-32C performance when traffic is sent only to the LLQ without background traffic. No queues are congested during this time.

The following table includes continuous background traffic up to 99%-line rate with encapsulation overhead considerations for Topology 1b with ACX7100-32C. The performance of the low-latency queue is measured in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. All queues are maintained below 10µs average latency, with LLQ operating at <6µs.

The following table includes burst traffic type rather than continuous for Topology 1b with ACX7100-32C, measuring the performance of the low-latency queue in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. In these scenarios, all queues are transmitted <6µs, with LLQ having slightly better performance.

In the next table, look at the impact on the LLQ when creating congestion to the point of traffic discarding in the oversubscribed strict-high queue. The intentionality of the LLQ design prevents such scenarios from disrupting the LLQ. From the results, you can observe that the latency budget is preserved at ~4-5µs and well below the goal of 10µs.

Topology 1c: ACX7509

In Topology 1c, same test scenarios are executed while moving to the second HSR device with the examination of ACX7509 performance. Once again, the test equipment emulates O-RU and O-DU without self-latency. There is no physical CSR in this case as the performance of the single device is captured. For each scenario, the results are provided across different frame sizes with either continuous or burst traffic patterns. Latency is measured in microseconds (µs).

Figure 5: Topology 1c ACX7509 Standalone DUT

The following table describes the Topology 1c ACX7509 performance when traffic is sent only to the LLQ without background traffic. No queues are congested during this time.

The following table includes continuous background traffic up to 99%-line rate with encapsulation overhead considerations for Topology 1c with ACX7509. Performance of the FC-LLQ is measured in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. All priority queues are maintained below 10µs average latency, with LLQ operating ≤6µs.

The following table includes burst traffic type rather than continuous for Topology 1c with ACX7509, measuring the performance of the low-latency queue in conjunction with multi-level priority queues. From the results, you can see that LLQ is given preferential treatment for latency constraints. In these scenarios, all queues are transmitted within ≤6µs, with LLQ having slightly better performance.

The next table provides the impact on the low-latency queue when creating congestion to the point of traffic discarding in the oversubscribed strict-high queue. The intentionality of the design prevents such scenarios from disrupting the LLQ. From the results, you can observe that the latency budget is preserved at <6µs and well below the goal of 10µs.

eCPRI Validation

In this section, the validation is summarized and performed with real eCPRI traffic patterns, O-RAN conformance testing, and handling of eCPRI message types. For all eCPRI and O-RAN conformance validation results with flow data and measurements, see the Test Report. This section captures the most critical data to explain the network and device performance. Latency is measured in microseconds (µs).

The O-RAN and eCPRI test scenarios include several functional permutations with emulated O-DU and RRU. Innovative steps are taken to validate the performance and assurance of 5G eCPRI communications, U-Plane message-type behaviors, and O-RAN conformance. These steps ensure that the featured DUTs are correctly and consistently transporting critical 5G services.

Results evolve across multiple topologies to capture a range of DUT performance characteristics in non-congested and congested scenarios.

Here is the summary of O-RAN and eCPRI test scenarios:

• eCPRI O-RAN Emulation: Leverages a standard IQ Sample file to generate flows.
• O-RAN Conformance: Analyzes messages for conformance to O-RAN specification.
• Crafted eCPRI O-RAN: Produces variable eCPRI payload for comparing latency performance.
• eCPRI Services Validation: Emulates User Plane messages, performing functional and integrity analysis.
• eCPRI Remote Memory Access (Type 4): Performs read or write from/to a specific memory address on the opposite eCPRI node and validates expected success or failure conditions.
• eCPRI Delay Measurement Message (Type 5): Estimates one-way delay between two eCPRI ports.
• eCPRI Remote Reset Message (Type 6): Requests reset of one eCPRI node from another node. This validates expected sender and receiver operations.
• eCPRI Event Indication Message (Type 7): An event notification message to convey information about raised or ceased faults or general notifications. Validation confirms events raised as expected.

Topology 1: Latency Performance with eCPRI

The proceeding test scenarios provide results across topology 1 for single-DUT performance, topology 2 for fronthaul EVPN-VPWS, and topology 3 for fronthaul active-active EVPN Multihoming. The focus of this section is on measuring the LLQ performance in non-congested and heavy congestion scenarios using real eCPRI traffic streams. Background traffic is sent up to 99%-line rate or exceeds the configured bandwidth rate to the point of discarding frames. The validation aims to measure the LLQ performance in these conditions.

For brevity, the data is summarized here with crucial results. For additional test details, including latency measured for all queues, see the Test Report or contact your Juniper representative for more information.

In the following table, real eCPRI traffic is forwarded across topology 1a with ACX7024, topology 1b with ACX7100-32C, and topology 1c with ACX7509 for 10GbE and 100GbE port speeds with continuous or burst traffic patterns. In all cases, the average latency is measured as less than the 10µs objective, with the majority ≤6µs across all three DUTs (ACX7024, ACX7100-32C, and ACX7509).

The following table validates the same scenario as above, introducing heavy congestion with the strict-high queue oversubscribed and dropping traffic. The intentionality of the LLQ design prevents such scenarios from causing significant disruption to the low-latency queue while sending eCPRI traffic streams. From the results, you can observe that the average latency budget is preserved below 10µs. As the port speed increases, the transmission delay associated with congestion typically decreases. As a result, slightly lower latency can be seen on 100GbE port speeds.

The following table continues to increase very heavy congestion with multiple queues simultaneously dropping traffic. In this scenario, both strict-high and high priority queues are oversubscribed. The LLQ implementation prevents disruption to delay sensitive eCPRI traffic, maintaining latency budget. Despite the increased congestion with all queues sending traffic and two queues dropping, latency is preserved below the 10µs objective in all cases. As the port speed increases, the transmission delay associated with congestion typically decreases. As a result, you can see even more benefit as the congestion increases, with measurements consistently in the range of 4-5µs.

Topology 2: Latency Performance with eCPRI over EVPN-VPWS

Topology 2 measures latency in the LLQ over point-to-point EVPN-VPWS services in the fronthaul network segment between CSR and HSR. In topology 2a, the ACX7024 is the CSR DUT, and ACX7100-32C is the HSR DUT. The test equipment emulates the O-RU and O-DU without self-latency. The focus of this section is on measuring the LLQ performance during conditions of non-congested and heavy congestion scenarios using real eCPRI traffic streams. Background traffic is sent up to 99%-line rate or exceeding the configured bandwidth rate to the point of discarding frames.

For brevity, the information provided here is summarized with results for EVPN-VPWS 5G fronthaul eCPRI performance. For fronthaul, midhaul and MBH workloads, see the Test Report of all data across multiple VPN services representing the traffic profiles explained in this document. In addition, the Test Report includes results for topology 2b, which features ACX7024 as the CSR and ACX7509 as the HSR.

Figure 6: Topology 2a ACX7024 CSR and ACX7100-32C HSR

Topology 2 provides single-homed performance data in a 2-hop scenario without a physical RU or DU element (both emulated by the test center). The following table measures the latency for eCPRI traffic sent over Topology 2, which includes two hops supporting point-to-point EVPN-VPWS services. The data shown is for Topology 2a, including ACX7024 as CSR and ACX7100-32C as HSR. Additional test results are found in the Test Report. Results are provided across different frame sizes, 10GbE and 100GbE port speeds, and continuous or burst traffic patterns. Latency is always measured in microseconds (µs). In all cases, the per-device average latency is measured less than the 10µs objective with the majority ≤6µs.

As shown, the average per-hop latency (2^nd column) is kept below 6µs when the network is not experiencing congestion. For the test validation, eCPRI traffic is generated from CSR (ACX7024) to HSR (ACX7100-32C).

The following table describes the latency performance with congestion created on the strict-high queue and additional scenarios including heavy congestion with traffic loss across multiple queues (strict-high and high). The congestion is created at the CSR ACX7024, resulting in discards on the egress path toward ACX7100-32C HSR.

As shown, the average per-hop latency (2^nd column) remains well below the overall goal of ≤10µs per device even during heavy network congestion, causing traffic loss in multiple priority queues (strict-high and high). In most cases, the per-hop latency results in less than 6µs. As the port speed increases, the transmission delay associated with congestion typically decreases. As a result, slightly lower latency is seen. The low-latency queue is designed to preserve the strict latency budget. This is a critical function for 5G architectures.

Topology 3: Latency Performance with eCPRI over active-active EVPN-VPWS Multihoming

Topology 3 measures low-latency queue performance over active-active EVPN-VPWS Multihoming services in the fronthaul network segment between CSR and a pair of HSRs. ACX7024 is the CSR with ACX7100-32C and ACX7509 as HSRs, counting as a single hop as traffic is load-shared. In this scenario, the QFX5120 is the third device emulating the DU. This section measures LLQ performance in conditions of non-congested and heavy congestion scenarios using real eCPRI traffic streams. Background traffic is sent up to 99%-line rate or exceeding the configured bandwidth rate to the point of discarding frames.

For brevity, the information provided here is summarized with results for EVPN-VPWS 5G fronthaul eCPRI performance. For fronthaul, midhaul, and MBH workloads, see the test report of all data across multiple VPN services representing the traffic profiles explained in this document.

Figure 7: Topology 3 CSR to active-active HSR

Topology 3 provides the multihomed performance data in a 3-hop scenario, which includes QFX Series Switches as the DU connecting to the all-active ESI LAG. The test center emulates the RU.

The following table provides measurements of the latency for eCPRI traffic sent over topology 3, which includes three hops supporting active-active multihoming EVPN-VPWS services. Results are provided across different frame sizes, 10GbE and 100GbE port speeds, and continuous or burst traffic patterns. Latency is always measured in microseconds (µs). In all cases, the per-device average latency is measured less than the 10µs objective, with the majority ~3-4µs.

As shown in the table, the average per-hop latency (2^nd column) equates to ~3-4µs per device as traffic is load-shared and includes an additional low latency QFX Series Switches element as the 3^rd hop DU. For the test validation, eCPRI traffic is generated from CSR (ACX7024) to active-active multihomed HSRs (ACX7100-32C and ACX7509) and traversing QFX5120 as the DU.

The following table describes the latency performance with congestion created on the strict-high queue and additional scenarios, including heavy congestion with traffic loss across multiple queues (strict-high and high).

As shown in the table, the average per-hop latency (2^nd column) results in ~3-5µs per device even during heavy network congestion, causing traffic loss in multiple priority queues (strict-high and high). As the port speed increases, the associated transmission delay might decrease. The low-latency queue is designed to preserve the strict latency budget.

Buffer Occupancy Validation

As part of the validation, buffer utilization is verified throughout the test execution. For the complete details, see the full Test Report. The CoS buffer configuration outlined in the Scheduling section proposes the following buffer allocation per queue for the ACX7000 platform.

With the configuration implemented in the JVD, the following table displays the expected buffer allocation based on a 100GbE port with the 1250KB dedicated buffer.

* remaining buffer is 0%, so minimum buffer programmed

The following outputs confirm that the buffer is allocated as expected. For more information related to buffer utilization during the test validation, see the Test Report.

Host Traffic Classification

For details on the results related to assigning host traffic to a forwarding class for this profile, see the Test Report.

Traffic Characteristics

For all details on traffic flows and types of streams created in the execution of this JVD, see the Test Report.