Mark Atkinson is SVP, Head of Radio Access Networks at Nokia, a post he has held since January 2021. The role means he has overall Product Line Management responsibility for the company’s radio access networks business. Before taking this position, he ran Nokia’s 5G business unit for about two years.
Atkinson’s roles heading up 5G development and then the RAN business overall have coincided with a period during which Nokia moved to overcome criticism related to its operating margins in 5G and what was seen as a relatively weaker product position compared to its main competitors, Ericsson and Huawei.
As the CEO and a host of other C-level executives left the company, one aspect didn’t change. The company knew it had to move to a 5G RAN platform that would enable it to compete with its main rivals, and would give its customers greater confidence in its technology roadmap. In recent strategy and results updates, the leadership has stated that the 5G networks business is its top priority.
One metric the company has adopted is to report the percentage of products it has shipped that are based on its own custom ASIC System on a Chip (SoCs), which it calls Reef Shark. It said that 43% of products shipped in 2020 were based on Reef Shark platforms, and it expects to hit 70% by the end of 2021. So why is Reef Shark seen as critical to Nokia’s fortunes, and what are the company’s plans for product development based upon it?
Nokia wasn’t ready with its SoCs to any extent on RF or baseband.
To explain Reef Shark’s importance, Atkinson recalls how things looked two years ago.
“What I inherited back at the beginning of 2019 was a pretty immature situation as far as 5G was concerned. Nokia wasn’t ready with its SoCs to any extent on RF [radio units] or baseband. We were caught out a little bit by the speed with which 5G evolved from 2018 to 2019, and ended up on an FPGA track for both RF and baseband.
“On the surface of things that’s not so bad; FPGAs being programmable do give you flexibility – but you need to get away from them as quickly as possible. Being programmable isn’t always as flexible as it sounds. You can think of an FPGA as a hard drive which you fill up pretty quickly, and then every time you want to add more features and capabilities, you need to optimise what’s already on your hard drive to make room for more. And that’s basically how an FPGA works as well.”
The company made the decision to move to a System on Chip approach, with custom ASICs designed to support the baseband and radio units.
Atkinson says that most products shipping so far with Reef Shark inside have been its radio units. “On the RF side, we already had a good plan in place with the Reef Shark RF platform which we developed together with Intel, where we were moving to SoC-based massive MIMO already in the second half of 2019, and then getting it to more mass market through 2020. That means that it is the RF products that make up a lot of these percentages when we’re talking about how many of our products are now shipping.”
Nokia’s baseband SoC development, Atkinson says, has been ongoing now for about two years. “We started early in 2019 and we are just now productising, it takes a pretty long time. On one hand you need to develop the SoC itself, then you need to get it up and running, and then you need to get all of the software features that were already working on the FPGA working on the SoC – and then carry it forward.”
Atkinson says that the way Nokia has designed its baseband gives it a lot of deployment flexibility. Nokia’s capacity plugin units, each with two Reef Shark baseband SoCs, can be plugged into the Airscale chassis, with (as Atkinson says) the potential to have six plugins in one rack to boost capacity and enable usage across multiple technologies.
“We actually have a pretty cool baseband architecture that enables us on the board level to move from technologies pretty quickly. So when we look at Airscale, we have a chassis, where you can have two controller cards and six capacity cards inside, and you’re able to mix and match them. When you’re going through the generations of new technology you can introduce them into chassis which are already installed and co-existing, already installed. There is no need to replace the existing box with a new one, as with some other vendors.” *
Atkinson says these basebands are now in their first customer pilots in Japan, adding in one shot the capability for 5G NR or S-RAN (Nokia’s 2-4G single radio solution). “And then we will go to full concurrent mode meaning S-RAN and NR on the same board, and then we go to capacity enhancements and so on. It’s an evolution via software. And the joy of the SoC is you develop in a more progressive way, it’s not like FPGA where you stop-start the whole time, it’s more a continuous development track, which makes our R&D a lot smoother.”
Atkinson says that SoCs are more power efficient which drives down size and weight, something that is especially important for 64TRx form factors. “They are more cost -optimised which is important because it’s not an industry where there’s lots of margin for everybody.” And then there’s smoothness of development. “On the RF side we are using the same Reef Shark SoC for everything from a 4T/4R micro radio to the 64TRx massive-mimo product: and it’s just that the number of SoCs you use that is scaleable.”
“And the cool thing there is you then have the ability to add features pretty easily. Let’s say bandwidth support. So you can start with 100MHz and if someone want 50 or 70 you can work on the SoC and immediately bring that into the whole radio portfolio. But in FPGAs you have to do that work multiple times. We have gone through a challenging wave on FGPAs, and managed to win a lot of customers so it’s not like we are shutting down FPGAs. We need to keep doing software work on those for many years into the future.”
The baseband unit silicon provider is Marvell, although there’s a role for Intel there too. Combinations of SoCs, and the role each plays, is also likely to be important in the future.
“For Marvell the main area is L1 right now, which is the closest you get to the hardware and where we had the FPGA in the past. L1 processing is of course fundamental. If you take things like eCPRI, beam forming that’s very L1 heavy. But even when you are talking about things like carrier aggregation at L3 there is still work to do on the L1 side. By having the SoC there, you make the L1 a non-bottleneck area, so it’s relatively easy work compared to what it might be on an FPGA.”
“There are different SoCS for L1, L2/L3 and transport, and Intel plays a role in there as well. And over time the roles will change. The secret sauce is how to get the most out of SoC partners when combining them together on a system level.
“When you’re doing your job well which we now believe we are, you are looking at what products you need three to four years into the future, which backtracks into what SoCs you need two years into the future so that you can productise baseband and radio software. That’s where engagements with SoC partners look beyond what current products you have.”
Nokia is also working with Broadcom on some future RF SoCs, Atkinson added.
If I look at my customer base today there are few customers who are going from day one down the track of vRAN
vRAN and Open RAN
With so much dedication and work going into custom silicon in Nokia’s baseband and RF products, the obvious question to ask is what this means in an industry where there’s a direction of travel – at least publicly – towards deploying networks as software on commercial hardware, and in making those software functions interoperable and open?
One question has been if those COTS-based platforms can achieve the same performance as the dedicated silicon platforms.
Certainly, for Atkinson, this is still something for the future.
“If I look at my customer base today there are few customers who are going from day one down the track of vRAN. Most of them like silicon just like we like silicon, they are going down the purpose-built baseband path. A couple of cases are starting with classical Airscale and have a path to vRAN but it’s not something they are rushing towards. There’s questions like what you do on the cloud side – do you have accelerators in there – which take you a bit away from the idea that any one software can work on any cloud server. So there’s paths that we need to work through and I think for the next couple of years we will still see the majority of deployments on purpose built hardware.”
One goal of virtualising RAN workloads is to enable the newer radio players in the market, giving operators a more diverse vendor landscape to work with. That might have benefits in terms of business security, access to more innovation and, in some cases, lower cost hardware. But for the newer vendors to really play, it will help to be able to deploy them in an Open environment. Especially as the vast majority of them don’t have their own silicon.
Atkinson repeats Nokia’s years-long messaging on Open RAN – it is for it, broadly, and more so than its direct competitors. But it needs to be done in the right way.
“For vRAN 2.0 – taking the CU and DU and parking it on x86 and connecting via eCPRI fronthaul to RF – I wouldn’t say it’s O-RAN ready. It’s in the right direction for O-RAN, because there’s a lot of flavours and messaging around O-RAN. When we have, let’s say the classic vRAN – Nokia software on the CU-DU connecting to a Nokia RF – that’s real stuff that we have customers contracted for and will be piloting this year.”
“It’s a track that different vendors are speaking different languages on.” *
Our approach to this is we will take our very well performing LTE and/or 5G system and we will, on our terms, open the interfaces.
“So that bring us to O-RAN, and O-RAN is an opening of interfaces. It’s not a new baseband that’s being drawn up from scratch. It’s taking something that already works, and then opening the interfaces that typically haven’t been opened in the past for good reasons. One of the good reasons is maybe a commercial one. The other one is it is not easy to make a baseband and a radio work together. There are a lot of issues around timing and synchronisation. There are a lot of features which touch both ends of the pipe and even layers within the pipe.
“Our approach to this is we will take our very well performing LTE and/or 5G system and we will, on our terms, open the interfaces. And by on our terms I mean it doesn’t make sense to say yes to everything and then figure out later it doesn’t work. It needs to be in agreement with operators profiles. There are several multipliers of O-RAN profiles which could combine into hundreds or thousands, so it’s not like plugging two ends of a pipe together, there needs to be a lot of agreement on profiles. Even today there’s some light fragmentation on O-RAN in Japan, Europe and the US, which is kind of counter intuitive to the idea of ORAN- where you can take whatever you like from wherever and plug it together.
“So we see this as a journey, it’s not something that will be done and dusted in 2021 or 2022. It’s a clear industry direction and as we have said publicly many times it is something we want to be part of it as well, to have the right solutions at the right time. For us the main step is the open fronthaul, to plug and play third party radios with our baseband, and possibly vice versa, and opening some of the operability interfaces like the RIC. Where it comes to the F1 [interface] between the CU and DU, there’s a lot more complexity in separating L1 low from L2 high and C-Plane; it becomes a lot more tricky where you have to disaggregate between the software layers. Carrier aggregation, for example, touches L1, L2, L3, O&M and RF.
“If you look at Rakuten’s LTE deployment it’s a relatively straightforward implementation of LTE, a simple carrier, few bells and whistles: so you can get software stacks and make them work. But when you go to 5G and add NSA or SA support, carrier aggregation, MU-MIMO, m-MIMO, beamforming – there’s layers of complexity to deal with and that’s something that we know how to do because we have done it many times over.”
* UPDATE 09/03/20: The original version of this article contained, at this points, some remarks about Nokia’s competitors that Nokia has subsequently asked us to remove. We agreed to do so on the basis that excluding the comments doesn’t alter the overall focus of the piece.
