White Paper

VIAVI Solutions

Test Suite for

O-RAN Specifications
Open Radio Access Network (O-RAN) is being adopted by operators and equipment
manufacturers worldwide to reduce infrastructure deployment cost and lower the
barrier to entry for new product innovation. As a leader in 5G test and measurement,
VIAVI Solutions has developed a comprehensive test suite with modules for lab
validation, field deployment and service assurance. This guide provides an overview
of O-RAN, descriptions of use cases, and instrument and system recommendations
to support a robust and efficient test environment.

O-RAN Overview
The expectations of 5G will place enormous demands on the network infrastructure to deliver massive volumes of
data over swathes of spectrum to multitudes of users at challenging latencies. To meet this challenge necessitates
the possibility for the different logical functions of the network to be flexibly placed at different physical locations
and the network must be disaggregated into more components than has been seen before.

Traditionally, as shown in Figure 1, RAN components such as radio and digital base band have been built on
proprietary hardware, and these components typically use vendor-specific protocols for communications.
Software functions and interfaces between the different RAN components are designed for optimal performance
for that proprietary hardware. For example, Common Public Radio Interface (CPRI) is commonly used for LTE
fronthaul (link between radio unit and baseband unit), however, vendor specific implementation often restricts
multi-vendor operability.

For the introduction of RAN functions disaggregation and open interfaces in 5G, 3GPP has in Release 15 specified
a Higher Layer Split (HLS) option of the gNB which is known as well as the Option 2 NR-PDCP split option. In
this option, the gNB may consist of a Central Unit (gNB-CU) and one or more gNB Distributed Unit (gNB-DU)
connected through the F1 interface. 3GPP has delivered a set of specifications for the F1 interface, however realizing
multi-vendors interoperability over the F1 interface can be very challenging as these specifications have been
defined with options which can be used in different manners depending on vendors’ implementation.

3GPP has started a study on Lower Layer Split (LLS) in Release 15 during which multiple lower layer split options
were identified but it has proven to be difficult for the 3GPP community to converge on specifying a single
split option in 3GPP. Many vendor specific implementations of lower layer splits exist in the market today which
even though have been optimized to take advantage of the benefits of lower layer split such as improved radio
performance due to coordination gains, these closed systems do not support multi-vendors interoperability.

O-RAN sets out to deliver well defined specifications to the industry aiming to enable deployments of O-RAN
based programmable networks consisting of fully disaggregated modular O-RAN network functions which are
designed to be multi-vendor interoperable over open interfaces running on cloud-based virtual systems. This allows
operators to design and deploy mixed-vendor network and network slices which is key to delivering mixes of use
cases in the same O-RAN infrastructure.
What is O-RAN?

• Further Dis-aggregation O-RU

OFH
RIC
• RAN Cloudification
O-RAN O-DU
F1
O-CU EPC / NGC
• Open APIs
• Multi-Vendors Interoperability O-RU OFH Open interfaces and APIs with interoperable RAN components
NFV modules and reference designs
Intelligence and automation for Plug and Play

• Proprietary System
FH F1
EPC /
1st Level • Some Dis-aggregation RU Layer 1 Layer 2 Layer 3 Next Generation
Dis-aggregation • Partially Virtualized Core (NGC)
DU CU
• No Interoperability Proprietary hardware Virtualized proprietary design
NO multi-vendors NO multi-vendors interoperability
interoperability

• Closed Proprietary System Evolved

FH
Traditional RAN • No Open Interfaces RRH Layer 1 Layer 2 Layer 3 Packet Core
• No Interoperability (EPC)
BBU
Proprietary hardware and design
Does not support multi-vendors interoperability

Figure 1. RAN evolution

A key challenge for the more complex and flexible 5G network that results from this is the scale and flexibility of
deployment, optimization, management and orchestration of the network. Delivering new services and managing
RAN capacity will no longer be practical if managed manually. Intelligence and automation must be integrated into
all aspects of the network lifecycle to reduce both CAPEX and OPEX. As RAN disaggregation facilitates managing
the complexity required to address the 5G challenge, intelligence in every layer of the RAN architecture is at the
core of open RAN technology. This will allow operators to deploy a truly self-managed, zero-touch automated
network. Consider the example where base band capacity can become a bottleneck during an unplanned network
event. Using artificial intelligence and machine learning tools, this event can be detected and characterized in
a short amount of time leading to automated optimization, such as small cell infill capacity. Such an innovative
solution can be deployed quickly and efficiently on a white-box platform.

To achieve the above-mentioned goals of an open radio access network, operators founded the O-RAN Alliance
to clearly define requirements and help build a supply chain eco-system that can foster an environment for
existing and new vendors to drive innovation. As per the charter of O-RAN Alliance, O-RAN Alliance members
and contributors have committed to evolving radio access networks around the world. Future RANs will be built on
a foundation of virtualized network elements, white-box hardware and standardized interfaces that fully embrace
O-RAN’s core principles of intelligence and openness.

The key principles of the O-RAN Alliance, as shown in Figure 2, include:

y Lead the industry towards open, interoperable interfaces, RAN virtualization, and big data enabled
RAN intelligence

y Specify APIs and interfaces, driving standards to adopt them as appropriate

y Maximize the use of common off-the-shelf hardware and merchant silicon, thus minimizing proprietary hardware.

Although there are several operator-led industry initiatives that aim to generically create an open RAN ecosystem,
the O-RAN Alliance has received the greatest amount of support. In this document we use “O-RAN” to refer to the
open RAN ecosystem target of the O-RAN Alliance.
2 Test Suite for O-RAN Specifications
Benefits of O-RAN
5G’s diverse use cases and scale have further challenged operators to:

y Evolve their infrastructure quickly to monetize the new business opportunities offered by 5G, and simultaneously.

y Manage their CAPEX while managing their OPEX.

As we know, deployment and management of RAN is the most expensive part of a wireless network, which
means current ways of network evolution, growth and maintenance will not scale to meet the 5G challenges and
opportunities. Therefore, operators are now seeing O-RAN as the most viable option to help them meet those
goals:
1. Enable an open, multi-vendor interoperable ecosystem driving healthier competition, lowering costs for RAN
equipment, and delivering a much larger pool of vendors.
2. Enable automation, which can reduce deployment and management cost.
3. Deliver scale and agility, where network components implemented as software functions can be scaled to meet
network capability and capacity demands.

Orchestration & Automation (e.g. ONAP): MANO, NMS

Design Inventory Policy Configuration RAN Intelligent Controller (RIC) non-RT

A1

Applications Layer RAN Intelligent Controller (RIC) near-RT

Radio Connection Interference

3rd Party App Mobility Mgmt QoS Mgmt Trained Model
Mgmt Mgmt
Radio-Network Information Base

E2: btw RIC near-RT and CU / DU

Multi-RAT CU-CP E1 CU-UP

CU Protocol Stack RRC SDAP
PDCP-C PDCP-U

NFVI Platform: Virtualization layer and COTS platform F1

O-DU: RLC / MAC / PHY-high

Open Fronthaul

O-RU: PHY-low / RF

From

Figure 2. O-RAN Architecture

Challenges of Deploying and Managing O-RAN based networks

Interoperability and end-to-end performance will be by far the biggest concerns on the minds of vendors and
operators in an O-RAN environment. Imagine all the advanced coordination features, power control algorithms and
intra-technology interactions in a multi-vendor RAN. Today, having one vendor simplifies all that. And, when product
related network performance issues arise, which is inevitable, service providers work with only one vendor to resolve
them. Now imagine a network where RAN components such as central unit, distributed unit, and radio unit are
supplied and supported by multiple vendors – operators and vendors will face greater challenges in both identifying
and isolating issues as well as ensuring that performance/cost compares favorably to that of an optimized single
vendor solution. Another key challenge of an O-RAN based multi-vendor network will be network management
and resource management. Management of multi-vendor spares and training resources to maintain a multi-vendor
network will be a learning curve for service providers’ operations team. Not to forget, integrating new functions and
orchestration of new services in an O-RAN based network will be another key challenge.
3 Test Suite for O-RAN Specifications
To overcome the above challenges, O-RAN Alliance has been working with its members and contributors, including
VIAVI, to deliver a Reference Architecture designed to enable next generation RAN infrastructures. This reference
architecture will be based on well-defined, standardized interfaces to enable an open, interoperable supply chain
ecosystem in full support of and complimentary to standards promoted by 3GPP and other industry standards
organizations. Further details of the structure and working groups are included in Appendix 1.

Key Test Areas for Vendors and Operators

Success of O-RAN will depend on the capability of operators to integrate and meet network KPIs in a true multi-
vendor environment. To achieve this goal, operators need to have the confidence that all components in an O-RAN
network have been tested in a trusted and controlled environment and all open interfaces and components are
working correctly such that a multi-vendor O-RAN network cost to performance ratio is at least equivalent to that
of a traditional a single-vendor network. Operators will only deploy a network with an O-RU from one vendor,
fronthaul from another, and baseband from a third one only if the performance and cost meet their targets and
network integration is robust.

VIAVI plays an active role in contributing to the development of O-RAN standards and how O-RAN compliant
products can be tested to ensure interoperability, commercial robustness and high performance.

VIAVI was also part of the first global Plugfest, an event conducted to foster adoption of open and interoperable
5G and 4G Radio Access Networks. The O-RAN architecture references multiple standards bodies to deliver a robust
open RAN ecosystem. VIAVI participates in those bodies and their workgroups including ITU-T, 3GPP, ONAP, IEEE
(specifications for network transport, timing and sync workgroup) to name a few. VIAVI thus facilitates the delivery
of test solutions so operators can be confident that their networks, once tested with VIAVI, are compliant with
multiple required standards.

VIAVI has identified various use cases which can help identify, isolate and resolve network performance issues before
an O-RAN multi-vendor network is launched.

The following are some key areas of our focus in lab validation, field deployment and network assurance.

y Multi-vendor interoperability test (MV-IOT) for functionality, performance, reliability, robustness, and resilience

y Subsystem (wrap-around) test 1. Multi-vendors interoperability

Open interfaces • Whitebox • RIC
y System level test
2. Multi Variants can be deployed
Automation & Orchestration

y Vendors-pairing evaluation Functions, Performance, Robustness,

Resilience, Wrap around & System Testing
y Protocol compliance for open interfaces and protocols
System Test

y Continuous Integration and Continuous Delivery Subsystem Test

IOT
test automation O-CU
Profiles
y Continuous test process throughout the entire lifecycle
CUS/M/T-Plane
IOT

y Holistic evaluation of multiple RAN deployment options

(RAN dis-aggregation, spectrum bands, O-DU
delay management, features, vendors, etc.)

y Performance monitoring of open interfaces and Figure 3. O-RAN Subsystem and System Testing using
protocols to ensure optimum operation O-CU and O-DU

4 Test Suite for O-RAN Specifications

Figure 3 shows the scope of system and subsystem testing methodology using O-CU and O-DU. The remainder
of this paper sets out several test challenges and associated use cases, resources and recommendations for how
to overcome these challenges. The presented test cases are a subset of the potential use cases rather than an
exhaustive list of every required test case and are intended to provide an insight into test requirements and act as
a starting point for more detailed discussion. Emphasis is given to multi-vendor testing aspects.

There are many options for deploying multi-vendor networks and the choices made will drive test priorities. One
potential scenario is that the operator sources the O-DU and O-CU from one vendor and uses them with O-RUs
from different vendors. In this scenario, separating the testing of the single-vendor O-DU and O-CU will enable
the single vendor part of the network to be tested and optimized separately from any variability introduced by
different O-RUs. Once that is complete, end-to-end testing involving the complete O-RU, O-DU, O-CU chain
should be performed as well.

In another scenario, the split is between the O-DU and the O-CU. In the same way, testing upwards from the F1
interface into the O-CU for the single-vendor part can be separated from the variability introduced by the different
O-RU and O-DU suppliers.

Irrespective of decisions about the mix of different vendors and network architectures, certain critical performance
aspects will remain. Included among these are:

y End-to-end network performance including during handover and with mobility and fading test scenarios

y Robustness of the X-haul transport and synchronization networks.

y Multi-vendor interoperability testing

To help operators manage testing, VIAVI has worked closely with the O-RAN Alliance in the development of
interoperability and conformance test scenarios. Along those lines different operators are launching O-RAN Test
and Integration Centers (OTIC) around the globe. The core charter for OTIC is to ensure O-RAN components from
multiple vendors support standard and open interfaces and can interoperate in accordance with O-RAN test
specifications. Some of the key goals are to:

1. Verify, integrate and test disaggregated RAN components.

2. Ensure O-RAN solutions functionally comply to the specifications of the O-RAN alliance.

3. Deliver the desired architecture that supports a plug-and-play model for O-RAN network components
and solutions.

NITRO™ Platform for O-RAN

Delivering on Test, Measurement and Assurance for O-RAN through the lifecycle, VIAVI is leveraging the NITRO
(Network Integrated Test, Real-time analytics and Optimization) Platform to enable an integrated and open T&M
environment. Architected for Automated Workflows and lowering Total Cost of Ownership, NITRO enables full
lifecycle analytics and reporting.

5 Test Suite for O-RAN Specifications

Use Cases for Enabling the O-RAN Ecosystem
As discussed earlier, in an open multi-vendor scenario, it is essential to ensure disaggregated RAN components
(O-CU, O-DU, and O-RU) are not impacting network performance. As shown in figure 4, this can be achieved
by validating them in the lab environment to make sure the nodes are designed and functioning per O-RAN
specifications, and are interacting with each other without causing performance issues. Scaling the validation to a
real network environment under heavy traffic with different traffic and application mix also needs to be performed
to discover and address failures to meet KPI targets under real-world heavily loaded network conditions. Today,
VIAVI TeraVM and TM500 are the de facto solutions used by almost all network vendors in the lab to make sure
their products will meet the performance requirements of wireless service providers. Building on that experience,
VIAVI solutions now support O-RAN specifications to ensure the same level of precision testing at the O-RAN
interfaces can be performed in the lab. Once network components are deployed, our field solutions such as
T-BERD®/MTS-5800 and CellAdvisor™ 5G 5G help service providers troubleshoot and isolate problems quickly and
efficiently.

Now, let’s discuss some of these lab and field challenges and how VIAVI can help both vendors and operators
overcome them efficiently.

TeraVM CORE DU/RAN Emulation

NW SIM
• Apply large scale O-DU traffic to O-CU
5GC Sim
(UPF, AMF, etc) • Realistic modeling of high load scenarios
EPC Sim • F1 and X2 traffic emulation
(MME, SGW, PGW, etc)
FH Test Interface
• Apply UE traffic at FH interface
CU/O-CU • Efficiently increase O-DU test capacity
• Reduce complexity/cost with no RF
3GPP F1
WG4 OFH Protocol Analysis
• C/U-plane message timing & analysis
O-DU • High speed packet capture & indexing
• WG4 OFH S-plane performance validation
O-RAN Open Fronthaul (OFH)
RF/Beam Analysis
O-RU • Real-time spectrum analysis
• 5G NR beam analysis
• 5G NR signal analysis

UE/Apps Emulation
RF
• Device emulation & analysis
• UE capacity & throughput
• Beamforming test scenarios

Figure 4. Example Test Points in an O-RAN environment

6 Test Suite for O-RAN Specifications

Use Case 1: Validating O-DU in a Multi-Vendor O-RU Environment
In a multi-vendor O-RAN environment, network vendors and service providers will face situations where they must
support a varied set of O-RU configurations, potentially supporting O-RUs from multiple vendors simultaneously
in the same network. Having different O-RU configurations can add complexity in terms of interoperability. This is
compounded by the fact that compared to testing over RF of single vendor networks, the O-DU and standardized
O-RAN Fronthaul interface are new elements, which introduces a new risk. O-DU focused testing is used to minimize
this risk to the 3GPP features and interactions the network must support, which requires all disaggregated nodes
to perform well. O-DU vendors therefore need to ensure that O-DUs can handle multi-vendor O-RUs without
introducing performance compromises and avoid the addition of new risks from a 3GPP feature interaction point
of view.

Extensive experience and VIAVI leadership in validation of 3GPP features and interactions over RF is leveraged
(as shown in figure 5) in the VIAVI TM500 O-RU Emulator solution to validate the capability of an O-DU to handle
multi-vendor O-RUs without unexpected performance compromises.

Service Management and Mobile Core

Non-Real Time RIC
Orchestration Framework (SMO) (5GC / EPC)
O1 A1 O1 O2
OFH S1/NG
M-Plane xApp Near Real Time RIC

E2 E2
TM500 TM500 OFH F1 E1
O-DU O-CU-CP O-CU-UP
UE Emulator O-RU Emulator

O-Cloud

Figure 5. Validating O-DU in a Multi-Vendor O-RU Environment

7 Test Suite for O-RAN Specifications

Use Case 2: Validating F1 Interface Performance Using an O-DU Emulator
3GPP F1 interface connects multiple O-DU nodes back to the central unit (O-CU) for both the control plane
(CU-CP) and user plane (CU-UP) . Ensuring the performance of the F1 interface and ability of the O-CU to handle
many O-DU’s while supporting different traffic profiles with large numbers of UEs is important to quantify overall
network performance. With the VIAVI DU/RAN Emulation solution, network vendors and service providers can
emulate many O-DU nodes with a realistic traffic mix generated by a large number of emulated UEs. The X2
interface used between eNBs in LTE is reused between the Master eNB and en-gNB for non-standalone (NSA)
operation and is supported with VIAVI virtual RAN emulation functionality. The DU/RAN Emulation solution enables
validation of the performance of the O-CU F1 interface , and how individual UEs are successfully managed in a
multi-vendor environment. This solution efficiently adds hundreds of O-DUs worth of traffic applied to the O-CU
under test without the cost or complexity associated with many real O-DUs (and even more O-RUs). UE stack
integration allows realistic modeling of very high load traffic scenarios with dynamic F1 traffic emulation.

Service Management and Mobile Core

Non-Real Time RIC
Orchestration Framework (SMO) (5GC / EPC)
O1 A1 O1 O2
S1/NG S1/NG
xApp Near Real Time RIC
E2
E2
F1
TeraVM E1
O-CU-CP O-CU-UP
DU/RAN Emulator X2/Xn gNB
Xn

O-Cloud

Figure 6. Validating F1 Interface Performance Using an O-DU Emulator

8 Test Suite for O-RAN Specifications

Use Case 3: End-to-End Network Performance, Mobility, and Capacity Test
With the TM500 Network Tester emulating multiple UEs, tests over RF can be done to assess the end-to-end
performance of a real O-RU upwards to a real O-DU, O-CU and the core network. With the TM500 supporting
Real Data Applications e.g. HTTP, FTP, streaming/UDP traffic, performance validation can be done to ensure that
KPIs such as throughput, latency, and round trip times (RTT) meet customer requirements even though the O-DU
and the O-CU may come from different vendors.

The introduction of 5G adds new fading profiles and handover scenarios which must be tested for low, medium,
and high UE capacity test scenarios. In NSA mode for instance, multiple types of handovers can occur between 4G
and 5G carrier depending upon the deployment scenario and UE distance from the base-stations. For example, a
handover can occur from 5G to 4G, 4G to 4G or 5G to 5G. Additional fading and channel profiles introduced by new
deployment scenarios and frequencies above 6 GHz defined in 3GPP TR 38.901 contribute to complexity in terms of
the different test scenarios that must be validated.

The TM500 emulator, with the support of real data applications, can execute high capacity end-to-end
performance tests in simulated real-world environments facilitating, validation of the different mobility, traffic
and handover scenarios for 4G and 5G. Such end-to-end validations continue to be vitally important when testing
disaggregated RAN networks leveraging O-RAN based components.

Use Case 4: Transport and Synchronization Verification of the Open Fronthaul

In O-RAN, open fronthaul is defined as the link between the O-DU and O-RU. Mobile broadband services that are
expected to take advantage of advanced mobility applications will require coordination of multiple radios driving
a lower layer functional split of the baseband function. The lower layer functional split was primarily implemented
in 4G using CPRI as the interface between 4G BBU and RRH. While simple in design, it requires significant transport
bandwidth proportional to the bandwidth of the baseband signal and the number of antennas. This disadvantage
poses a significant challenge to the introduction of 5G services that rely on much larger bandwidths and antenna
ports. The challenge has been addressed with the introduction of a new lower layer functional split. Known as
eCPRI, this packet-based transport technology significantly reduces the fronthaul bandwidth, but it also presents
some new challenges. It exposes some of the disadvantages of packet-based technology such a its inherent packet
delay variation. Furthermore, eCPRI is not a synchronous technology and relies on synchronization technologies
such as Precision Time Protocol (PTP) and optionally synchronous Ethernet (SyncE).

Open fronthaul facilitates the use of standardized multi-vendor interfaces which paves the path to successful
interoperability between O-DU and O-RU, but performance validation of the open fronthaul and interoperability
of the O-DU and O-RU over the open fronthaul will be necessary to ensure field deployments do not result in
catastrophic failures.

9 Test Suite for O-RAN Specifications

The field-tested VIAVI T-BERD/MTS-5800 solution can be used to validate the performance of the open fronthaul
in the lab and in the field. Network vendors can quickly validate the health of the transport and synchronization
performance. T-BERD/MTS-5800 allows lab engineers and field technicians to perform this validation in the live
mode giving them visibility into the protocol messages between the O-DU and O-RU. The following verification
can be performed in the live mode:

Transport Health Verification Synchronization Verification

y Power Level y PTP Connection

y Frequency Offset y Message count

y Packet count

y Bandwidth Utilization

5GC
(UPF, AMF, etc)
Transport Health Verification
EPC • Power Level
(MME, SGW, PGW, etc) • Frequency Offset
• Packet count
• Bandwidth Utilization
CU/O-CU
Synchronization Verification
3GPP F1 • PTP Connection
• Message count

O-DU
O-RAN OFH

Splitter

O-RU

RF

Figure 7. Fronthaul Analyzer – Transport and Synchronization Network Test

10 Test Suite for O-RAN Specifications

Use Case 5: Verification of 4G and 5G FH Transport and Synchronization Networks
Fronthaul transport nodes (FTN) aggregate and transport traffic between CPRI/eCPRI-based RRH/O-RU and
BBU/O-DU’s. While they simplify the fronthaul topology, they can introduce transport and synchronization issues.
Validating FTN-based networks is essential to minimizing any issues caused by excessive packet loss, delays, jitter
and poor QoS. In a multivendor O-DU/O-RU deployment, these FTN challenges can create more complexity in the
validation, verification and troubleshooting of the open fronthaul, and other O-RAN components. Verifying FTN
readiness for O-RAN is necessary for a smooth O-RAN deployment.

The VIAVI T-BERD/MTS-5800-100G performs eCPRI tests throughput, delay, and packet jitter. Engineers can
configure eCPRI message types according to eCPRI specification, measure bandwidth for each message type, and
measure Round Trip Delay (RTD) with sub 5ns accuracy. CPRI BERT verifies 4G BBU to RRU transport quality. By
performing FTN tests, engineers can validate the transport requirements of the FTN and can ensure they are within
the designed network specifications.

5GC
(UPF, AMF, etc)
EPC
(MME, SGW, PGW, etc)

GOOD POOR

CU/O-CU 1

3GPP F1
FTN Connectivity and QoS 1
• Measure bandwidth, delay, and
BBU O-DU
2 jitter per message type
CPRI eCPRI • Verify QoS for eCPRI packets
RoE
1 2 • CPRI BERT verifies 4G BBU to
FTN RRU transport quality 2
• PTP test verifies fronthaul
WDM synchronization quality
Fiber

Connectivity to O-DU/O-RU 2
FTN and Latency Measurement
RoE
1 2 • Establish connection by
CPRI eCPRI performing eCPRI one-way
2 delay (OWD) protocol
RRU O-RU
• Latency from/to O-RU (or O-DU)

RF

Figure 8. Fronthaul Analyzer – 4G /5G FTN test

O-RAN open fronthaul networks can be synchronized in several modes as depicted in figure 9 and as described
in the O-RAN WG4 CUS specification. Where LLS-C1 through LLS-C3 modes rely on PTP/SyncE for O-RU
synchronization, LLS-C4 works based on a local GNSS-based timing source. The LLS-C1 mode obtains its source
from the O-DU, whereas LLS-C2 and LLS-C3 deploy one or several fronthaul transport nodes between the O-DU
and O-RU. In LLS-C2, the Telecom Grandmaster (T-GM) resides in the O-DU; in LLS-C3, that function is assigned to
the fronthaul network, and both O-DU and O-RU play the role of a telecom time slave clock (T-TSC).
11 Test Suite for O-RAN Specifications
The PTP networks can support an ITU-T G.8275.1 (Full Timing Support) profile, or ITU-T G.8275.2 (Partial/Assisted
Partial Timing Support) profile. The former profile is expected to be the main one to be deployed in future
fronthaul networks. It is characterized by one or several Telecom Boundary Clock (T-BC) functions resident in
the fronthaul transport nodes. They ensure the proper function and performance of the synchronization plane
in line with network limits provided in standards such as ITU-T G.8271.1. Timing error constitutes one of the most
important parameters for the proper operation of the radio network. The T-BERD/MTS-5800 100G delivers the
complete set of testing parameters, thresholds/masks and profiles for verification of synchronization standards.
The measurements can be performed at the output of any T-BC as provided in the example of LLS-C3 mode below.

O-DU O-RU
PRTC
LLS-C1 T-GM T-TSC
Fronthaul

O-DU O-RU
PRTC
LLS-C2 T-GM T-BC T-BC T-TSC
Fronthaul

O-DU O-RU

LLS-C3 T-TSC T-BC T-BC T-TSC

Fronthaul
PRTC
T-GM

LLS-C4 O-DU O-RU

Fronthaul PRTC

Figure 9. O-RAN WG4 S-Plane Topologies

12 Test Suite for O-RAN Specifications

Use Case 6: Control/User Plane Connectivity and Packet Capture
eCPRI based O-RAN technology relies on transmission of control plane (CP) and user plane (UP) packets between
the O-DU and the O-RU. In an O-RAN environment with O-DU and O-RU from potentially different vendors, any
anomaly in transmission of control and user plane packets can lead to problems in O-RU or O-DU. T-BERD/MTS-
5800 with O-RAN support not only can check the health of the open fronthaul, but it also can capture O-RAN
CP and UP packets and filter those packets to validate if the packet transmission is compliant with the O-RAN
fronthaul protocol specification. Operators can view the captured and filtered packets in wireshark expediting the
analysis and allowing faster troubleshooting and a successful on-time network launch.

5GC
(UPF, AMF, etc)
EPC
(MME, SGW, PGW, etc)

CU/O-CU

O-RAN WG4 3GPP F1

Open Fronthaul CP/UP Health Verification
• Message count
C Plane U Plane S Plane
O-DU • Bandwidth for UP and CP
O-RAN OFH

eCPRI / eCPRI / PTP

RoE RoE SyncE

L3 (optional)
Splitter CP/UP Packet Capture and Filter
Ethernet L2 + VLAN (optional)
• UP and CP packet capture
• Wireshark analysis
Ethernet L1
O-RU

RF Filter

Packet
Capture

Analysis

Figure 10. CP/UP Analysis using an T-BERD/MTS-5800

13 Test Suite for O-RAN Specifications

Use Case 7: RIC and xApp Mixed Vendor Ecosystem Assurance
The O-RAN Alliance is currently defining the RAN Intelligent Controller (RIC) which has two principle logical
components. The non-real-time RIC (non-RT RIC) forms part of the vendor’s service management and orchestration
(SMO) framework and may implicitly use the SMO’s O1/O2 interface (O2 connects to the RAN virtualization platform)
for collecting data from the RAN and for making configuration changes. Additionally, the non-RT RIC may use the
A1 interface, defined by O-RAN, for disseminating policy information to the near-RT RIC. The near-RT RIC is located
with the O-CU network element of the vendor’s gNB. It connects to the RAN via the O-RAN defined E2 interface
which gives the near-RT RIC access to information exposed by the RAN and permits modification of RAN operation to
execute policies passed down by the non-RT RIC.

The RIC and RAN together operate as a set of nested control loops. The O-DU operates in “real-time” with a sub 10
ms response time; the near-RT RIC operates in the 10 ms to 1 s range; and the non-RT RIC operates with response
times of 1 second and greater. The response time associated with each element is indicative of where the decision
functionality of use cases with that response time would be expected to be located.

The inputs and outputs of the near-RT RIC are defined by open interfaces. The O1/O2 interface is under review by
standard bodies, and the A1 and E2 interfaces are standardized by O-RAN. The functionality of the near-RT RIC will
be performed by a mix of xApps. These xApps will likely be from a variety of suppliers including the RIC vendor,
in-house developments from the operator, and third parties. The xApps are expected to ingest RAN data from
various sources including over E2, performance management (PM) data over O1, enriched data that may mash-up
internal data and external data over O1, as well as data from other xApps. The xApps will process this data and
ultimately implement A1 policies over the E2 interface.

The O-RAN ecosystem needs assurance across all stages of the product life cycle from sandbox development
through to assurance of network operation. It is essential to ensure that once xApps from disparate sources are
available, they operate in a coherent and compatible manner—either when operating in an independent manner
or chained together—and produce the required objectives. This includes validation that the heterogeneous xApps
in combination are able to implement the policies of the operator across a mix of subscribers consuming the range
of services envisaged for the network across multiple network slices and in an appropriate set of mobility profiles.
It must also be validated at scale, making it a use case well suited to VIAVI End-To-End Wireless Network Test.

14 Test Suite for O-RAN Specifications

Use Case 8: Operational Assurance, Troubleshooting and Optimization
As described above, there are profound benefits of disaggregation of the network into multiple discrete
components with a decoupled control system in the form of the RIC. And with more components comes more
complexity and an increased number of ways for the network to experience impairments. Impairments in a more
complex network can be harder to detect, diagnose and resolve than they would be in a simpler network with
fewer components.

Considering the many and varied potential ways that the operational network can experience degraded
performance, the network may suffer from impairment or failure in the transport network (fronthaul, mid-haul,
backhaul). This may range from congestion leading to latencies or packet loss out of acceptable ranges, to complete
loss of a fiber link through breakage or physical disconnection. The disaggregated functions may become impaired,
for example, through overload or software quality issues. The core network functions may suffer impairment for
similar reasons. The SMO system may experience impairment or the physical infrastructure on which the logical
functions are hosted may degrade. The 5G New Radio (5GNR) is a shared resource in a harsh environment and can
sometimes be poorly tuned to the demands placed on it by the subscribers. Concentrations of increasing demand
for 5G services can lead to congestion on the radio resources. Poor coverage or interference can impact on the
accessibility of the network services. These phenomena will vary as the spatial dynamics of demand for services
around the network changes. And as the demand for different mixes of services with novel mobility profiles
pushing the resource management capability to the limit, new edge failure cases beyond what was tested at the
pre-deployment stage can be exposed and manifest as degraded performance.

Each of these phenomena will manifest in the complex system in different ways, not necessarily associated with
the network component directly suffering the impairment. For example, a loss of a radio unit through hardware
failure will mean that nearby O-RUs, O-DUs, and O-CUs will pick up more traffic along with subjecting the X-haul
links to more load and potentially congestion. This challenges the network monitoring and assurance system to
provide a more complete view of the network, with richer analytics to detect problems, isolate the cause and
provide the most appropriate mitigation.

The VIAVI NITRO™ platform provides the visibility of the network across the breadth of the radio, RAN, transport
and core. This unprecedented visibility brings with it the ability to detect instances of issues such as congestion of
spectrum or transport assets, or impairment of physical or logical infrastructure. The intimate view on the network
means that the location of the problem can be quickly isolated and the root cause identified. Thus, with the richest
information on the network performance, the autonomic network control systems will be most effective and where
intervention by the operational network management engineers is required, resolutions can be implemented within
the shortest timeframes.

15 Test Suite for O-RAN Specifications

Conclusion:
O-RAN brings many benefits for operators such as an open ecosystem that removes vendor lock, lays down
the foundation for virtualized network elements, and introduces white-box hardware that can be quickly
scaled up through software-based nodes. At the same time, it also creates significant challenges in terms of
test and integration. Having the right test and network management strategy and the right partner during the
development, deployment and operation of an O-RAN network can help operators overcome those challenges.

VIAVI has the expertise, legacy and vision to help operators validate open RAN components, both hardware and
software in the lab. And with our NITRO™ Mobile integrated field and assurance solution, operators can be certain
network performance issues will be isolated and rectified quickly to meet their KPI goals.

VIAVI End-to-End Solution Portfolio for O-RAN

Functional / Performance / Capacity Testing / Troubleshooting & Assurance

4.5G RRH 4.5G C-RAN

EPC / NGC
Fronthaul Midhaul Backhaul

5G O-RU 5G O-DU 5G O-CU

Data Center &
Radio Fiber Access Transport Interconnects Core network

Lab
4G and 5G Device and O-RU Test O-DU Test O-DU Test O-CU Test Core Test RAN Test
Application emulation O-DU Emulation O-RU Emulation O-CU Emulation O-DU Emulation RAN Emulation Core Emulation
End User Simulation

Field
CellAdvisor 5G 3Z RF Vision TBERD/MTS Network Tester
RF Beam Analysis Antenna Alignment X-haul, Latency, Timing and Sync testing

Assurance
NITRO Mobile NITRO Fusion NITRO Mobile
Optimization and Transport network xHAUL Assurance
Automated GEO location Virtual service activation and PM

NITRO MOBILE PLATFORM

Figure 11. VIAVI Test Suite for O-RAN Specifications

16 Test Suite for O-RAN Specifications

Appendix 1:
The O-RAN Alliance management structure consists of a board made of operators and a Technical Steering
Committee (TSC). Nine technical workgroups have been set up under the supervision of the TSC with specific focus
areas as shown in Figure 12.

O-RAN Working Groups

WG1 - Use Cases and Overall Architecture

WG2 - The Non-real-time RAN Intelligent Controller and A1 Interface

WG3 - The Near-real-time RIC and E2 Interface Workgroup

WG4 - The Open Fronthaul Interfaces

WG5 - The Open F1/W1/E1/X2/Xn Interface

WG6 - The Cloudification and Orchestration

WG7 - The White-box Hardware

WG8 - Stack Reference Design

WG9 - Open X-haul Transport

Figure 12. O-RAN working groups

References
[1] O-RAN: Towards an Open and Smart RAN; October 2018

Contact Us +1 844 GO VIAVI © 2020 VIAVI Solutions Inc.

(+1 844 468 4284) Product specifications and descriptions in this
document are subject to change without notice.
To reach the VIAVI office nearest you, oran-testsuite-wp-wir-nse-ae
visit viavisolutions.com/contact 30191049 900 0320

viavisolutions.com