EE World spoke with Adam Smith of LitePoint about the progress and challenges of Open RAN interoperability and testing.
We’ve been hearing about Open RAN for some time now. The disaggregating of the telecom radio access network from a single baseband unit into a radio unit (RU), distributed unit (DU), and centralized unit (CU) has occurred in some deployments. The key to making Open RAN work is interoperability in the interfaces between the RU, DU, and CU.
Adam Smith, LitePoint
EE World: Adam, thank you for speaking with EE World. You were recently on a panel session where you discussed Open RAN interoperability. Who’s going to solve the problems? Are we talking about the physical layer interfaces between the radio unit, the distributed unit, the central unit?
Smith: The first thing we must answer is, “What does interoperable mean?” It does not necessarily mean plug-and-play. When people talk about plug and play, that to me means something very specific. For example, I can choose vendor ABC right off the shelf, just put it in place, and nobody must put duct tape and glue on it to make it work. It just works. Getting to true plug-and-play is, I think, the vision of Open RAN.
Interoperability might be a subset of true plug-and-play. System integrators must make sure that things work together at the entire system level. The interfaces between the CU, DU, and RU all need testing to make sure that they’re interoperable. What matters is at the system level.
We’re finding that we’re immature. It’s the same with every new technology; It’s taking baby steps to get to a working prototype. The whole goal of this is to open up the ecosystem to more players to create diversity in the ecosystem.
EE World: For people who come from, say, the datacom side, for example, the interfaces between these units are generally some form of Ethernet, is that correct? People expect Ethernet products to be plug-and-play. That’s not what the case here is, as you’ve said.
Smith: I’m very centric around the radio unit. So, what we’re focused on doing is bringing new vendors into the market who make RUs. The interface between the DU and the RU is not Ethernet; it’s an optical interface but even there, that interface is not a digital interface. It’s a digital representation of an analog interface because a lot of the digital processing that used to be in the RU has moved more to the DU. So, even though there is digital information going between the DU and the RU, it’s still an analog signal. That’s largely what we’re seeing right now as the “interoperability” issues between our RUs and the DUs.
EE World: The panel discussion brought up that there is a transition border between what 3GPP does and what the O-RAN Alliance does. Can you describe where that transition takes place? And then, you also mentioned some interpretation issues with the specs, which comes up with almost any spec.
Smith: The radio unit is the perfect example where 3GPP and O-RAN come together. The air interface from the antenna to the world is 3GPP. It’s very well defined and very well understood; every 5G network operating today operates on the same 3GPP interface specifications. There’s nothing new about that part of the spec. Now, whether you’re doing a Release 16 or Release 15 RU versus user equipment (UE), we can talk about 3GPP specs on the air interface side. On the RU, instead of having an Ethernet connection, now we have a new fronthaul interface that’s 100% defined by the O-RAN Alliance. The 3GPP spec does not say, “Here’s what a fronthaul interface on a radio unit looks like.” In between the air interface and this optical interface on the RU, the specs transition from 3GPP to O-RAN Alliance digital transport spec.
EE World: In the case of a traditional integrated RAN, does all of that take place in the baseband unit?
Smith: In an integrated traditional RAN radio unit, all of the baseband and modem processing functionality is fully self-contained in the RU.
EE World: Now that we’ve disaggregated the RAN, and the interface coming off of the RU is under O-RAN Alliance jurisdiction, what kind of interoperability issues have you seen? That is, differences and interpretations between a manufacturer of a radio unit and a DU.
Smith: So far, I would categorize these into two different areas, one of which is interpretations of the existing spec while the other is technology immaturity. You’ll hear terms such as C-plane, U-plane, S-plane, and M-plane, which represent four different communication layers in this interface. Initial development focus has been on the C-plane and the U-plane. All four of these planes, the physical spec — signals, the voltage levels, the digital lead — are very well defined. We have, however, seen some scaling differences in different RUs, what’s called “dB full scale.” Some people use 10 bits, some use 12 bits. There is flexibility in the spec, and so people make assumptions or interpretations, and they do a development on that. Even though the physical interface is well-defined, the information that goes across an interface isn’t.
I’d say there’s we’re finding small gaps in the spec that will get addressed as more vendors get in place and as we do in our operability tests. Now, as far as the maturity of the spec, the C and the U planes are where everybody has been putting their initial efforts; the M plane seems to be vendor-specific. So vendor A, vendor B, and vendor C might have a different API on the M plane. That’s why I get into what plug-and-play means versus interoperability. If I give you the API for my radio unit, I can make it interoperable, but is that really plug-and-play? I think we’re marching down the maturity phase of O-RAN.
Lastly, we have the S plane, which is all your synchronization. That’s just been all over the map. That is, all the way from “we need an external synchronization signal coming from the DU” to people doing a true Ethernet-type PTP sync on the S plane. The maturity curve on the S plane is probably the least mature. We’ve got interpretation differences to work out.
Open Ran fronthaul interfaces consist of planes with different protocol stacks.
EE World: Can you describe the functions of these three planes, or at least say why they exist? The S plane is clearly synchronization, and EE World has published quite a number of articles on synchronization, including some that are O-RAN specific.
Smith: The C plane is a control plane. It controls signals between the radio unit and the rest of the network. Then there’s the U, or user plane. That’s largely where your data is. The configuration of the radio unit takes place in the M plane.
EE World: Who performs interoperability testing? Is there, for example, a test lab that engineers could go to? What about plugfests?
Smith: There are three areas to address interoperability. First, there is a defined conformance specification for the O-RAN interface. For the 7.2 fronthaul split, there’s conformance suite for the C plane, the U plane, the S plane, and the M plane. The baseline is “are you meeting the specs that are written in the O-RAN Alliance specification for conformance?” Secondly, the O-RAN Alliance holds plugfests, perhaps three or four per year around the world.
So far, we’ve observed that people are not taking vendor ABC’s product and just plugging it into the network; it’s largely demonstrating different components of the network. So, I don’t want to go as far as to say that it’s just a marketing event for the O-RAN Alliance. I would just say we’re very early in getting to what you would think of as a plugfest where you have multiple vendors physically interacting with each other. It’s largely just vendors doing demonstrations. Lastly, there’s live network testing, which is also extremely early. In most of the O-RAN deployments, we’ve seen single-vendor O-RAN networks where the same vendor is providing the DU, the CU, and the RU.
EE World: Let’s say I’m a radio unit manufacturer, large or small. What are some of the things that I would have to do to prepare for interoperability testing?
Smith: My answer will depend largely on the phase of your development. If you’re starting from scratch, the first thing you need to do is choose a silicon partner. That’s because your developments will depend on the tools you get from the silicon company. Silicon vendor A is going to have different software tools than silicon vendor B.
Once you get up and running with their suite of tools, you pick a family for whatever frequency band you’re designing. You need to figure out which global band you’re going for. Is this radio unit going to be used in an AisaAPAC-based radio unit or is it for North America? Currently, we’re seeing development in the FR1 (sub 6 GHz) band. We could see development in the FR2 mmWave band as well. That’s a completely different topic on the requirements side. Fundamentally, it comes back to when you’re ready to do interoperability testing, you’re going to start with conformance testing on the fronthaul side and the conformance testing on the 3GPP air interface side. First of all, you want to make sure you meet the basic specifications.
LitePoint radio unit tester
EE World: What role does LitePoint play in O-RAN testing?
Smith: For O-RAN testing, we provide test equipment to customers who are developing radio units so they can quickly characterize and get their products to market. We’re working with telecom equipment vendors and with chipset suppliers whose chips are in these radio units to characterize, calibrate, and validate that they meet both the 3GPP side of the spec as well as the O-RAN fronthaul side of the spec. Ultimately, we want to make sure that radio unit number one off the line works like radio unit 1 million off the line. We provide a scalable manufacturing system to produce these volumes.
EE World: Have you seen new players entering the market for radio units?
Smith: It’s absolutely moving in that direction. We’ve got traditional players that are participating in the O-RAN Alliance. We’ve got startups, particularly on the silicon side, that are participating in the O-RAN Alliance. I’ve also seen companies that have historically made network equipment such as access points, gateways, and set-top boxes are now making radio units. The ecosystem is growing.
