Who will integrate open, disaggregated networks?

A systems integrator, the operator, a blend of the two? At FYUZ, service providers and vendors wrestled with the key internal conflict of disaggregation. How tightly do you stitch things back together again, and who does it?

Lots of things have changed in Open RAN since TIP last got its community together in a physical event. There are more networks, more vendors, more silicon providers. But the core contradiction at the heart of the disaggregation that underpins Open RAN hasn’t changed.

Operators want an open platform onto which they can deploy solutions from a range of vendors, exploiting the modularity to access innovation in software and components, avoiding lockins etc. Hence the disaggregation. But as things get pulled apart, somebody then has to put them back together again.

Who should do that? Should it be the operator, a specialist systems integrator, or a “blueprint” provider? There are examples of each of these approaches out there, and they all have their pros and cons. If an operator pulls it together, they have control – but they take on the risk and the need to assess and then manage a whole cast of characters. If a systems integrator does it, then the operator externalises the complexity, but with it also the knowledge and the know-how. And it might risk creating a bottleneck for new applications and innovation, as the system integrator takes on a quasi gatekeeping role.

One solution, identified by Vodafone on the first day of TIP’s gastronomically-inspired Fyuz event, is for operators to do it, but in a much more co-ordinated manner, to avoid duplication and also to give vendors something solid and tangible to work to. To that end Vodafone announced that it and NTT DoCoMo would be connecting their labs, and working on common integration specifications. This would align the two operators on the SMO and RIC elements within the Open RAN architecture. These are the bits that manage and control the RAN, and which can act as host for network facing applications from third party vendors.

They will produce a whitepaper stating how they will want these elements to work.

It might also help smaller operators access Open RAN technology with some degree of confidence that they too could manage such a system. NTT DoCoMo has had a multi-vendor network for a long time, carrying out its own integration and interoperability verification. It has already stated that it wants to export that as a capability for other operators, mirroring in some ways the manner in which Rakuten Mobile spun off Rakuten Symphony.


Let’s say you want to sell Radio Units, or CU-DU software or hardware, to mobile network operators and you are not one of the incumbent vendors. What is your best chance of making a sale?

Is it to approach an operator that you hear is in the market for new radio solutions, and convince them that not only is your new unit good enough for their network, it is “better” than everyone else’s – ie offers a set value of features and performance at a better power budget, price, installation and operational budget. Oh and your roadmap is secure and you are going to be around providing support for 5-10 years. And it will work with the equipment and software that this operator is putting together around it, from the baseband to the management interfaces and so on.

Or is it better to form up as part of a system, or solution, that integrates your RU with a DU-CU from a radio software developer, or your CU-DU with a hardware provider, and someone who does the cloud infrastructure management that hosts the functions, an OSS provider, someone who can instrument and monitor all that, automate test and verification of the system and then maintain ongoing software updates? A system integrator then offers this as a solution to operators, and you hope that it solves enough deployment headaches for operators that you will get more sales this way than if you had pitched solo for the RU business.

Or maybe there’s a third way – one that neither creates integrated solutions, but rather forms blueprints that meet specified operator requirements, and then tests, validates and certifies products that will fit into that blueprint. That way, our hypothetical RU vendor gets the following. They get set SKUs to manufacture that a number of operators have already said they want – they’re not customising each time per the requirements of each operator. Once they are tested and certified by the trusted party that specifies the blueprints, they don’t need to convince each operator one by one that they work, interoperate and can play as part of a system. An operator looking for solutions to meet a use case – say a low band rural deployment, or a MassiveMIMO densification, or a network extension into a new airport terminal – accesses the blueprint catalogue, sees which vendors are validated, and puts its choices together. It is still in control of its vendor choices, its deployment and its update path. But much of the certification of performance and the pre-integration has been taken care of.


By the way, you can reverse the view from the other end of the telescope and role-play as an operator. What is the best way for you to give yourself access to an open radio network that will enable you to access new software updates, new automation technology, new management capabilities when you want it, and who you want it from?

Is it to issue RFIs then an RFP and RFQ, conduct extensive tests of your shortlist, take a couple of candidates into lab tests, then field trials, then limited live pilots, then stitch it into your rollout and commissioning processes, your management interfaces and OSS. Then finally, commit to a wider production rollout.

Or is it, again, to go for one of options two or three?


Well, none of this is really hypothetical. This issue is precisely what the industry was grappling with at TIP’s FYUZ event, and it is something TIP itself is addressing head on.

If you wanted to understand where we are, then Option 1 is the Status Quo and it is, by common agreement, stifling the market for those in the Open RAN ecosystem, outside of Dish, and arguably Vodafone, although Vodafone has not broken any barriers with its Open RAN vendor choices to date (mostly Samsung for vRAN, and now Nokia too).

Option 2 is the System Integrator approach, where someone like Tech Mahindra, Cap Gemini or Accenture, or actually NEC in one instance, will put the pieces together for an operator. It is still an open network, in that it is multi vendor – but the operators is being delivered an integrated solution.

I believe we are taking it one step further in terms of  a commercial alternative that retains optionality longer term

And then Option 3 is what TIP is trying to do, and what it was explaining this week. TIP feels that this approach breaks down a lot of barriers for entry both for new vendors but also for operators that are trying to get to the benefits of open networks. Its new CEO, Kristian Toivo, said, “This is my personal obsession, a significant portion of my time is spent around that challenge, and it was brought up by several speakers – especially on Tuesday by Telefonica and Orange and other operators.

“You do need to have a process that does in some sort of way consolidate that integration, to avoid every operator having to do it themselves. The discussion right now is what is the best way of doing it? I believe the right way is to take the TIP process as it is today and enhance it, make it more robust and disciplined to extend and deepen the integration and verification that is done under TIP control, in approved labs and environments, so that it becomes commercial-grade and shortens the part of the process that an operator has to do for commercial deployment.”

“They will always have to do some remaining integration and verification against legacy environments and handovers, northbound OSS and BSS, but if every operator has to do all the integration from scratch there is a risk that it outweighs the benefits of disaggregation. Hence we need to have a way where we have benefits of scale. And there are different ways to do that. One approach, for example, is Rakuten Symphony, an example of a vendor, if you look at it that way, that is open in the sense that they use different components, but tacitly they take a big portion to do this piece of work.

“The way that we are thinking in TIP is to do that but still using the TIP community with the stringent process that TIP has got. If you are an operator you retain the optionality of suppliers within the TIP community.”

How TIP sees its process moving from operator-drive use cases, via approved and trusted test and validation processes, to a marketplace of deployable products and solutions.

“What we want to do is take it one step further, put discipline into it, say what are those prioritised configurations, and collect and order the requirements, with an openness and sharing of priorities. So the operators do agree on priorities and functionality and now we do the next step. You still need the test plans and the operators need to be involved in doing that. I believe we are taking it one step further in terms of  a commercial alternative that retains optionality longer term.”

Toivo agrees that this approach does put more expectation on the operators, there is not a company you can request for fixes if anything goes wrong. But he thinks that in itself is a positive, at a strategic level.

“I think it brings an important topic, which is that the role of the operator has to evolve and they need to take control. It is similar to the IT transformation on cloud. You need to take control as a client to control your vendors, to select your applications, and you need to upskill your team, with the impact on your operational model. I personally think it is the best thing that can happen to this industry. It enables us to take control and to have the capabilities and skills in the business when you want to innovate. But it’s a journey in itself, and operators are not only doing that for Open RAN, it is to transform themselves on the adoption of the cloud.”

I really never had a problem with the concept of TIP. The problem is the execution from idea into reality: how many people would actually go and take in practicality what TIP wants to do and put it into marketplace


Toivo mentions Rakuten Symphony as the system integrator example. And perhaps Symphony is more of an option 2.5, sitting somewhere between the full System Integration option and the “verified marketplace” option. To some Symphony is a fully system integrated offering, but Symphony has and would insist that it offers an open platform, offering operators the ability to choose the cloud or RAN or RU vendor of their choice, if need be.

And its CEO Tareq Amin insists that Symphony offers its partners more opportunity for volume sales than the TIP approach. In comments to journalists at FYUZ he described the company as “already a unicorn” by valuation – a valuation he says he will share the justification for soon. Symphony is, he said, on the cusp of announcing operator deals, including brownfield deals, that would prove it. That would give our hypothetical RU vendor a path to deals, more than via the TIP approach, he said. In fact he said that “next year” will really be the year that we start to see a major adoption of the new architecture amongst major operators.

But he still isn’t sure about TIP.

“So I think the TIP idea is really good,” he says.  “I really never had a problem with the concept of TIP. The problem is the execution from idea into reality: how many people would actually go and take in practicality what TIP wants to do and put it into marketplace?

“So it’s not like we as Rakuten did not like or enjoy the premise of what TIP is, but four and a half years ago I couldn’t see how to work with TIP to actually build something that is real. So the approach that we have taken is in order for you to succeed … vendors need to make money, operators need to make money, you have to create a win-win relationship, right? You cannot just say, “Hey, open source,” but there’s no path to revenue. You’re got to to show people revenue, money.

“So when we brought the hardware providers in Rakuten in Japan, there was 13 of them – 13 hardware providers. And I met all their CEOs. I said, look, “I want you to sell me the hardware. I don’t want the software.” Of course that was like a shocker to them. You know, I said, “What does it matter to you, you are obligated to your board to generate revenue. So we build a model where this ecosystem, we became the blueprint creators.

“Now, in reality, a TIP-like concept shouldn’t be the blueprint creator. Because if it’s community driven, it’s a good idea to get the community to say, “Oh, this is a validated architecture. Company A hardware versus Company B software really works well.” The question is money. In the TIP construct how does money transaction work? I think that’s where TIP needs to think about carefully; the monetisation strategy.”

What Amin elides over, is that it is early days in TIP regarding Open RAN. It’s not that vendors can’t monetise, just that they haven’t done so yet. But that is surely down to timing and market maturity, rather than the mode. Elsewhere, TIP does seem to have proved its model can work, although it wouldn’t do to make too many claims for market disruption, its open cell site router – DCSG – project is slightly further down the path, having followed a similar course, and companies such as EdgeCore are achieving real sales having satisfied TIP requirements. Toivo also mentions the Open Optical programme success.

So Amin’s doubts that vendors can monetise via TIP may or may not be driven by competitive rivalry. But he certainly hits on the key question, even if not everyone would agree with his answer.


One final point, is that any blueprint must look beyond Day 1. Automation is another key. With CI/CD pipelines, operators can “automate away” many of their ongoing issues in identifying the root cause of faults, taking the right action, testing the required update and then deploying it. Alla Goldner, once of Amdocs and recently now of NEC where she is heading up standardisation, said during one Fyuz main stage session that moving to zero touch operation was a key part of achieving Open RAN market maturity, with closed loop automation becoming a necessity.

So you can see why Vodafone and NTT DoCoMo want to get the SMO and RIC piece right. And you can also see why Rakuten thinks one of its big achievements was not just smooshing together the Altiostar CU-DU with a range of RUs, but in automating its network rollout and ongoing cloud native operations – so much so that it bought a key provider of this piece – Robin.io, as well as its observability vendor Innoeye. That gave it the means to manage its own integration in an automated way. And any discussion about innovation also needs to take full account of this part of the ongoing operational infrastructure.