Juniper’s decision to harmonize its implementation of the Open RAN RIC (Radio/RAN Intelligent Controller) with Intel’s FlexRAN program raises again a question I’ve asked in prior blogs, which is whether a network vendor who isn’t a mobile-network incumbent can play in 5G, and by extension whether they could play at the edge. I believe that network success (for any sort of vendor) is impossible without a 5G strategy, because 5G is what has funding to change the network in 2022 and 2023. Does the Juniper move with Intel move the ball for its 5G strategy?
5G is a kind of transitional technology in that it transitions networks from being strictly appliance-based to being a combination of devices and hosted features. The impact of this transformation is likely to be felt primarily in the metro portion of the network, deep enough to justify hosting resources but close enough to 5G RAN access to be impacted by O-RAN and 5G Core implementations. Because metro hosting is also where edge computing likely ends up, the ability of 5G to pull through an edge hosting model that could be generalized may be critical to exploiting the edge.
5G tends to call out NFV hosting, but many 5G RAN and open-Core implementations aren’t NFV-specific. That means that there could be a common model adopted for the orchestration and lifecycle management of 5G and edge applications, if such a model could be defined. However, the issue of orchestration and lifecycle management isn’t the only issue, or even the largest issue, IMHO. That honor goes to the relationship between networking and hosting in the metro zone, and it’s that area that Juniper as a network vendor has the biggest stake.
Operators’ fall technology planning cycle gets underway mid-September, and 5G is the most secure budget item on the 2022 list, and the most significant technology topic of this fall’s cycle. Network vendors without a seat at the 5G table face a significant risk of disintermediation. Ciena, for example, announced last week that it was acquiring the Vyatta switch/router software assets that AT&T had picked up long ago, noting that “The acquisition reflects continued investment in our Routing and Switching roadmap to address the growing market opportunity with Metro and Edge use cases, including 5G networks and cloud environments.”
One big problem for network vendors in becoming 5G powerhouses is that they have little opportunity for differentiation, since they don’t have either specific mobile network experience or a particularly large product footprint in the space. Juniper’s decision to roll its own near-real-time RIC into the Intel 5G ecosystem is a way for the company to become a part of a credible, broad, publicized, 5G model. Intel saw 5G as an opportunity to break out of the processor-for-PCs-and-servers market and into the device space. That was important because devices, including white-box switches/routers, could end up as big winners in open-model 5G and O-RAN, and that would risk having non-Intel processors gaining traction in metro hosting. That’s not only a threat to Intel expansion, but also to its core server business.
It’s also a threat to the network equipment business, particularly that related to metro. If you have both servers and networking in the same place, and if 5G standards favor hosting of many 5G elements, you could certainly speculate that servers with the proper software could absorb the mission of network devices. Vyatta is proper software for sure. I know a lot of operators who spent money on Vyatta, going as far back as 2012. Ciena’s move thus makes sense even if you assume servers could take over for routers and switches. Since Vyatta software would also run, or could be made to run, on white boxes, it could have a big play in a 5G-driven metro play, if we consider that 5G is where most of the budget for near-term network change in the metro is coming from.
The problem that vendors like Juniper, Ciena, and Cisco face in 5G goes back to the question I asked above, which is whether 5G in the metro creates a bastion of hosting at the edge, or a bastion of networking in content data centers. Or both. If metro infrastructure is hosting-centric and if 5G white-box thinking dominate there, then open-model devices could own the metro and the current network vendors could see little gain from the metro/edge build-out. It’s that risk that network vendors have to worry about, and despite Ciena’s positioning of their Vyatta deal, they still have to establish a 5G positioning, not just a switch/router software positioning.
The keys to the metro kingdom, so to speak, lie in the RIC, or more properly, in the two RICs. The RIC concept is a product of the O-RAN Alliance, designed primarily to prevent a monolithic lock-in from developing in the 5G RAN, particularly in the “E2 nodes”, the Distributed Unit, Central Unit, and Radio Unit (DU/CU/RU) elements. The near-real-time RIC (nearRT RIC) is responsible for the management of microservice apps (xApps) that are hosted within this “edge” part of the 5G RAN, opening that portion up to broader competition by making sure its pieces are more interchangeable. You could say that the nearRT RIC is a bridge between traditional cloud hosting and management and the more device-centric implementations likely to be found outward toward the 5G towers.
You could also say that the non-real-time RIC (nonRT RIC) is a bridge between the 5G RAN infrastructure and the broader network and service management framework. It’s a part of the Service Management and Orchestration layer of O-RAN, and its A1 interface is the channel through which both operators’ OSS/BSS and NMS frameworks act on RAN elements, with the aid of the nearRT RIC.
Inside a metro area, both RICs and the implementation of 5G Core would create/manage the hosting of “features and functions” that are components of 5G service. It would be optimal, given the fact that most IP traffic growth comes form metro-hosted content, for the content hosting, 5G feature/function hosting, and edge computing missions of metro infrastructure to harmonize on a single structure for both hosting and connection.
This is what’s behind a lot of maneuvering by vendors like Juniper, Ciena, and even Cisco. If metro is going to evolve through the parallel forces of hosting and connecting, having nothing to say in the hosting area is a decided disadvantage. Similarly, being stuck too low on the stack, down at the fiber transport level as Ciena is, relegates you to a plumbing mission and surely takes you out of meaningful metro planning dialogs.
You actually need to think about going up in the metro-success game. Hosting of almost anything that’s distributed demands some sort of multi-tenant network model for the data center/cloud, and that’s what actually spawned the whole SDN thing with Nicira ages ago. The ONF’s 5G approach is based on SDN control, demonstrating that you could take a network-centric view of the future of metro infrastructure for 5G hosting, and likely then on to edge computing.
Let’s make an important point here: Juniper, of all the non-mobile network infrastructure players, has the strongest product portfolio to address the New Metro moves. They have their Cloud Metro fabric concept for connectivity at the physical level, they have Apstra for data center automation and virtualization, they have both Contrail and 128 Technology for virtual networking with security and prioritization, and they have Mist/Marvis and AI automation overall for operations efficiency. They also have a RIC from a deal with the Nestia subsidiary of Turk Telecom in January, and it’s this effort that they’re now harmonizing with Intel’s FlexRAN model.
The fusion is a good strategy for Juniper, because Intel has a higher 5G profile and a better platform on which to promote its RIC model to the market. Juniper has been fairly quiet about the details of its RIC so far; it’s even hard to find any information on Juniper’s website. Given the RIC’s strategic position in 5G and the edge, they need a dose of publicity and credibility if they’re to reap the full benefits of their RIC deal, and exploit that to improve their 5G, Edge, and metro position.
Any non-mobile-incumbent network vendor, which Juniper is, has a challenge in the 5G space. They not only face competition from the mobile incumbents, who are so far winning the majority of the deals, but also competition from software hosting-or-white-box players, including giants like Dell, HPE, Red Hat, and VMware. The former group have pride of place, and the latter group have the inside track on the open-model 5G space because they’re hardware-independent. For the non-mobile-incumbents, like Juniper, there has to be a powerful reason for a buyer to give them a seat at the table, and it’s not enough to say “we have O-RAN and RIC too.” So does everyone else.
The Intel move could help Juniper validate it’s RIC approach, but it doesn’t explain it. That’s something Juniper has to do, and they also need to create a better Cloud Metro positioning that reflects the reality of the metro space. It’s where the money is, and will be. It’s where differentiation matters, and is also possible, and it’s where every vendor in the server, software, and network space is hoping for a win. Juniper has magnified its metro assets, but not yet fully developed or exploited them, and they need to do that.