It is two years now since Europe’s largest five group operators got together and formed a MoU to co-operate on Open RAN.
That effort focussed mainly on aligning their buying and R&D power around a set of specific requirements for Open RAN technology. It has met with limited market impact to date, but it did send a clear signal to the market that these operators were serious about progressing Open RAN product requirements.
Well last week, the same five – Deutsche Telekom, Orange, Telecom Italia, Telefonica and Vodafone got together to collaborate on the creation of a cloud software framework. Again, the stated aim was to reduce the infrastructure fragmentation, within the European context. This time, though, two vendors were also involved – Nokia and Ericsson.
The project, known as Sylva, is homed within Linux Foundation Europe (LF Europe). Its members have two main aims. First, to “create a new, open source production-grade Telco Cloud Stack” – i.e. a cloud software framework. Secondly, to produce a Reference Implementation of that framework.
Sylva’s main objective is to release a cloud native infrastructure stack to host Telco (5G, OpenRAN, CDN, etc.) and Edge use cases. The main technical challenges that Sylva is targeting are Network performance, Distributed Cloud (multi cluster Kubernetes, Bare Metal Automation), Energy Efficiency, Security (hardening and compliance) and Openness (capitalise and contribute to Anuket, Nephio, O-RAN). A launch press release from the group said, “Sylva provides an environment to collaborate and develop solutions to tackle specific technology challenges and facilitate cloud native adaption for Telco and Edge use cases”.
The aim of the cloud software framework is to:
- Identify and prioritise telco and edge requirements
- Develop solutions to the specific technical challenges identified on the infrastructure layer of the telco ecosystem
- Integrate these solutions with existing open source components
- These solutions and the integrated cloud software framework are not “production ready” software, but aims to be “production grade” in order to be used by third parties such as operators, network function vendors, and cloud providers to create commercial products
The Reference Implementation of this cloud software framework and create an Integration and Validation program to:
- Validate the commercial network functions against this cloud software framework
- Validate implementations based on the released framework and its components
- Accelerate commercial adoption of network functions and their compliance with this cloud software framework
Why are they doing this?
Well, it seems to be a case of “too many clouds” creating a specific need to address how to deploy and manage functions across core and distributed and edge cloudlets in a common manner, whilst overcoming technical limitations of current cloud ingrastructure approaches.
A whitepaper from the telcos says that the telcos know they will need to deploy hundreds of Edge Cloud nodes in the coming years, accommodating traditional telco functionality such as 5G Radio Access Network (RAN), core network, BGP, SDN functions and modern cloud services such as video analysis or control platforms for robotics in the same location. Cloud Native Infrastructure offers a great opportunity to make this deployment simple and efficient.
The white paper says that the problem they face is that, if the Telco industry continues with its traditional deployment model then fragmentation is inevitable for the deployment of applications that mandate the use of proprietary CaaS (Container as a Service) and even specific physical compute. “Today, the fragmentation of this cloud layer leads to increased complexity, for both vendors and operators. Firstly, the vendors must develop their application layer, aka Network Functions (NF), to be able to certify against multiple cloud layers (vendors proprietary cloud, operators’ proprietary cloud, and so on).”
This paper says this approach is no longer sustainable as it:
• Prevents the possibility of sharing CaaS and physical resources among different applications, resulting in wasted compute power with CAPEX and energy impacts
• Creates unnecessary complexity for vendors as they look to certify multiple cloud platforms
• Creates operational burdens on Telcos as the different “islands” will need different skills and will evolve at different speeds
• Fails to provide a solution that can evolve with the necessary speed of cloud native
An edited version of this article was first published in our Friday newsletter, InsideTMN. You can sign up to receive future newsletters here.
So what are the telcos looking for, from Sylva, that can overcome these issues?
Well the whitepaper says it wants to close gaps in the infrastructure technology to be able to support telco apps, but to do so in a common way. It says, “Although Kubernetes’ customisability… makes the technology great in utilising any type of Compute Hardware, as a result of how the interfaces are designed the CaaS layers do not abstract the Compute Hardware completely from the Applications. There are some technology areas where Cloud Native infrastructure components need to evolve to support the needs of Telco applications. When closing the gaps in the infrastructure technology the most optimal approach for the whole industry is to develop open source de-facto standard interfaces instead of vendor specific solutions.”
Here is a list of some of these extended capabilities required by Sylva use cases
• Enhanced performance support (e.g.: EPA capabilities, DPDK, SRV-IO)
• Specific synchronisation cards support for O-RAN (PTP)
• Cloud Native support for L1 RAN acceleration network interface cards
• GPU hardware support
• Bare Metal automation provisioning
• Multi-Clustering support
• Service mesh support
• Enhanced security (e.g.: Internal ciphering and multi-tenancy)
• Lightweight (all in 1 server)
• Energy efficiency.
Having one consistent computing platform that can be deployed, sharing hardware and connectivity resources among different applications, can “reduce fragmentation of the cloud infrastructure layer for telecommunication and edge services”.
In a large part, Sylva is about providing that implementation platform for a distributed cloud that meets telco needs, evolving them away from relying on proprietary vendor clouds, operator clouds, public clouds etc.
Sylva said it is not intended to replace those other efforts but to leverage them and cover those requirements that are specific for the use cases that the European Telcos are working on.
Project Sylva is not starting from scratch, though. It is using Anuket, which is an open initiative that delivers a common model, standardised reference infrastructure specifications, and conformance and performance frameworks for virtualised and cloud native network functions. However, Sylva says it is not a duplication of Anuket. Rather, “Sylva is a production-grade cloud framework implementation compliant with the reference architecture (RA2) and the conformance test suites (RC2) from Anuket.”
And Sylva is also aware that there are already other initiatives covering cloud native technology stacks such as Kubernetes and the Anuket itself, as well as other initiatives that cover specifying, integrating and verifying Telco-specific stacks and the validation of Telco applications.
Sylva said it is not intended to replace those other efforts, but to leverage them and cover those requirements that are specific for the use cases that the European Telcos are working on.
If needed, the Sylva project will contribute to those initiatives some specific extensions that could otherwise become duplications.
You might also be thinking, why not just leverage the public cloud?
Well, the telcos feel that while hyperscalers can provide to both operators and vendors the capabilities they need, this solution will remain a vertical solution with no interoperability between hyperscalers themselves, and strong lock in.
Another difference with this project is the explicit involvement of the two NF vendors. The vendors themselves are challenged by cloud and cloud infrastructure fragmentation as it means they have to develop software for a whole gamut of different telco cloud environments. Of course the vendors also offer operators their own cloud environments, but when they are faced with deploying to a telco cloud, the question of who manages that, and takes charge of ongoing updates and deployment, is difficult for those vendors too. Indeed one vendor recently express to TMN just such a frustration – that they are expected to be able not just to create but also support CNF software across a wide variety of different telco clouds, and often to bear the development cost of doing so.
These issues are only magnified in a distributed use cases, where resource sharing and flexibility is more important than in a showcase centralised cloud environment that might host, say, a new 5G SA-capable core network.
There are a lot of pre-prepared quotes on the public press release, but this, from Laurent Leboucher, group CTO and SVP, Orange Innovation Networks is probably the most important one:
“The Telco Cloud ecosystem today is fragmented and slowing down our operational model transformation. Despite a transition to cloud native technologies, a real interoperability between workloads and platforms remains a challenge. Indeed, operators have to deal with a lot of vertical solutions that are different for each vendor, leading to operational complexity, lack of scalability, and high costs. Sylva, by providing a homogenous and open telco cloud reference implementation for the entire industry: interoperable, flexible and easy to operate, should help all the ecosystem (Europe and beyond),”
And LeBoucher, remember, is part of a team guiding an experimental cloud-native network (Pikeo) in northern France, with open source automation including ONAP software. Add to that the operator already having been through a commercial NFV development programme in Spain with RedHat OpenStack. It also deploys 5G SA cores from Nokia and Ericsson on their cloud infrastructure. Despite all that it still sees real interoperability between layers of the cloud stack is a challenge. Hence, for the time being, Sylva.
