In a previous post we discussed the evolution of massive MIMO away from the early theoretical work (on eigenmodes) and toward today’s practical implementations using digital beam-forming to separate UEs and interferers — separating UEs spatially in order to deliver multiuser MIMO, and discriminating from interferers in order to improve SINR for DL and UL throughput.

Ericsson seems to be shipping massive MIMO radios as fast as they can build them, but of course theirs is a very proprietary product, meaning they’re at liberty to partition RAN functions between radio and baseband in any way they like. And they do. In a moment we’ll consider Ericsson’s so-called Uplink Booster.

Open RAN is different. The ORAN Alliance (work group 4) agreed to a 7.2 functional split and published a fronthaul specification accordingly. You can’t overstate how important this is. Open fronthaul is the very foundation of open RAN, because it is the key to decoupling radio vendors from baseband vendors. So the choice of architecture is a fateful one, and everything else builds on it.

The 7.2 functional split is a trade-off between radio complexity and fronthaul bandwidth. A simple radio would leave all processing in the baseband. This was the case with 4G and what became known as “Remote Radio Heads”. The fronthaul protocol at that time was CPRI, and it carried actual digitized RF samples to and from the RRH. The RRH only had to convert between digital and analog and modulate/demodulate the RF carrier.

The bandwidth required by CPRI was high, but initially it didn’t matter, because the baseband sat by the tower and running a dedicated optical fiber up the tower was no big deal. Now it matters. The baseband is being ‘cloudified’, and we want first of all an ethernet-compatible fronthaul to simplify transport and routing, and secondly a reduction in bandwidth to make it practical in the real world.

The 7.2 split meets these objectives by placing some of the baseband processing in the radio. But not all of it. The intent was to keep the radios as dumb as possible, to keep costs down.

The result is a bit awkward for massive MIMO. Channel estimation resides in the DU (first baseband stop), but beam-forming (multiplying all sub-carriers in all data layers by complex coefficients) resides in the RU (radio in 5G lingo). The fronthaul carries a number of data layers related to the number of simultaneous users — not to all possible antennas in the massive MIMO RU.

So one obvious solution is for the RU to have a set of predefined beams that covers its service sector. Eight beams fits in with the 5G specification for beam-based initial access and/or handover, where the UE reports to the base station a beam ID for best signal.

But these beams are necessarily quite broad. Narrower beams are needed for interference rejection. An additional set of beams can also be predefined. Once a connection is established through initial access or handover, it’s possible to select a narrower beam to improve the connection.

This approach works, but the connection quality is obviously uneven as the UE moves around, switching from beam to beam as the connection deteriorates. If we’re going to use narrow beams to accomplish spatial multiplexing (rather than using eigenmodes), we really want each beam to track the UE as it moves.

The ORAN fronthaul spec provides for the DU to download updated beam weights with each timeslot. What this means is that the DU can recalculate the complex numbers that the RU should use in its beam–forming functions, and do it often enough to track mobile users.

Let’s now suppose the DU has some sophisticated algorithm to do just that, possibly an angle-of-arrival computation utilizing all available uplink streams in the fronthaul. To track users at vehicle speeds in the mid-bands, the beam weights for each subcarrier must be updated every timeslot, or half a millisecond apart. For a 64T64R massive MIMO array operating with a 100MHz channel bandwidth, this amounts to 15Gbs of fronthaul capacity. In contrast, the user plane requires only 12Gbs.

This is clearly not tenable. If the beam weights are to be updated often enough to track users at vehicle speeds, they will have to be calculated right in the RU.

This is exactly what Ericsson has done. The Ericsson Uplink Booster moves several processing functions out of the baseband and into the RU, namely channel estimation, beam processing, and IRC. IRC means Interference Reduction Combining, which means combining all available channels so as to null out as much interference as possible. It sounds suspiciously like eigenmode processing to me. See Massive MIMO – Some thoughts on where it stands (technical, longish).

This may not be so easy to do with the ORAN 7.2 architecture. Channel estimation, for example, usually requires knowledge of the users, which the ORAN architecture reserves for the DU.

However, I think Xilinx and Samsung are making an attempt. They are partnering to bring Xilinx’s Versal hardware vector processing to the RU, presumably along with Samsung’s expertise in beam-forming (they have declared many beam-forming patents essential to 5G). (Announcement here.)

Details are scarce, but this is worth watching. Might turn out to be the way open RAN-compliant massive MIMO eventually challenges Ericsson’s leadership. Or at least makes itself useful.