In September, the Open Networking Foundation (ONF) added a welcome dose of heavyweight experience with open telecoms platforms when it announced its SD-RAN initiative, though it also injected a further note of confusion into the open RAN debate. Now it has made its intentions clearer with the publication of version 1.0 of SD-RAN, a cloud-native platform that provides developer frameworks based on O-RAN’s underlying architecture.
A key focus of the O-RAN Alliance, and its most significant new contribution to vRAN architecture, is the RAN Intelligent Controller (RIC), which abstracts control functions that were traditionally embedded in the base stations. It has two strands, addressing non-real time and near-real time processes.
The non-real time RIC is relatively uncontroversial, since many higher layer network control functions were already becoming virtualized and opened-up within broad orchestration systems such as ONAP. But there is heated debate over whether near-real time control, which applies to very demanding Layer 1 and 2 processes such as beamforming for Massive MIMO, can be implemented as software applications without performance trade-offs.
The strongly operator-centric make-up of ONF should help bring a dose of realism to the debate. One of the reasons ONF gave for initiating SD-RAN was that O-RAN itself was becoming too driven by large vendors, while it would reflect the real requirements of diverse operators. And ONF’s considerable experience in defining architectures and developer platforms for different network domains, including the CORD (central office re-architected as a data center) projects, is welcome.
The other significant area of ONF experience is in full open source licensing (its projects are hosted by the Linux Foundation). The balance between open source and licensed models within O-RAN and Telecom Infra Project (TIP) is somewhat confused at this early stage.
There will inevitably be both models – some vendors will not participate in an open source-only initiative as they would lose key IPR differentiation and revenue; some operators are wary of open source when it comes to highly secure technologies. At an early stage in its life, TIP introduced a licensed model alongside its original open source framework.
O-RAN has the O-RAN Software Community – an open source grouping that sits alongside the O-RAN Alliance – which recently published its ‘Cherry’ software release. Cherry contains new functions aligned with O-RAN specifications including the E2, A1 or O1 interfaces, and new service management & orchestration (SMO) elements.
So far, open source has a very limited role in the RAN market, even though open source base station projects, such as OpenBTS, have existed since 2G days, and Huawei executives demonstrated the potential for a base station made entirely of open source components seven years ago. There have been trials in the O-RAN environment – in June, Nokia and AT&T conducted a live trial of a co-developed RIC over the operator’s commercial 5G mmWave network in New York City using an Open Cloud Platform based on the LF Edge-developed Akraino open source software stack.
But the dream that a vendor or operator could download open source, free software to a baseband or radio unit is too challenging to the established business models, even for Rakuten’s vision of an app store-like platform for building a RAN. According to Daryl Schoolar, practice leader at research firm Omdia, the total contribution of open source to RAN in the first nine months of 2020 “would be at a maximum $600,000 against a market we estimate to be around $29.5bn”.
Steve Papa, CEO of O-RAN challenger Parallel Wireless, told the firm: “It’s just that the radio software, as it turns out, is as much about your test and quality assurance environment as it is the software itself, and that requires specialized equipment and whatnot that doesn’t lend itself well to an open source development community.”
But despite these warnings, Release 1.0 of SD-RAN promises a “complete open source RAN solution for developers” spanning the key O-RAN elements – the nRT RIC, the radio unit, distributed unit and central unit (RU/DU/CU), and a framework for developing xApps, the concept underpinning the RIC. This can be implemented entirely virtually or on reference white box hardware (see inset).
The release also includes the first stages of a software development kit (SDK) to make it easier to create xApps that can be ported across different RICs. This may be important, with several vendors announcing RIC developments – Nokia and Juniper among the majors – and potential fragmentation between their implementations, and even the specs laid down by O-RAN and ONF. TIP has also recently announced a RIC-focused activity, RIA, though this aims to provide deployment frameworks rather than its own set of specs.
ONF’s fledgling SDK is being shared with the O-RAN Software Community to support and promote availability of interoperable xApps that can work with a selection of nRT-RIC implementations.
Current SD-RAN community members within ONF include Aarna Networks, Airhop Communications, AT&T, China Mobile, China Unicom, Cohere Technologies, Deutsche Telekom, Facebook, Google, Intel, NTT, Parallel Wireless, Radisys and Sercomm.
These names have much overlap with other initiatives, but ONF’s agenda may be quite different from that of O-RAN.
Like TIP, ONF focuses on open platforms that go well beyond the RAN with the aim of achieving common cloud-based architectures and developer frameworks across all domains. ONF has previously focused on open source platforms for the mobile core (OMEC), telco data center, packet switching, optical transport and passive optical network.
And when it announced SD-RAN, the ONF pointedly promised a more “truly open” RAN ecosystem.
Timon Sloane, its VP of marketing, said RAN vendors are increasingly active in O-RAN and are starting to “advocate for standards that are beneficial to their businesses”. He did not give specific examples, but Nokia’s development of the RIC, and the work of Nokia and Samsung on foundational O-RAN interfaces, are cases in point.
While large vendors, with their significant expertise and R&D teams, are important in driving development, testing and adoption of new platforms, they can also twist the agenda towards their own ends. Sloane claims rising vendor influence on O-RAN is making it hard for operators to shape the work agenda. “What we’re seeing is that more vendor-specific contributions are being made and some are even in binary form, not even open source,” he told SDxCentral. O-RAN now has 150 vendor contributors.
But the ONF is not promoting a full alternative to O-RAN. Instead, it aims to use the O-RAN architecture and specifications as its starting point, but identify where there are gaps or needed improvements, especially in terms of operator requirements. It then plans to feed its findings back into the community in the shape of open source projects to address the shortcomings.
“We’ll do some code sharing where it makes some sense and certainly we want to have common APIs and we’d love to have interoperable implementations come out of open communities,” Sloane said. “We’re not trying to fork off from O-RAN. What we’re doing is compatible with O-RAN and is really, in our view, just helping fill some of the holes.”
That would, the ONF argues, keep true to the spirit and original objectives of O-RAN, which was set up to be heavily operator-driven, and address the risk – seen in many open technology movements in the past – that an open platform becomes just another large vendor lock-in. That can happen if a single supplier comes to have an unassailable influence, or if several vendors implement the specs in proprietary ways, as happened with the CPRI fronthaul interface and 3GPP’s X2 base station interface.
Some of the early O-RAN designs are not fully open, claims the ONF. “Handover is not possible in an xApp. Handover is still a baked-in feature in their device. That’s just one concrete example of the spectrum of functionality that’s still not really in these xApps,” Sloane said. The ONF will take a pragmatic approach to speed up time to market, mixing vendor and open source xApps in a way that may seem to compromise the open RAN vision, but could deliver workable, trusted solutions more quickly. “These solutions are going to definitely include closed source RAN components. It doesn’t mean the full RAN goes open, but it does mean that some critical key building blocks go open,” noted Sloane.
The ONF claims it is well-positioned to avoid falling into the trap of undue vendor influence, because it has proven in past projects that its model provides safeguards against that. The approach is to develop and demonstrate a solution which forces stakeholders to look at the market with a new eye, because the commercial upsides are clearly proven.
Another difference between the ONF and many other open initiatives is that it has a significant inhouse engineering team, and so is less reliant on contributions from large vendors. “Instead of just arguing, what we at ONF do is say ‘OK, we’ll go do it’,” said Sloane. “That’s why ONF has an engineering team. ONF is different than every one of these organizations because ONF is an engineering organization” (at least 80% of its staff are engineers).
SD-RAN Release 1.0:
Release 1.0 of SD-RAN centers on a lightweight end-to-end O-RAN stack that provides a
development environment for building xApps (composite applications that can combine web services and data from multiple systems within a common framework). It includes:
- µONOS-RIC – ONF’s nRT-RIC based on its open network operating system or ONOS, which interacts with RAN hardware (RU/DU/CU) via O-RAN E2AP interfaces, encodings (ASN.1), transport-protocols (SCTP) and service models (SMs).
- A white box-based RU/DU/CU, leveraging software from the open source Open Air Interface project, enhanced to expose O-RAN consistent interfaces and protocols.
- SD-RAN can run on this reference white box hardware, or it can be instantiated entirely in a virtualized form in a distribution package called RiaB (SD-RAN-in-a-box). The entire distribution including xApp, µONOS-RIC components, CU/DU, user element (UE)and ONF’s OMEC mobile core, can be instantiated within RiaB with a few simple commands, the Foundation claims.
- To integrate with µONOS-RIC, the CU-control plane RAN component has been enhanced with an E2 Agent that exposes the KPM-SM information elements to xApps, that connect to the nRT-RIC and subscribe to the KPM service.
- There is also an end-to-end solution that also allows the RAN components to interact with Samsung Android handsets and the OAI User Element (UE) emulation software. For mobile core integration, the RAN components interact with ONF’s OMEC open source core.