5G Mobile xHaul with Seamless MPLS Segment Routing—Juniper Validated Design (JVD)

About This Document

Juniper Networks Validated Designs offer a comprehensive, end-to-end blueprint for deploying Juniper solutions. These designs are engineered and tested by Juniper's experts to meet customer requirements, reduce the risk of costly mistakes, save time and money, and optimize network performance.

This document presents a Juniper Validated Design (JVD) for a 5G xHaul network utilizing the Juniper ACX7000 series, MX series, and PTX series with a seamless MPLS segment routing framework. The JVD extends previous solutions, focusing on the integration of the ACX7024 (AN4) with Junos OS Evolved as the 5G Cell Site Router (CSR). Thorough analysis of functional and performance aspects, specifically Fronthaul services and Class of Service (CoS) operations, was conducted.

The reference network design validated the ACX7024 as a reliable CSR choice, offering enhanced features and improved performance over previous ACX platforms. It is specifically designed for the CSR role, meeting the scale, bandwidth, and performance requirements of this function.

For the full test report, including configuration files, test bed details, and multidimensional scale and performance data, contact a Juniper Networks representative.

Solution Benefits

Juniper's ACX7000 series are designed as CSRs for 4G and 5G networks, providing essential connectivity and routing capabilities at cell sites for seamless communication between the radio access network (RAN) and the core network. ACX Series routers offer advanced features for mobile backhaul (MBH) and xHaul applications, supporting high-speed Ethernet and optical interfaces to handle modern cellular bandwidth requirements. These routers address high-volume traffic, low latency, and strict Quality of Service (QoS) demands of 4G and 5G deployments.

ACX Series routers provide scalability, security, and advanced traffic management for diverse deployment scenarios, handling Fronthaul, Midhaul, and Backhaul services while ensuring efficient traffic flow, service prioritization, and network resilience.

• Flexibility: The seamless MPLS segment routing framework enables flexible routing and traffic management, optimizing network performance and accommodating diverse 5G service requirements.
• Low Latency: 5G networks require ultra-low latency. ACX7000 Cloud Metro Routers ensure ultra-low latency forwarding, and Segment Routing MPLS (SR-MPLS) provides optimized latency-based path forwarding, eliminating complex protocol processing.
• Scalability: SR-MPLS segment routing simplifies the forwarding plane and reduces control plane complexity, enabling network scalability for a massive number of devices and seamless connectivity.
• Traffic Engineering: Seamless MPLS segment routing offers advanced traffic engineering capabilities for dynamic control and optimization of traffic flow, essential for load balancing, congestion avoidance, and QoS management in high-performance 5G services.
• Network Resiliency: MPLS segment routing provides fast rerouting mechanisms and supports protection/restoration schemes for quick recovery from failures and service continuity.
• Simplified Operations: MPLS segment routing simplifies network operations through source routing, encoding the forwarding path in the packet header, which reduces control plane overhead and improves operational efficiency.

Use Case and Reference Architecture

The 5G xHaul architecture comprises three physical segments: Fronthaul, Midhaul, and Backhaul.

Figure: 5G xHaul Reference Network Description: A diagram illustrating the logical segments of a 5G xHaul network. It shows a chain of components: RU (Radio Unit), Fronthaul (RAN Split 7.2), DU (Distributed Unit), Midhaul (RAN Split 2), CU (Centralized Unit), Backhaul, and EPC (Evolved Packet Core). The RU, DU, CU, and EPC are represented as nodes, with connections indicating the Fronthaul, Midhaul, and Backhaul segments. The Fronthaul segment connects RU to DU, Midhaul connects DU to CU, and Backhaul connects CU to EPC. There are also connections from 4G eNB and 5G gNB to the RU/DU/CU path, with RT (Router) nodes indicating various points in the network. A 'Subject for validation' box is shown around the Fronthaul and Midhaul segments, indicating the focus of the design.

The Fronthaul segment provides Layer 2 connectivity between the Open Radio Unit (O-RU) and Open Distributed Unit (O-DU) in the RAN, ensuring time and frequency synchronization for control, data, and management traffic. Low latency (below 150µs from RU to DU) is critical, limiting the Fronthaul segment to one or two hops.

RAN advancements involve diverse architectures for 4G (distributed, centralized, virtual) coexisting with 5G disaggregated O-RAN, offering flexibility for O-DU and O-CU placement. This JVD aligns with O-RAN split 7.2x, where the O-RU connects to the CSR and the O-DU is within the HSR infrastructure. Additional insertion points can support disaggregation between Midhaul and Backhaul segments.

Figure: RAN Deployment Scenarios for Simultaneous Support of 4G and 5G Description: A diagram illustrating various RAN deployment scenarios. It shows different configurations for Co-located O-CU and O-DU (O-RAN split 7.2x from cell site), Independent O-RU, O-CU, O-DU locations (O-RAN 7.2x from cell site), O-RU and O-DU integration on cell site (O-RAN split 2 from cell site), and O-RU, O-DU and O-CU integration on cell sites (Split 1 from cell site). Each scenario depicts the Cell Site, Access, Pre-Aggregation, Aggregation, and Core (5GC) segments with different arrangements of O-RU, O-DU, O-CU, UPF, and BH/MH/FH connections. For example, one row shows O-RU connected via FH to O-DU, then MH to O-CU, then BH to UPF and N6 to 5GC. Another shows O-RU, O-DU, O-CU co-located at the cell site, connecting via MH to BH, then UPF and N6 to 5GC.

The ACX7024 Universal Cloud Metro Router is designed for the CSR role, supporting 24 ports of 1/10/25 GbE and 4x100 GbE, with 360 Gbps system throughput. This JVD validates the ACX7024's scale, performance, and functional capabilities as a CSR in the 4G/5G Fronthaul network, specifically its insertion into the 5G xHaul solution (referencing 5G Fronthaul Network Using Seamless MPLS Segment Routing and 5G Fronthaul Class of Service JVDs).

Solution Design and Architecture

In This Section

• Overlay Services
• Connectivity Models
• Layer 3 Connectivity Models
• 5G QoS Identifier (5QI) Model
• QoS Profiles
• Class of Service Building Blocks
• Service Carve Out
• VLAN Operations

Figure: 5G Fronthaul Services Topology Description: A detailed network topology diagram showing two Autonomous Systems (AS 63535 and AS 63536) and their segments: Fronthaul Access, Midhaul/Backhaul, and Service Edge. Nodes include AN1 (ACX7100-48L), AG1.1 (ACX7509), AN2 (ACX7024), AG2.1 (MX204), AG3.1 (MX10003), CR1 (PTX10001-36MR), AN3 (ACX7100-48L), AG1.2 (ACX7100-32C), AG2.2 (MX204), AG3.2 (MX480), CR2 (PTX10001-36MR), and SAG (MX304). Connections between nodes represent various link types (100Ge, 100Ge AE, 10Ge, 10Ge AE). Routing protocols like ISIS L1 (SR), ISIS L2 (SR), BGP-LU, MB-BGP (V4/V6), and MP-eBGP (v4/v6) are indicated for different segments. Overlay services like EVPN-VPWS, EVPN-VPWS FXC, EVPN-ELAN, 4G L3VPN over BGP-LU, BGP-VPLS, L2VPN, and L2CKT are shown as logical paths across the topology. A 'DUT' (Device Under Test) is also indicated.

The Fronthaul network deployment scenarios support both traditional 4G MBH and the evolution to 5G network infrastructure over the same physical network. This enables MSOs to smoothly transition from 4G to 5G without disrupting existing services, gradually introducing changes and upgrades for 5G requirements.

The network underlay features SR-MPLS across multiple ISIS domains and inter-AS. Access nodes are in an ISIS L1 domain with adjacencies to L1/L2 HSR nodes, where the L2 domain extends from aggregation to core segments. Seamless MPLS is achieved by enabling BGP Labeled Unicast (BGP-LU) at border nodes.

Table: Transport Layer

To manage increased network scale, two sets of route reflectors are used at CR1 and CR2, primarily serving westward HSR (AG1) clients. AG1.1/AG1.2 act as redundant route reflectors for the access Fronthaul segment. Inter-AS Option-B solutions are supported via Multi-Protocol BGP peering between the Services Aggregation Gateway router (SAG) and the HSR (AG1).

Overlay Services

Overlay services in the network use various VLAN operations applied to Layer 2 service types such as EVPN-ELAN, EVPN-VPWS, EVPN-FXC, L2Circuit, VPLS, and L2VPN. Junos OS Evolved Release 22.3R1 supports Flow Aware Transport Pseudowire Label (FAT-PW) for L2Circuit and L2VPN services, included in this JVD. Ethernet OAM with performance monitoring is enabled for EVPN Fronthaul and VPLS MBH services. L3VPN services incorporate IPv6 tunneling to validate IPv6 PE functionality.

The following VPN combinations are designed to allow traffic flows in the 5G xHaul network:

• Layer 2 eCPRI (emulated) between O-RU to O-DU traffic flows (5G Fronthaul).
• Layer 3 IP packet flows between 4G CSR and EPC (SAG) (4G L3-MBH).
• Layer 2 flows between CSR (AN) to EPC (SAG) (4G L2-MBH).
• Layer 3 IP packet flows between 5G O-DU and CU/EPC (5G Midhaul and Backhaul).
• Layer 2 Midhaul flows emulating additional attachment segments (4G Midhaul and Backhaul).

Connectivity Models

Two connectivity models exist between O-RU and O-DU, leveraging EVPN-VPWS, EVPN-FXC, or EVPN-ELAN services:

1. EVPN-VPWS single-homed supporting dedicated MAC for eCPRI without redundancy.
2. EVPN-FXC VLAN-AWARE single-homed supporting dedicated MAC for eCPRI without redundancy.
3. EVPN-VPWS with A/A ESI LAG DU attachment.
4. EVPN-FXC VLAN-AWARE with A/A LAG DU attachment.
5. EVPN-ELAN with A/A ESI LAG DU attachment.

Figure: O-RAN Fronthaul Single-Homed EVPN-VPWS/FXC Description: A diagram illustrating the first connectivity model. It shows a Cell site with an O-RU connected to a CSR. The CSR is connected to an HSR in the Hub site, which then connects to an O-DU. The path between CSR and HSR is labeled 'Fronthaul'. The eCPRI flow is shown from O-RU through CSR and HSR to O-DU. The CSR has 'Untagged 802.1Q QinQ' and 'VLAN manipulation' indicated. The EVPN VPWS path is also shown. This setup supports dedicated MAC for eCPRI without redundancy and uses Ethernet OAM with performance monitoring, though OAM is only supported for the single-homed configuration.

Figure: O-RAN Fronthaul A/A EVPN-VPWS/FXC/ELAN Description: A diagram illustrating the second connectivity model. It shows a Cell site with an O-RU (MAC-A) connected to a CSR. The CSR connects to two HSRs (HSR-1 and HSR-2) in the Hub site, which then connect to an O-DU (MAC-B). The path between CSR and HSRs is labeled 'Fronthaul'. eCPRI flow and EVPN-VPWS paths are shown. This model uses either EVPN-VPWS or EVPN-ELAN with active/active multihoming, and EVPN-VPWS with FXC active/active multihoming from CSR (AN4) to HSR (AG1.1/AG1.2). HSR devices connect to the O-DU via an active/active Ethernet Segment Identifier (ESI) Link Aggregation Group (LAG) for traffic load sharing. Links are bundled into an active/active EVPN ESI 10Ge LAG between AG1.1 and AG1.2, and to the O-DU, which includes a two-member Aggregate Ethernet (AE) with both links actively functioning. eCPRI packets can arrive on either O-DU link from HSRs and are transmitted across either HSR uplink for active/active operations.

Layer 3 Connectivity Models

L3VPN protocol was chosen to facilitate Layer 3 connectivity between O-DU and vCU/vEPC elements of the 5G xHaul. Two unique connectivity models are proposed, both supporting Layer 3 multihoming between O-DU and a pair of HSRs:

• EVPN IRB anycast gateway with L3VPN.
• BD with IRB and static MAC/ARP with L3VPN.

The two corresponding models are EVPN IRB with L3VPN and BD IRB with L3VPN. For more details on configurations, contact a Juniper Networks representative.

Figure: EVPN IRB Anycast Gateway with L3VPN Description: A diagram showing EVPN IRB Anycast Gateway with L3VPN. It illustrates HSR1.1 (R8) and HSR1.2 (R9) connected to O-DU (R17). 5G EVPN-VPWS over SR paths are shown from 'To RU' to both HSRs. 4G/5G L3VPN connections are shown from HSRs to O-DU and 'To EPC/CU'. EVPN-VPWS Multihoming and EVPN-ELAN IRB/w StaticMAC are indicated. VLANs for 5G eCIPRI (100-150) and 5G MidHaul (200-210) are also shown.

Figure: BD with IRB and Static MAC/ARP with L3VPN Description: A diagram showing BD with IRB and Static MAC/ARP with L3VPN. Similar to the previous figure, it illustrates HSR1.1 (R8) and HSR1.2 (R9) connected to O-DU (R17). 5G EVPN-VPWS over SR paths are shown from 'To RU' to both HSRs. 4G/5G L3VPN connections are shown from HSRs to O-DU and 'To EPC/CU'. BD (Bridge Domain) is indicated between HSRs and O-DU, with L3VPN + IRB Static MAC. EVPN-VPWS Multihoming is also shown. VLANs are indicated at the top.

5G QoS Identifier (5QI) Model

When transitioning from the 4G LTE Quality of Service Class Identifier (QCI) model to the flow-based 5G QoS Identifier (5QI) model, most traffic definitions overlap. However, 5G introduces new categories for delay-critical Guaranteed Bit Rate (GBR) flows. In the 5G Fronthaul segment, eCPRI-based flows handle user and control traffic between the O-RU and O-DU, requiring high bandwidth and extremely low delay. Therefore, all devices in the access topology must prioritize this traffic type with the highest priority.

The O-RAN specification [O-RAN.WG9.XPSAAS-v02.00] proposes a model to group common QCI and 5QI flow characteristics into four exemplary groups based on their delay budget. This grouping aims to define QoS for different traffic types in the 5G network.

Figure: O-RAN 5QI/QCI Exemplary Grouping Description: A scatter plot illustrating O-RAN 5QI/QCI exemplary grouping based on Packet Loss (Y-axis, logarithmic scale from 10^-2 to 10^-8) and Delay (X-axis, from 0 to 100). Different numbered circles represent 5QI/QCI IDs with their corresponding delay/expected packet loss values. Four exemplary grouping regions are defined: Grouping 1 (low delay, low packet loss), Grouping 2 (higher delay, higher packet loss), Grouping 3 (GBR), and Grouping 4 - Default (Non-GBR). Delay-critical GBR (denoted as GBR QCIs) are also highlighted.

QoS schemas can vary among mobile operators, and this JVD does not endorse a specific design as the recommended one. The objective is to establish predictable behaviors for critical and non-critical traffic flows across various services delivered by the xHaul network. The transport architecture must accommodate existing and emerging mobile applications while maintaining delay budgets and traffic priorities.

For more details on the specific latency and delay budgets considered for this JVD, contact a Juniper Networks representative.

QoS Profiles

O-RAN/3GPP proposes two common QoS profiles to meet transport network requirements. In Profile A, a single priority queue handles ultra-low latency flows like Precision Time Protocol (PTP) and eCPRI, given priority over all other queues. Lower priority queues are serviced using weighted fair queuing (WFQ) round-robin scheduling. The ACX7000 series is best suited for Profile A.

Figure: Single Priority Queue (Profile A) Description: A diagram illustrating the Scheduler Parameters for a Single Priority Queue (Profile A). It shows a 'Port' with multiple queues feeding into it. The top queue, for CPRI (RoE), eCPRI CU-P, PTP unaware mode, is a 'PQ' (Priority Queue) with 'PIR' (Peak Information Rate). All other queues are 'BQ' (Bandwidth Queue) with 'Weight' and 'PIR'. These include OAM with aggressive timers, 5QI/QCI Group 1; Network control; O-RAN/3GPP C-plane and M-plane; 5QI/QCI Group 2; 5QI/QCI Group 3; a 'spare' queue; and 5QI/QCI Group 4. Below the diagram, a legend explains WFQ/WRR/WDRR Scheduling, 'Very high weight (BW over-dimensioning)' for frequent enqueuing, 'PIR mandatory' to avoid starving remaining queues, and 'PIR optional'. Queue buffer size is aligned to maximum latency requirements.

The Profile B model uses a hierarchy of queue priorities: high, medium, and low. These priority queues support preemption to minimize packet delay variations (PDV) and prioritize critical low-latency flows. The queue for eCPRI traffic must be able to interrupt or take priority over other queues.

As of Junos OS Evolved Release 22.3R2, ACX Metro Routers support multiple strict-high (SH) or low priority queues. Strict-high queues are serviced as round-robin without preemption. Profile A was selected for this JVD, reserving a strict-high queue for ultra-low latency between RU and DU.

Class of Service Building Blocks

Class of Service (CoS) governs how traffic is forwarded, stored, or dropped, in conjunction with mechanisms to manage and avoid congestion. CoS comprises the following basic building blocks:

• Classification
• Scheduling and Queuing
• Rewriting
• Shaping and Rate Limiting

CoS models vary between operators based on unique traffic profiles and characteristics. This JVD used a pseudo-customer model. For more details on this CoS model, contact a Juniper Networks representative.

Table: Validated Scheduling Profiles

Two styles of ingress classification were validated:

• Fixed classification: Context-based, where all traffic arriving on a specific interface is mapped into one forwarding class.
• Behavior Aggregate: Packet-based, where flows are pre-marked with Layer 3 DSCP, Layer 2 802.1Q Priority Code Points (PCP), or MPLS EXP.

O-RAN/3GPP proposes a minimum of six and a maximum of eight queues per interface. All platforms support eight queues. For this JVD, six queues and associated forwarding classes were used. For Profile-A, only one strict-high queue was used, shaped (PIR) to prevent starving low priority queues. Other queues were low priority and serviced as weighted fair queuing (WFQ) based on the designated transmit-rate.

At egress, DSCP, 802.1p, or EXP codepoints and loss priorities (PLP) are rewritten based on the assigned forwarding class and rewrite-rule instruction. The ACX series supports rewriting only the outer tag by default. In most cases, preserving and transmitting the inner (C-TAG) 802.1p bits transparently is preferred.

Service Carve Out

Ultra-low latency services (eCPRI) are assigned the highest priority as a best practice. MBH applications may have varying treatments. The priority mappings used for this JVD are grouped by service type.

Table: Service Definitions

VLAN Operations

The ACX7000 series supports a comprehensive set of VLAN manipulation operations compared to previous generation ACX platforms. This JVD validates 80 VLAN combinations across L2Circuit, L2VPN, EVPN-VPWS, and EVPN-ELAN services.

Test scenarios include the following VLAN operations:

• Untagged (UT)/Native VLAN
• Single-tag (ST) operations (pop, swap, push)
• Dual-tag (DT) operations (swap-swap, pop-swap/swap-push, pop-pop/push-push, swap-push/pop-swap)
• Rewrite PCP bits
• Preservation of PCP bits
• Classification of PCP bits and FC mapping

The explicit VLAN normalization operations validated for each Layer 2 VPN type are summarized below. For the comprehensive test report, contact a Juniper Networks representative.

Table: Validated VLAN Operations

Solution and Validation Key Parameters

In This Section

• Supported Platforms
• Service Profiles
• Scale and Performance
• Key Feature List
• Test Bed
• Solution Validation Goals
• Class of Service Validation Points
• Solution Validation Non-Goals
• Failure Scenarios

This section outlines solution key parameters and validation objectives for this JVD.

Supported Platforms

Table: Supported Platforms and Positioning

Service Profiles

The Fronthaul and Midhaul service profiles and associated network services used during validation are listed below. Fronthaul profiles were the focus of validation, while Midhaul profiles and associated traffic flows ensured validation completeness.

Table: Fronthaul Service Profiles

Table: Midhaul Service Profiles

Scale and Performance

This section details key performance indexes (KPIs) used in solution validation targets. Validated KPIs are multi-dimensional and reflect observations in customer networks or reasonably represent solution capabilities. These numbers do not indicate the maximum scale and performance of individual tested devices. For uni-dimensional data on individual SKUs, contact a Juniper Networks representative.

The Juniper JVD team continuously enhances solution capabilities, so solution KPIs may change without prior notice. Always refer to the latest JVD test report for up-to-date solution KPIs. For the latest comprehensive test report, contact a Juniper Networks representative.

The scale reference below provides an overview of KPIs represented in the validated profile.

To validate CoS functionality, classification, scheduling, shaping, and rewriting behaviors of the ACX7024 were tested across services utilizing the 5G xHaul infrastructure. Latency for critical Fronthaul traffic types was measured.

Based on the network design, the architecture can deliver fast restoration within 50ms for most traffic flows transported over ISIS-SR with Topology Independent Loop-Free Alternate (TI-LFA) protection mechanisms. Load distribution and optimization features improved service restoration during link or node failures. Link events consistently achieved convergence in less than 50ms. The ACX7024 with Junos OS Evolved Release 22.3R2 can deliver the outlined solutions across intra- and inter-domain architectures and is ideally suited for the CSR access role.

Table: KPI Scale Summary

For complete ECMP results with all outputs, contact a Juniper Networks representative.

Only Known Unicast is shown. VPLS BUM traffic should not load balance over ECMP routed links. This is expected behavior.

In terms of ECMP performance, the ACX7024 performed similarly to the previously tested 5G Fronthaul Network Using Seamless MPLS Segment Routing JVD. However, a slight imbalance in L2VPN traffic distribution was observed due to hash computation on the ACX7024. Similar results were seen with three ECMP links, where the ACX7024 showed a distribution of 33kpps/38kpps/30kpps, while the ACX7100-48L achieved nearly perfect balance. For a detailed report on test results, including ACX7024 ECMP Load-Balancing information, contact a Juniper Networks representative.

Network Convergence

Overall convergence results are within expectations for the given network design. In Fronthaul (CSR to HSR), ACX7024 failure and restoration events recovered within 50ms. ACX7024 performance was comparable to ACX7100-48L in the CSR role, with the ACX7100-48L achieving slightly better convergence. All ACX7000 series demonstrated improved convergence compared to previous generation ACX5448/ACX710, where CSR-to-DU reported up to four seconds of traffic loss during EVPN-VPWS failure events.

The table below summarizes convergence performance validations across all represented VPN services, including single-homing or active-active multi-homing. Traffic is sent as known-unicast. Higher convergence can be expected for BUM traffic in MAC-learned services. These results are also recorded in the full test report.

Table: Convergence Times for 5G Fronthaul Failure Events Per Flow Type

Class of Service Validation

Across the end-to-end topology, classification and rewrite were performed on 802.1p, DSCP, and EXP. The table below summarizes these results for the included services and classification types. In dual-tag scenarios, the outer service tag is used for classification and rewrite. CoS bits can be preserved end-to-end, including for inner or outer tags.

When a port shaper is defined, applicable class of service functions are adjusted to the new port speed and performed equivalently. For example, a 1G port shaper was used, and transmit-rate percentages were correctly shown to be based on a 1G port speed.

Figure: Class of Service Functional Diagram Description: This diagram is identical to Figure 3 (5G Fronthaul Services Topology) and Figure 10 (5G Fronthaul Lab Topology), illustrating the network architecture with AS 63535 and AS 63536, Fronthaul Access, Midhaul/Backhaul, and Service Edge segments. It shows various Juniper devices (AN1, AG1.1, AN4, AG2.1, AG3.1, CR1, AN3, AG1.2, AG2.2, AG3.2, CR2, SAG) and their interconnections. The diagram highlights points where 802.1P/DSCP Marking, Classifier, EXP Rewrite, and 802.1P/DSCP Marking occur, indicating the flow of traffic classification and rewriting across the network. A 'DUT' (Device Under Test) is also indicated. The traffic flows from IXIA (RT) are directed through the ACX7024 (AN4) towards the O-DU or SAG (Services Aggregation Gateway). These flows are classified based on Layer 2 (802.1p) or Layer 3 (DSCP) codepoints at specific positions called classifiers. The codepoints are then mapped to EXP values across the SR-MPLS topology. To ensure expected behavior, queue statistics are monitored to confirm desired classification and scheduling. Rewrite operations are performed at designated positions to modify packet fields. Packet captures verify correct rewriting or preservation of DSCP, 802.1p, or EXP bits. In the opposite direction, flows from SAG are marked and validated upon exiting AN4. For the full test report, contact a Juniper Networks representative.

Table: CoS Summarized Results

Congestion Scenarios

The validation included various congestion scenarios outlined in the Solution Validation Goals section. Congestion occurs when traffic exceeds the configured scheduler transmit-rate, shaped-rate, or port speed, leading to expected traffic loss. The main objective is to ensure critical priority traffic remains uninterrupted during congestion.

During key congestion events, the following observations were made:

• Strict-high queue was serviced ahead of low priority queues (up to queue shaped rate). Critical flows were guaranteed without packet loss, even when low priority queues were dropping packets.
• Low priority queues are guaranteed up to configured transmit-rate (CIR) (strict-high queue is shaped).
• Low priority queues are serviced as WFQ when operating in excess regions and bandwidth is available.
• Low priority remainder queue was granted a transmit rate consistent with leftover bandwidth.
• Scheduler percentages correctly inherit the configured port-shaper as port speed.
• Queue shaping rate is deducted from total bandwidth, with transmit-rates applied to the remaining bandwidth.
• Priority hierarchies are honored across and within VPN services that share common links.

For the full test report with details on all test cases, contact a Juniper Networks representative.

Latency Budgets

5G xHaul infrastructure defines strict latency budgets, particularly in the Fronthaul segment where ultra-low latency flows are required. Total budget factors include fiber length, connected devices, and transport design. O-RAN mandates a maximum of 100µs Fronthaul one-way latency from O-RU to O-DU, with each device contributing ~≤10µs. Operations demand device latency closer to ~5-6µs, a significant shift from earlier 4G architectures.

First, ACX7024 performance was evaluated as a standalone platform by taking latency measurements. Then, the complete Fronthaul and MBH infrastructure performance with ACX7024 as the CSR was validated.

Topology 1 was used to validate the ACX7024 device's performance as the CSR, providing the most accurate representation of its individual performance without additional network hops. Traffic was generated by Ixia, excluding self-latency. Critical eCPRI traffic flows were simulated using burst or continuous streams, with packet sizes of 64b, 512b, and 1500b.

Figure: Topology 1 for Single DUT Description: A diagram showing a single Device Under Test (DUT) setup. An 'IXIA' traffic generator is connected to an 'Emulated O-RU' and a 'CSR' (ACX7024 DUT). The CSR is connected to an 'Emulated O-DU'. The CSR is also connected to an 'xHaul' network represented by a grid of interconnected nodes. 'Crafted eCPRI stream' and 'Background Traffic' flows are indicated from IXIA to the CSR and through the network. This setup measures the latency of the ACX7024. In this scenario, a single-DUT utilizes a bridge-domain, with traffic mapped to the strict-high queue. A minimal difference is observed whether the queue is set to strict-high or low when there is no congestion.

Table: Single DUT Latency Measurements

For complete outputs of all latency measurements, contact a Juniper Networks representative.

Topology 2 was used to measure performance across the xHaul, including both CSR and HSR devices in the Fronthaul segment. The ACX7024 is the CSR DUT and the ACX7509 is the HSR.

The Fronthaul segment consists of three hops:

1. CSR ACX7024
2. HSR ACX7509
3. O-DU QFX5110-48S/O-DU

EVPN single-homed services are between ACX7024 and ACX7509, with QFX acting as a Layer 2 passthrough.

The Midhaul to Backhaul segment (L2Circuit and L3VPN) consists of six hops:

1. CSR ACX7024 (start)
2. HSRs ACX7100-32C and ACX7509
3. AG2 MX204s
4. AG3 MX480/MX10003
5. Core PTX10001-36MRs
6. SAG with MX304 (end)

Figure: Topology 2 for Fronthaul Description: A diagram showing a more complex test topology for Fronthaul. An 'IXIA' traffic generator is connected to an 'Emulated O-RU' and a 'CSR' (ACX7024 DUT). The CSR is connected to an 'HSR' (ACX7509). The HSR is then connected to an 'O-DU' (QFX5110). The CSR and HSR are also connected to an 'xHaul' network represented by a grid of interconnected nodes. 'Crafted eCPRI stream' and 'Background Traffic' flows are indicated. This setup measures performance across the xHaul, including both CSR and HSR devices in the Fronthaul segment.

Table: Latency Measurements (No Congestion)

The priority queue delivers strict latency performance compared to low priority queues.

Recommendations

The ACX7024 is a reliable CSR choice, offering enhanced features and improved performance compared to previous ACX platforms. It is specifically designed for the CSR role, catering to its scale, bandwidth, and performance requirements.

Compared to the ACX7100-48L, the ACX7024 demonstrates identical features and comparable performance for the CSR role and scale. Overall convergence improvements across all services were observed compared to previous generation ACX5448/ACX710.

Segment Routing is a suggested underlay architecture for seamless MPLS stitching with BGP-LU across multiple IGP and inter-AS domains. This setup can be improved by incorporating Seamless-SR and BGP-CT once supported. Utilizing TI-LFA and ECMP mechanisms enables quick failover and resilience. However, currently ACX7000 series does not support simultaneous ECMP and Fast Reroute (FRR) functionalities.

The ACX7024 supports deterministic and effective QoS, performing within expectations.

Layer 3 (DSCP), MPLS (EXP), and Layer 2 (802.1p) traffic, whether single-tagged or dual-tagged, were accurately classified based on their respective codepoints. Priority hierarchies were maintained within the guaranteed and excess regions, as defined by the transmit rate. The low priority queue supports weighted fair queuing (WFQ) for weighted distribution in the excess region. The strict-high priority queue, as typical, does not have an excess region and is shaped to avoid starving low priority queues. The CoS model ensured low priority queues always received committed information rates (CIR) as configured, using transmit-rate percentages.

When a port is shaped, CoS scheduling parameters are adjusted to match the new port speed. Codepoint preservation was maintained during all tested VLAN manipulation sequences. In terms of latency, the ACX7024 demonstrated comparable results to the ACX7100-48L. The average single-DUT latency was slightly better for the ACX7024 (around 4-5µs) compared to the ACX7100 (5-8µs). The minimum achieved latency for ACX7100 was 3.5µs, and for ACX7024 was 4.6µs.

Compared to the previously validated ACX5448/ACX710 reference network design, differences in some CoS behaviors are worth understanding when planning migration to ACX7000 series:

• The ACX7000 series supports significantly more VLAN manipulation operations compared to earlier ACX platforms, achieving relative parity with MX platforms.
• 802.1p bits are preserved without incurring a default rewrite. ACX5448/ACX710 perform a default rewrite.
• The ACX7000 series does not include simultaneous use of transmit-rate and shaping-rate for a queue. When only shaping-rate is utilized, the strict-high queue deducts the configured rate from the total port speed, and the remaining bandwidth is allocated to other queues based on their configured percentages. For example, if a 10G port has a 40% shaping-rate queue (SH), it deducts 4G from the total port speed. The remaining 6G is allocated to the other queues. For instance, a low priority queue with a 50% transmit-rate receives 3G.
• The ACX7000 series does not support routing-instance classification or rewrite functionalities.
• The ACX7000 series does not support the ability to lock the buffer using temporal or exact configuration.

For further details, contact a Juniper Networks representative for the full test report.

Although this JVD primarily focuses on the convergence of 5G xHaul infrastructure, the technologies and practical solutions discussed can serve as building blocks for developing various network architectures. These concepts can be leveraged to support multidimensional network designs and enable further advancements in network infrastructure.