Cloud-native OSS/BSS should reduce opex and drive automation, but this requires technological and organizational change
Before getting into expert commentary on cloud-native OSS/BSS provided during the recent Telco Cloud & Edge Forum (available on demand here), it’s important to understand what operational support systems (OSS) and business support systems (BSS) do, and how that baseline functionality will materially change in the march to 5G Standalone and the enablement of advanced services combining connectivity with mobile edge computing.
OSS/BSS are essentially IT systems that combine hardware and software to streamline the day-to-day machinations of managing and administering a network. The OSS is a key piece of maintaining a network inventory, detecting network problems, configuring, delivering and assuring various services, and network planning. The BSS is an operator’s primary interface with customers and covers things like handling orders, managing subscriptions, billing for services, pushing marketing offers and, broadly, customer relationship management (CRM).
Historically, these two hugely important systems have been somewhat siloed which can lead to operational inefficiencies and best-effort CRM processes. In the context of 5G, operators are struggling to monetize massive network investments, which reinforces the importance of effective CRM coupled with the ability to, from a network perspective, deliver differentiated services when and where they’re needed.
The next wrinkle comes with the move from Non-standalone 5G to Standalone 5G, the latter of which implies a cloud-native, service-based architecture. The jump to Standalone 5G is regarded as a necessary step to combine connectivity and compute at the enterprise edge to deliver advanced 5G services, often latency-sensitive, that yield real business value for buyers and new revenues for operators. In this context, the network gets more complex and SLAs become even more critical—as such, a cloud-native OSS/BSS will become table stakes.
Three opportunities and three challenges to cloud-native OSS/BSS
With the ongoing maturation of 5G specifications and the eventual transition to Standalone 5G, operators will, at some point, move to a fully cloud-native architecture. Most early moves are around the core network, but we’re increasingly seeing adoption of virtualized and cloud-native network functions out in the radio access networks. As this progresses, operators will also need to transition OSS/BSS systems to cloud-native.
Why? Beyond the standards and 5G Standalone piece, “There’s a lot of good business value promised by cloud-native architectures,” according to Andrew Keen, senior director, product manager, Volt Active Data. Specifically, as operators look to fully leverage 5G to generate new service revenue on the back of advanced services combining connectivity and distributed compute—private 5G for latency-sensitive, always-on industrial applications for example—there has to be a new approach to managing operational support and billing against exacting service level agreements.
- Flexibility—”Cloud-native applications should be much quicker and easier to deploy and manage than traditional deployments. You should be able to easily define deployment characteristics, the number and size of any given service, and what it’s going to be used for…and be able to spin it up or tear it down in minutes.”
- Automation—”Once running, the system should be much easier to manage with many traditional manual tasks now automated in cloud-native.” This hinges on a microservices approach where service elements “are independently deployable, upgradable, scalable, etc…which translates to reduced operational overhead. To effectively do this, operators will need to borrow from enterprise IT and establish a CI/CD pipeline. “You remove the tired human error component and it’s all automated.”
- Optimization of compute resources—”Cloud-native applications should then also make better use of the underlying compute capabilities than the traditional monolith. Instead of scaling the entire monolith so that the single crunch point has enough capacity, you scale the individual microservice. For example, if an online charging function has an overloaded rating engine, scale it and only it instead of scaling the whole applications…Auto-scaling means this should happen automatically.”
And, of course, Keen said these opportunities present new challenges, including:
- Cost—Dynamically scaling stateful BSS applications “does come at a cost of managing the distribution of the data…While BSS applications applications, cloud-native applications, should scale, it’s not quite as trivial as scaling a stateless service, so just bear that in mind.”
- Telco cloud approach—there’s ongoing debate as to the right telco cloud approach; is it all private, all public or a hybrid combination? In this dynamic space, “CSPs need to be upfront about their expectations with their vendors and discuss their cloud-native strategies and requirements.”
- It takes time—”It still is an evolving space…Chances are [vendors] don’t necessarily have everything ready to right now.”
Back to how this ties to delivery and monetization of new services, Keen gave the example of a charging application “that performs thousands of tractions per second.” A congested network interface or overloaded CPU causing problems with the BSS and potentially leading to a deviation from a service-level agreement has “serious consequences. So whatever cloud infrastructure is used, the CSPs need predictable performance from these BSS applications. Many CSPs on the public cloud front are finding the commercial realities aren’t quite as favorable as they first thought.”
Double clicking on issues operators can face from (over)reliance on the public cloud, Keen called out the high costs associated with BSS data transmission to the public cloud. And, “The SLAs of most public clouds aren’t quite what the telcos have been used to.”
Bottomline, Keen said, “Ensuring an active high availability architecture across multiple availability zones or probably even across multiple regions is going to be important to achieve the kind of availability that telcos expect and are used to…Finally, not all applications in this space are going to be upgraded to cloud-native at once. The advent of 5G has definitely accelerated and focused many CSPs, BSS, OSS teams on cloud-native architectures, but legacy systems will be around for some time and so these going to need to coexist.
