Enea team have been involved in integrating into a variety of virtualization environments and processes from different vendors and we’d like to take the opportunity to share with you a few of our recent learnings from our Stratum Network Data Layer and other traffic management products, integration with Microsoft AON (Azure Operator Nexus), Broadcom VMWare Tanzu, Red Hat OpenShift environments for example.

 An overall observation is that being “Telco grade” is harder than you may think and requires more processes and infrastructure maturity from vendor, integrator, and customer perspectives. The telecom environment is not greenfield and the systems that need to change (or at least be accessible) are often quite a mix of technology. Added to that, telco upgrade and transition failures are very quickly public knowledge (e.g. Optus, November 2023). Resilience, failover, stateful data storage, performance, software roadmap to infrastructure roadmap alignment, security, management & operations are all bound up in the statement ‘Telco Grade’.

 As Enea we are involved in multiple multi-vendor projects on different infrastructure and here are eight key points from our viewpoint:

 #1 The Telco Infrastructure must be clearly defined. In production system telecom systems don’t like to be a ‘bleeding’ edge and need to have versions of software infrastructure that are both functionally mature, highly performant and verified from a security perspective. The telco should take into account that they are defining a software platform for their vendors. The new software stack platform, takes knowledge, time and effort to define and maintain.

 #2 Day 1 … Day N – don’t forget about the rolling upgrade problem, for both infrastructure and vendors. In a multi-vendor solution, there could be 10-15 vendors as well as infrastructure provider to coordinate; this presents 2 problems (1) In respect of infrastructure, Kubernetes, for example, has new versions every 6 months – so the choice is which to integrate and publish to vendors; and equally vendors have to be more open to their compliance. The second problem (2) is that service has to be maintained during an upgrade – and vendors need to ensure their CNF continues to work during its own upgrade.

 #3 (Automated) Test, Test, Test & Automated Deploy. There is an old adage fail to plan, plan to fail. Applying that here we would emphasize that automated testing & verification is critical to achieving speed in deployment. Cloudification could mean more site diversification, moving from fixed data centers to a hybrid mix of fixed and cloud based. Automated pipelines to manage the full lifecycle of CNF installation, upgrade, verification and rollback of are essential for delivery in cloud native environments. Automating the upgrade and deployment across more sites is the basis is critical to achieving speed and predictability in deployment.

 #4 Not all ‘common’ components are created equal. There are, for example different flavors of management interfaces to integrate with, or on the infrastructure side, K8S may come with preferred options (e.g. including SRIOV and MULTUS options). This matters for fault & performance management, analytics, and performance tuning.

 #5 Don’t forget about observability. No, we didn’t either, but in multi-vendor environments, common, standard mechanisms to report faults, escalate and diagnose are a core part of making the software Telco grade. In effect this can lead to reformatting/remapping of alarms, logs etc. So abstracting reporting (&mapping) will give you greater flexibility. This, in part, is also addressed by the NGMN Cloud Native Manifesto^[2] – publishing guidelines for vendors working in a cloud native telecom environment.

 #6 ‘Tool Sprawl’- There is a balance for the tools that vendors use, and the tools prescribed in a specific infrastructure. Individual tools can’t be used for each vendor or for small tasks as the number of tools will increase significantly. However, the toolset from a large scale infrastructure vendor can lead to position of (software) lock-in where, over time each vendors’ software has to increasingly adopt customized variations. A bad workman will blame their tools, so the lesson here is plan and roadmap the tools to use, their standard interfaces and what is best in class.

 #7 Performance Tuning & Operations; ensuring that the software stated performance is not based on ideal conditions in vendor lab but on real world traffic and environment considerations in the Telecom Environment. Including Network Operations in integration will speed up the process in the long term, providing valuable insight to vendors and integrators about what it takes to be Telco Grade.

 #8 Physical Storage / Stateful Data – There is a lot data (provisioned and generated) in telecom networks. How this is managed in a cloud native environment is business critical. In the case of Enea’s Stratum, Network Data Layer (NDL), it is keeping stateful information about users and their sessions. How that data is stored, replicated, and distributed and how a new instance of a local cache is ‘spun up’ has to be planned in meticulous detail. This is the data that makes the network work and records how it interacted with consumers – so for all stateful data – it’s worth significant review. Fail to Plan, Plan to Fail.

We would also cross reference NGMN group’s Cloud Native Manifesto^[2] in which they laid out key areas to drive the conversation forward in a telecom for cloud native transition. In brief summary, it called for increased abstraction from infrastructure, increasing openness and adoption of APIs as well as addressing the need for commonality in pipeline and operations. In a reference to A.I. it also highlighted the need the move from basic monitoring to observability with A.I., and automation in mind, calling for additional design thinking and opensource development of monitoring toolkits for microservices.

There is a greater understanding in telecom organization of what transformation means both from an organizational, integration, cost, and vendor perspective. There is also a greater understanding developing, in hyperscalers and virtualization suppliers, at what being telco grade means, and the business opportunity behind this. Enea has projects ongoing demonstrating our flexibility, certification, and collaboration. The Enea vision is for an open environment where best in class function software, interworking with standard cloud native framework deliver a coherent pipeline and operational solution for diverse telecom use cases.

If you want to know more about our Telecom Grade Cloud Native Software and Experiences please check out our solutions pages & their business value

References

[1] https://www.bbc.co.uk/news/world-australia-67340901

[2] NGMN – Cloud Native Manifesto