SD-RAN: A Familiar Tussle Unfolding
Another Study in the Importance of Defining Interfaces
We have written several posts on the reengineering of the 5G Mobile Core as a collection of microservices, but arguably the bigger transformation for 5G is happening in the Radio Access Network (RAN), where the SDN principles of disaggregation and centralized control are being aggressively applied. The goal is to build a Software-Defined RAN (SD-RAN), primarily to accelerate the pace of innovation, but also to lessen the grip of vendor lock-in that has dominated the marketplace. As we’ve seen many times before, getting the interfaces right is critical for the success of such a project.
The heavy lifting is already done on the architectural side. The RAN packet processing pipeline, which has historically been bundled and deployed in proprietary base stations, has been split into three disaggregated elements: a Radio Unit (RU) is responsible the D-to-A and RF layers; a Distributed Unit (DU) is responsible for segmentation/reassembly and the real-time scheduling of individual segments for transmission; and a Central Unit (CU) is responsible for data integrity and header compression. The CU also implements the RAN’s near-real-time control logic, deciding which base station—or in the new split RAN, which DU/RU combination—is best positioned to serve a given device at any moment in time. This control logic is centralized in the CU, so it is natural to run it in the cloud. Moreover, the CU control logic fits a familiar SDN design pattern: a Network OS hosting a set of Control Applications. In 5G-speak, these components are called the RAN Intelligent Controller (RIC) and xApps, respectively, but the purpose is exactly the same as in SDN: (1) to disaggregate the control and data planes, and (2) to provide a platform that catalyzes a marketplace of innovative control applications.1
The architecture is sound, and several implementation efforts are well-along. The SD-RAN project of the ONF is a great open source example. It has repurposed the ONOS Network OS as a RIC, and includes a nascent collection of xApps, including handover control. Having an open source implementation shines a bright light on the central unresolved issue: getting the interface definitions right. In particular, we are talking about the interface by which the RIC controls the various RAN elements (i.e., the set of RUs and DUs, and CU’s data plane). And as is usually the case in such scenarios, we can’t answer this question in a purely technical way. The O-RAN Alliance is an operator-led standardization effort trying to define this interface, known cryptically as E2. (There is a second relevant interface—the RIC’s Northbound Interface exposed to xApps—but this NBI will likely be an embellishment of the E2 interface the RIC uses to control the RAN elements.)
Taking a step back and revisiting the OpenFlow interface that set the SDN train in motion for wired networks helps us understand the E2 interface. OpenFlow is based on a powerful-but-simple flow abstraction, defined as a Match/Action pair. The E2 interface doesn’t have such a simple analog, in part because it is designed to both control and configure the RAN elements. But in principle, it does map onto an equally straightforward RESTful interface consisting of GET and PUT operations on a well-defined set of resources. This would naturally suggest using a transport protocol like gRPC and a data serialization spec like Protocol Buffers to define the API. Sadly, in a reflection of the telecommunications-based origins of the mobile network, E2 is based on ASN.1(!). That unfortunate choice is likely to be the least of our worries about getting the E2 interface right. The real challenge is settling on a schema for the resources (variables) that the RIC can read (observe) and write (control).
This is where the OpenFlow experience—and its shortcomings—is instructive: even though OpenFlow was intended to be device-agnostic, it evolved in a way that tightly coupled Control Apps with the specific flow tables supported by the underlying switches. The E2 interface faces the same risk. There is now a movement towards gRPC-style interfaces replacing OpenFlow in the SDN world for exactly this reason. One has to wonder if SD-RAN can learn from this experience.
What we are seeing here is a familiar tussle between customers (i.e., mobile network operators) who benefit from a shared schema for commodity devices, and providers (i.e., mobile network vendors) who benefit from preserving their product’s unique capabilities. It is also why the operator-led O-RAN Alliance is taking the lead, side-stepping the vendor-dominated 3GPP that has long been responsible for standardizing the mobile network. And the stakes are high: there is a wealth of telemetry information that xApps developers would like to take advantage of (including reports about signal quality from individual devices connected to the RAN), yet vendors are incentivized to retain high-value functionality on their devices (rather than be limited to a set of commodity features).
To this end, the E2 interface is being defined around a Service Model abstraction. The idea is that each RAN element advertises a Service Model, which effectively defines the set of RAN Functions the element is able to support. The RIC then uses the E2 interface to issue a combination of the following four operations against a given Service Model:
Report: RIC asks the element to report a function-specific value setting.
Insert: RIC instructs the element to activate a user plane function.
Control: RIC instructs the element to activate a control plane function.
Policy: RIC sets a policy parameter on one of the activated functions.
The Report and Policy operations are essentially different names for GET and PUT. It’s the Insert and Control operations that open the door for RAN vendors to implement unique features, with the consequence of locking in both their RAN devices and any xApps they have written take advantage of those features.
The unanswered question, at this point, is whether the operators will be able to collectively converge on a handful of “universal” Service Models that vendors are willing to support. Keeping the SD-RAN implementation open source is likely a prerequisite for that to happen. But it is probably not sufficient. A second useful lever would be to adopt P4Runtime-like tooling that is now correcting for the limitations of OpenFlow. Being able to auto-generate the “E2” interface from a language-based specification for a given RAN device is a proven strategy, embracing a fully software-defined network stack that includes the interface used to cross the control/data plane boundary.
Note again the importance of defining interfaces in a way that is both rigorous (i.e. using a specification language) and independent of any particular implementation. This supports verifying the correctness of networks and fosters more rapid innovation—one of the guiding principles of SDN. With the set of players in the 5G world expanding beyond the traditional telcos and their incumbent equipment providers (e.g. Helium, FreedomFi, Rakuten), we hope to see the SD-RAN architecture and corresponding interfaces supporting innovation in this space just as we have seen with SDN for wired networks. However, such an outcome is not yet assured.
In a follow-up to our last post on network verification, Bruce sat down with VMware’s Martijn Smit to talk about how he sees automated remediation of network faults playing out in an SDN world. And we made our first contribution to the dedicated network verification site netverify.fun. We’ve also picked up the editing pen to resume work on our TCP Congestion Control book just as the paper on Data Center TCP (DCTCP) won the SIGCOMM test of time award.
If the RAN packet-processing pipeline (i.e., protocol stack) is unfamiliar, you can think of each base station as a packet switch with an antenna attached to it. A set of interconnected base stations, overlaid on top of a backhaul network, forward packets and other control information to each other in an effort to collaboratively make decisions about how to best utilize the radio spectrum they share. You can learn more here and here.