Circle Opinion

Why Cloud-native telco networks must rethink their OSS/BSS

Authors
Alex Ankers
LinkedInEmail

With businesses looking to cut costs and increase efficiencies, it should be no surprise that the telecommunications industry is (slowly) moving towards the public Cloud to run some of its missioncritical backend systems, chiefly those provided by Operational Support Systems (OSS) and Business Support Systems (BSS) which underpin the business and revenue-generation model for a modern telco. With pioneers such as Totogi, the management plane of a modern telco network is bound to interact with some form of Cloud Service Provider (CSP) offering. So, what major pressure points are telco networks facing and how are they overcoming them? 

Pressure to maximise revenue through increased agility

Increased customer demand, competition and inefficient legacy monolithic OSS/BSS systems means that telco operators are struggling to maximise their Revenue Per User (RPU) in a world of constantly-growing network access technologies (3G, 4G, 5G, Edge, IoT) and increased consumer bandwidth, service appetite and choice between the newer MVNOs (Mobile Virtual Network Operators) in the market. Agility – both for Service Provision, Service Operation and Charging Model changes – is increasingly becoming the de facto differentiator between telcos in increasingly saturated marketspaces. 

Where telco’s geographic footprint once held supreme, the public Cloud provider is now increasingly encroaching on their traditional business. This is evidenced through innovative offerings such as Microsoft Azure Private 5G Core and AWS Private 5G starting to displace the decades-old practices of using costly, inflexible, vertically-integrated network vendor solutions for more Cloud-native alternatives. 

Additionally, the amount and complexity of nodes and technology types present are leading to the old “pets” approach human-fetered operation leaning more towards a “cattle” approach, with Operator Assistance tooling like ML, AIOps and Network Automation to ensure the same – or in many cases, reduced – headcount to run an ever-growing network boundary. 

Selling more data with data

Telcos often possess much of the data (analytics) that they need to empower them to sell more data (allowance) to their subscriber base, but are often not empowered with agile or Cloud-native tooling or frameworks to launch retention-focused offerings such as the Totogi churn prediction service or provide dynamic Fair Usage Policy management based on actual usage. For telcos moving towards the “as a service” offering spectrum – such as charging as a service, 5G RAN core as a service and others – Cloud-native approaches and tooling are required alongside more modern OSS/BSS Cloud-led approaches to fully exploit this. 

To do this, telecommunications providers must focus on the following: 

  • Modernising the network 
  • Monetising the network 
  • Reducing the TCO of the network 

Cloud-native is key to all three, particularly with regard to unlocking small customer wins which otherwise can’t afford CapEx-intensive, slow-delivery approaches as afforded by older monolithic cores within older OSS/BSS packages and the like. Ditto, monetisation of assets becomes easier when data can be processed on an ad-hoc, sub-hourly basis with compute billed accordingly, akin to Functions as a Service (FaaS) compute. 

NFV, VNF, CNF, vRAN, AI… oh my!

While discussions around artificial intelligence (AI) such as GPT-4 are new, related improvements to telco networks such as these are very much not, and have been in the industry zeitgeist for many years: 

  • Network Function Virtualisation (NFV) 
  • Virtualisation of Network Functions (VNF) 
  • Cloud-native Network Function (CNF) 
  • Virtual Radio Access Network (vRAN) 

“Carrier Grade” and “Cloud” previously haven’t been mentioned in the same sentence; not because the latter isn’t capable of the former, but because the “Carrier Grade” has always effectively meant large, monolithic applications and network operating systems deployed on large vertically-scalable, vertically-integrated platforms – such as the Network Chassis or VLR/HLR Controller. Internally, while similar in concept to the Twelve-Factor App, the proprietary nature of the internal northbound and southbound communications busses has led to a lack of innovation or integration possible with these devices. Added on this, the cost to vertically-scale (read: buy a new, much bigger unit) is cost prohibitive to new entrants in the space. 

With the IT industry advent of increased abstraction and minification of compute and programming into Containers, IaC and Orchestration (Kubernetes et al), so too has the telco industry effectively copied its IT peer – with abstraction and componentisation of telco network function into NFV, VNF and CNF, the rise of the vRAN and “RAN as a Service” has begun. Many of these are the underpinning of public Cloud providers telco 5G offerings and are only possible because the wider telco industry is reaching a level of maturity with Cloud and related coding discipline that it previously had eschewed. 

How CACI can support your move towards a connected industry 

We see similar across our enterprise and public sector clients with the rise of IoT Networks, industry 4.0 and the like. Previously monolithic approaches both in hardware and software are giving way to more agile, nimble Cloud-led approaches, tools, techniques and “as a service” offerings. Telcos can now leverage the benefits of public Clouds without having to rip and replace their current systems. This enables scalability, flexibility, cost-effectiveness and access to AI capabilities and machine learning prediction models that can produce powerful insights from world-class analytical products via open API-based services. 

CACI Network Services has a rich heritage in the telco sector; get in touch to see how we can help your telco, MVNO or OSS/BSS product fully exploit the agility and opportunity that Cloud can provide to increase the return on your RPU. 

Contact us now
Authors
Alex Ankers
LinkedInEmail