Use Case and Reference Architecture
5G O-RAN is an open and disaggregated radio access network architecture that enables interoperability, flexibility, and innovation among vendors and operators. The fronthaul is the most demanding segment of the xHaul architecture, requiring high performance and functionality to ensure delivery and preservation of ultra-low latency workloads introduced in the 5G network. One of the key features of 5G O-RAN is the support for multiple classes of service that provide differentiated QoS and network slicing for various use cases and applications.
The solution is based on the 5G xHaul network and reference architecture defined by O-RAN Alliance Working Group 9 in the O-RAN Xhaul Packet Switched Architectures and Solutions technical specification [O-RAN.WG9.XPSAAS-R003-v08.00], which establishes the service aspects and requirements for the xHaul plane.
The xHaul consists of the Fronthaul (FH), Midhaul (MH), and Backhaul (BH) segments that connect to the O-RAN radio units (O-RUs), distributed units (O-DUs), and centralized units (O-CUs), respectively.
The fronthaul network segment is leveraged to enable Layer 2 connectivity between O-RU and O-DU, also referred to as RU and DU in the diagram (Figure 1) of the RAN for control, data (eCPRI), management traffic flows, and to provide time and frequency synchronization between RAN elements of the fronthaul network.
The advancement of the RAN involves different architectures for 4G, including distributed, centralized, and virtualized infrastructures, which need to coexist with the 5G disaggregated O-RAN. These diverse ecosystems provide flexibility for the placement of components such as O-DU and O-CU.
This JVD does not cover all possible scenarios. However, it closely aligns with O-RAN split 7.2x, where the O-RU connects to the CSR and the O-DU is co-located with O-CU within the HSR infrastructure. Additional insertion points can be implemented to support disaggregation between the midhaul and backhaul segments by extending appropriate services.
Figure 2 summarizes the deployment scenarios for the RAN according to the ITU-T for simultaneous support of 4G and 5G as proposed by the O-RAN Alliance.
5G infrastructure must support stringent latency budgets between O-RU and O-DU. To achieve this goal, the number of Transport Network Elements (TNEs) facilitating the fronthaul segment is kept to a minimum, in most cases limited to one or two hops. For this reason, spine-and-leaf topologies are ideal. However, ring architectures might be leveraged if the given latency budget can be achieved. For transport requirements, O-RAN WG9 technical specification (O-RAN.WG9.XTRP-REQ-v01.00) provides guidelines for a maximum of one-way latency budget of 100µs for the fronthaul. This budget includes latency incurred by the fiber run (~4.9µs/km) and transit nodes. The objective for this 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 series platforms typically support ≤6µs for low latency workloads, including under network congestion scenarios.
To meet Service Level Objectives (SLOs), 5G transport network QoS must be capable of supporting the spectrum of fronthaul traffic characteristics and mobile backhaul service applications. The referenced CoS scheduling model is constructed to support service types defined by 3GPP, as shown in the following table. These service hierarchies might be realized as part of network slicing architectures, as explained in the O-RAN WG1 technical specification (O-RAN.WG1.Slicing-Architecture-R003-v11.00). While network slicing is outside the scope of this validation, the underlying service attributes are important considerations in developing a viable CoS model.
| Service Type | Characteristics |
|---|---|
| eMBB | Slice suitable for the handling of 5G enhanced Mobile Broadband. |
| URLLC | Slice suitable for the handling of ultra- reliable low latency communications |
| V2X | Slice suitable for the handling of V2X services. |
| MIoT / mMTC | Slice suitable for the handling of massive IoT and/or massive machine type communication |
The flow-based 5G QoS model provides more granular control and flexibility compared to the bearer-based 4G LTE QCI model. Instead of assigning a single QoS value to an entire bearer, 5G allows differentiated flows within the same bearer to deliver individual QoS requirements. This enables more fine-grained QoS management and allows different applications and services to receive tailored treatment based on their specific needs. It also enables the network to adjust QoS parameters for individual flows dynamically, optimizing resource allocation and providing a better user experience.
When transitioning from the 4G LTE QCI model to the 5G QoS Identifier (5QI) model, there exist some similarities in defining and handling the traffic. However, in 5G, new categories are introduced specifically for flows that require very low delay and high bandwidth. These are crucial for user-plane and control-plane traffic streams between O-RU and O-DU in the 5G Fronthaul segment. The O-RAN architecture separates user-plane and control-plane traffic to enhance the efficiency and performance of 5G networks. The user-plane traffic includes the transmission of high-speed user data with low latency, while the control-plane traffic manages the signaling and coordination necessary to support the UPF. Both traffic streams are transported using the eCPRI protocol over the Open Fronthaul (OFH) interface, ensuring a standardized and efficient communication pathway between the O-RU and O-DU.
5G incorporates several new delay-critical Guaranteed Bit Rate (GBR) flow categories to meet the strict requirements of certain 5G applications that demand ultra-reliable low latency communications (URLLC). The proper categorization with performance capabilities of the network becomes paramount with technological advancements to support mission-critical services like autonomous driving, remote surgery, and industrial automation.
With high bandwidth and extremely low latency characteristics, 5G fronthaul access devices must assign the highest priority to the eCPRI-based flows supporting user and control traffic streams to ensure optimal performance and reliability. This means that the Service Providers might need to rethink their existing CoS designs, where the highest priority queues are typically reserved for voice or video traffic.
3GPP defines 5QI to QoS characteristics mapping, which can be referenced to build an appropriate CoS model. Resources are classified as delay-critical GBR, GBR, or non-GBR. For more information on 3GPP 5QI models, see details in ETSI TS-23.501.
The O-RAN 5QI/QCI Exemplary Grouping model is shown in Figure 3 and defined in O-RAN [O-RAN.WG9.XPSAAS-R003-v08.00], groups common QCI and 5CI QoS flow characteristics into four exemplary groups based on delay budget.
QoS schemas vary between mobile operators; the JVD does not attempt to qualify a specific design as the recommendation. The main goal is to substantiate deterministic behaviors based on critical and noncritical traffic flows across a range of services delivered by the xHaul network. The CoS solution should further prove capable of supporting the Exemplary model explained here, along with the Time Sensitive Network (TSN) profile and transport CoS characteristics.
Time Sensitive Networking (TSN) Fronthaul Profiles
The IEEE 802.1CM standard formalizes Time-Sensitive Networking (TSN) for fronthaul and ensures that fronthaul networks in 5G and advanced mobile networks meet stringent latency, jitter, and reliability requirements. It applies TSN principles, like precise synchronization and traffic shaping, to maintain low-latency and low-jitter communication between remote radio heads and baseband units. This standard helps mobile operators enhance network performance, support new high-precision applications, and ensure scalable and flexible infrastructure for future advancements. The standard applies to both CPRI and eCPRI traffic flows.
The JVD goals align with TSN Profile A, outlined by 802.1CM section 8.1, which follows a strict-priority model where the user plane is assigned a high-priority class while control and management plane data are assigned a low-priority class. Fronthaul traffic is always prioritized over non-fronthaul traffic, with a maximum frame size recommendation of 2000 octets for both.
O-RAN defines TSN Profile A within its architecture to ensure deterministic communication in the fronthaul network, connecting remote radio units (RRUs) with centralized baseband units (BBUs). Profile A is recommended for ultra-low latency and jitter, with precise synchronization and traffic shaping, suitable for the most demanding 5G applications. Figure 4 , defined by the O-RAN WG9, illustrates the packet behavior in TSN Profile A.
802.1CM additionally defines TSN Profile B with express frame preemption. O-RAN.WG9.XPSAAS-R003-v08.00 illustrates the minimal benefit for port speeds >1Gbps. Table 2 outlines queuing delay differences based on port speed and calculates associated fiber reach. Each profile includes a reference frame size influencing queuing delay. The frame size with Profile B is smaller due to preemption, but only when frames are larger than 155 bytes. Frames below 155 bytes are not preempted.
| Port Speed |
TSN Profile A: Queuing delay of 2,020 bytes |
TSN Profile B: Queuing delay of 155 bytes |
Difference (µs) |
Difference (Fiber) |
|---|---|---|---|---|
| 1 Gbps | 16.160 µs | 1.240 µs | 14.920 µs | 3,045 m |
| 10 Gbps | 1.616 µs | 0.124 µs | 1.492 µs | 304 m |
| 25 Gbps | 0.646 µs | 0.050 µs | 0.596 µs | 122 m |
| 50 Gbps | 0.323 µs | 0.025 µs | 0.298 µs | 61 m |
| 100 Gbps | 0.162 µs | 0.012 µs | 0.149 µs | 30 m |
| 200 Gbps | 0.081 µs | 0.006 µs | 0.075 µs | 15 m |
| 400 Gbps | 0.040 µs | 0.003 µs | 0.037 µs | 8 m |
From 10Gbps onwards, the benefits of frame preemption in Profile B diminish to the point of nominal return. The recommended Profile A is leveraged in the JVD solution and includes multiple priority queues, with each having preemptive capability (between queues). The LLQ supports dequeuing prioritization over lower priority frames to ensure delivery of delay-sensitive traffic.
O-RAN Priority Queuing Models
O-RAN/3GPP proposes two common QoS profiles supporting a minimum of 6 queues to accommodate transport network requirements. These profiles include a single Priority Queue (PQ) or multiple Priority Queues.
In the single PQ model (Figure 5), the priority queue is defined for handling ultra-low latency flows such as PTP and eCPRI. This queue is serviced ahead of all other queues. Lower priority queues are then serviced as weighted fair queuing (WFQ).
In the second O-RAN transport core QoS model (Figure 6), a hierarchy supporting multiple priority queues is utilized with the ability to dequeue in priority order. Priority queues must be rate-limited to prevent starving queues of lower priorities.
The previous JVDs, 5G validated designs for 5G CSR Seamless Segment Routing and 5G Fronthaul Class of Service leveraged the Single Priority Queue model. The strict-high queue is reserved for the most critical traffic flows, such as eCPRI between O-RU and O-DU and is shaped to prevent starving lower priority queues.
As per Junos OS Evolved Release 23.3R1, the ACX7000 family supports six priorities: low-latency, strict-high, high, medium-high, medium-low, and low. Each priority queue is capable of preempting lower priority queues. A major focus for this JVD featuring LLQ is to validate the Multiple Priority Queue model.
Recommended Latency Budgets
5G xHaul infrastructure defines strict latency budgets, particularly in the fronthaul segment. The total budget factors include fiber length, transit network devices, and transport design. O-RAN mandates a maximum of 100µs fronthaul one-way latency.
Typically, this equates to ≤10µs per device without accounting for fiber distances. Operators commonly seek solutions to reduce further per-device transit latency in the range of ~6µs, which can help to extend the total network reach. This is a massive paradigm shift from the earlier 4G architecture requirements. The end-to-end xHaul RU to EPC is expected to be ≤10 milliseconds.
When leveraging a multiple PQ model, we recommend placing G.8275.2 PTP unaware as the highest possible priority. However, O-RAN discourages deployments with PTP unaware in favor of G.8275.1 PTP profile, using boundary clock mode on each transit node. PTP aware does not carry such precise delay requirements, allowing this traffic to be placed in a low-priority queue. The highest priority traffic is therefore given to eCPRI. Traffic classes used in the JVD are explained in the Solution Architecture section.
The transport architecture must be capable of preserving delay budget integrity while guaranteeing traffic priorities. The following table [O-RAN.WG9.XPSAAS-v08.00] defines suitable per-hop latency and per-hop packet delay variation budgets for critical traffic types and is an important reference point in developing the 5G JVD QoS model and contributing traffic classes. This table includes the alignment of traffic classes based on Exemplary grouping.
| Traffic Type | Packet Size | Per-Hop Latency | Per-Hop PDV |
|---|---|---|---|
| PTP (unaware mode)1 | ~100 bytes | constant average | ~0.5 μs) |
| CPRI (RoE) | ~1500 bytes | ~1-20 μs | ~1-20 μs |
| eCPRI CU-plane | ~1500 bytes | ~1-20 μs | ~1-20 μs |
| OAM with aggressive timers | ~100 bytes | ~1 ms | ~1 ms |
| 5QI/QCI Group 1 (low latency U-plane) | variable | ~1 ms | ~1 ms |
| Low latency business traffic | variable | ~1 ms | ~1 ms |
| Network Control: OAM with relaxed timers, IGP, BGP, LDP, RSVP, PTP aware mode (T-TC/T-BC) | variable | ~5 ms | ~1-3 ms |
| O-RAN/3GPP C-plane and M-plane) | variable | ~5 ms | ~1-3 ms |
| 5QI/QCI Group 2 (medium latency U-plane) | variable | ~5 ms | ~1-3 ms |
| 5QI/QCI Group 3 (remaining GBR U-plane) | variable | ~10 ms | ~5 ms |
| Guaranteed business traffic | variable | ~10 ms | ~5 ms |
|
5QI/QCI Group 4 (remaining non-GBR U-plane) Other traffic types (best effort) |
variable | ~10-50 ms | ~5-25 ms |
(1) PTP unaware mode will not be covered and is no longer recommended.
Regulatory Interests
- ETSI 3GPP Forum (3rd Generation Partnership Project)
- O-RAN Alliance
- Metro Ethernet Forum (MEF)
- IEEE P802.1CM
- eCPRI Specification