Shift left to tackle key O-RAN verification challenges

Designing a 5G system brings new challenges. Unlike all four previous standards, the 5G standard addresses multiple requirements coming from growth in mobile users, IoT proliferation, and autonomous driving vehicle development.

In addition, 5G broke through the proprietary and strenuously protected approach known as the Closed Network. The ensuing disaggregation of the radio base-station into its components opened opportunities for more wireless companies to be a part of the network. This disaggregation introduced new hurdles, and chief among them is the interoperability requirement of the Open Radio Access Networks (O-RAN) components designed by a diverse set of third-party developers.

Safeguarding standards compliance and interoperability between base-station components has also brought pre-and-post-silicon O-RAN verification into the spotlight within the design process.

O-RAN interoperability verification

Until now, interoperability testing has only been possible in the post-silicon stage when a manufactured O-RAN compatible Radio Unit (O-RU) is connected to a manufactured O-RAN-compatible Distributed Unit (O-DU) through O-RAN Fronthaul in the integration lab. Consequently, interoperability testing has too often become a time-consuming and error-prone effort. This can lead to delays in the schedule and increase the risks of failures for O-RAN based multi-vendor integrations.

Now, a shift-left verification methodology lets users initiate interoperability and conformance tests in a pre-silicon environment as soon as early register transfer level (RTL) code and bare-metal software is available.

The Shift-Left Verification Flow

For some time now, the shift-left verification methodology has succeeded in shortening the development cycle and improving the quality of SoC designs. The success of the methodology stems from the tight integration of software-based verification engines with hardware-based verification platforms. Working on the same hardware/software SoC design and switching between views of each on-the-fly to take advantage of each engine according to specific tasks allows for outstanding overall quality of testing in a short timeframe (Figure 1).

Figure 1. The hardware/software verification process proceeds in five stages and seven steps
(Siemens EDA)

Shift-left verification for O-RAN interoperability testing

Shift-left alone does not ensure interoperability, however. For that, it is necessary to deploy high-quality test cases shared between the pre-silicon phase and the post-silicon lab environment.

An efficient 5G virtual solutions should facilitate the creation of executable specifications for O-RAN based SoC development. With such a solution, O-RAN spec-like parameter sets come to life as O-RAN Control- and User-Plane traffic streams in simulation and emulation environments. A virtual model of a 5G Fronthaul should also support dynamic management- and Sync-Plane traffic streams, including NETCONF/YANG and PTPv2. With the help of these executable specifications for O-RAN, it is possible to model, verify and prove the functionality of the O-DU and O-RU in the virtual world.

The same O-RAN Fronthaul executable specifications from virtual environments can also be deployed in the 5G SoC bring-up phase in a lab. This unified test environment ensures effective and efficient bring-up of SoCs.

O-RAN Fronthaul interoperability is best ensured by verifying the O-DU and O-RU against these agreed-upon executable specifications (i.e., using the feature set of one unit as a golden reference for the verification of the other). The O-DU is made to work against a virtual model of a corresponding O-RU in pre-silicon verification. The O-RU is simulated or emulated against its virtual O-DU counterpart. The result is that the required O-RAN Fronthaul parameters, timings, and mechanisms work as anticipated when integrating the two units.

More specifically, the test cases should implement executable specifications that accurately describe the functionality of the complementary devices in the radio access network. The approach warrants efficient and effective integration of O-RAN devices as they have already been designed and verified to work against the O-RAN profiles used by their counterparts.

In many cases though, O-RU and O-DU development processes take place independent of one another because these two components often originate from different teams or different wireless companies. From an interoperability viewpoint, the sooner the O-RAN Fronthaul profiles of the O-RU and O-DU can be aligned in the pre-silicon phase, the faster and better results can be obtained, avoiding surprises during the integration phase.

The problem is that even when an O-RU passes O-RAN conformance tests, there is no guarantee that it will work correctly with a third-party O-DU. This forces significant testing efforts, not only in the conformance context but in interoperability assurance. Such interoperability testing means a whole new set of requirements for a test system.

Conclusion

5G solutions built to enable a true shift left in 5G radio development help to avoid discontinuities when the verification focus moves from virtual models to actual hardware in a lab. These 5G solutions satisfy the testing needs of today’s high-end radio SoCs and into the future.