Interoperability Issues Threaten O-RAN Fronthaul Networks

5 mins read

As O-RAN Fronthaul networks take center stage in the quest for seamless connectivity, unverified interoperability threatens to cancel the show!

The O-RAN Fronthaul network plays a crucial role in the evolution of wireless communication technologies. It is the critical low-latency part of the network, efficiently transmitting data and control signals between the central processing unit (O-CU), distribution units (O-DUs) and radio units (O-RUs) to deliver optimal network performance, scalability and flexibility.

In the real world, however, the Fronthaul network performance can be severely degraded as soon as the link experiences any of the impairments normally found on live networks such as jitter, bit error and latency. These impairments hamper a device’s ability to maintain functionality, connectivity, and interoperability, ultimately failing on the mission to deliver a seamless performance.

Excessive latency is one of the main impairments that can impact Fronthaul performance.When it occurs on the network, it can cause link loss, which can then trigger the O-RU tolose lock to its clock reference, causing further time and synchronization issues. This means that the devices in the Fronthaul (O-DUs and O-RUs as shown below) must be able to tolerate this latency to ensure reliability and responsiveness, and beyond that, interoperability.

                                                 5G Functional Split: O-CU, O-DU and O-RU

As a result, deploying a reliable low-latency Fronthaul network that delivers on its promise requires a significant amount of testing and validation for O-RUs and O-DUs with regards to their latency tolerance.

Latency Tolerance – Do you know your category?

In order to provide guidance on latency tolerance and enable devices to be categorized for interoperability, the O-RAN Alliance WG4 standards (which addresses Open Fronthaul Interfaces)define the test requirements to be carried out for O-RUs and O-DUs to gain conformance and interoperability validation.

One of the key tests within this is O-RAN Conformance to Latency, which is specified in O-RAN Control, User and Synchronization Plane Specification Annex B. This provides the minimum and maximum delay limits for a given device category and is required to be validated by testing.

The device category provides guidance to the open market on its validity and interoperability with other devices.

                          Figure B.1-1: Definition of reference points for delay management

To prove interoperability with other devices, the O-RAN WG4 Control, User and Synchronization Plane Specification informs the interoperability testing (IOT) requirements for O-DUs and O-RUs from different vendors connected using the O-RAN Fronthaul interface.

As mentioned, O-DUs and O-RUs are categorized by their delay characteristics for easy evaluation. They are defined in “delay categories” and “delay sub-categories” to allow the matching of O-DU and O-RU units and ensure proper operation to meet a service provider’s network delay requirements. A key reason for the many different categories of O-RUs is that longer delay requirements (for longer distances) will lead to more buffering and significantly affect the cost and complexity of the O-RU. An in-building application with short network delays will require smaller buffers and a lower-cost implementation.

There are two tables (see below) which list the O-RU categories versus the O-DU categories. Table B.2-2 is for the maximum delay supported for each category combination, and Table B.2-3 is for the minimum delay supported for each category combination.

Tables B.2-2 and B.2-3 shown below are intended for use by network providers to determine the best- and worst-case T12_max / T34_max values that can be supported by a given equipment combination. Alternatively, network providers may locate the desired T12_max / T34_max and select from the equipment combinations meeting those criteria. Common criteria are identified by different colors on diagonals through the tables.

                     Table B.2-2: Latency_min (Minimum supported T12_max/T34_max in µs)

                    Table B.2-3: Latency_max (Maximum supported T12_max/T34_max in µs)

Vendors need to test conformance to both the minimum and maximum latency tolerance figures in these tables for their category of device(s).

As mentioned, the objective is to verify conformance to latency as specified in Tables B.2-2 (minimum latency) and B.2-3 (maximum latency). This is achieved by adding the maximum and minimum delays for the particular category of O-RU and O-DU being tested and then verifying that the O-RU remains in lock.

So, how do you test conformance? Network Emulation

Conformance can be tested using a network emulator specifically designed for 5G O-RAN Fronthaul testing. Such emulators need to have low intrinsic latency and low PDV/Jitter. Intrinsic latency less than 8µs is required to test all classes of O-RUs and O-DUs. PDV/Jitter needs to be less than 100ns to avoid O-RUs losing lock. The emulator also needs to be PTP aware, in other words integrated PTP functionality such as a transparent clock (TC). TC capability will ensure that high-priority S-plane traffic is not affected by large user-plane (jumbo) packets and will ensure the O-RU does not lose lock.

Embracing network emulation for interoperability testing and validation not only safeguards against potential pitfalls and performance issues but also fosters innovation and collaboration within the industry, paving the way for O-RAN to be the enabler of unparalleled network performance.

For more information on the Calnex O-RAN Fronthaul network emulator, please visit: calnexsol.com/products/calnex-sne-ignite/