How to modernize 5G operational and business support systems for the cloud

Operational support systems (OSSes) are the information processing systems that manage communications networks. These systems allow an organization to coordinate customers, services, resources, processes, and activities. They assist service providers in designing, building, operating, and maintaining communications networks.

[ Learn why open source and 5G are a perfect partnership. ]

Traditionally, OSSes aimed to provide network-facing or network-operations-facing functionality, including fault and performance management (assurance), subscriber and service activations (fulfillment), asset and inventory management, configuration management, and network security.

On the other hand, business support systems (BSSes) provide business and customer-facing functionality. BSS tools allow an organization to connect with partners and customers (using customer relationship management, or CRM, services), create offerings, issue bills to customers, and generate inter-business transactions such as settlements and point-of-interconnect.

Our group's previous articles presented the 5G Open HyperCore architecture, using Kubernetes for edge applications, improving container observability with a service mesh, comparing init containers in Istio CNI, implementing self-scaling 5G core, architecting distributed scalable 5G with observability, and using cloud hyperscalers to handle 5G traffic demand bursts.

This article describes how OSS and BSS together can enable network operators to efficiently and reliably offer existing services at a lower cost and provide new services with better revenue models for enormous numbers of subscribers, devices, terminals, and machines. The two systems enable this on the world's most complex systems, including global communications, media, and entertainment networks.

OSS and BSS goals are:

• Efficiency: Faster time to market with lower operational and capital expenditures
• Reliability: Based on distributed systems on multiclouds powered by artificial intelligence (AI) and machine learning (ML)

This article examines the next-generation cloud-ready OSS and BSS solution blueprint, what it can offer for next-generation communication solutions (5G and 6G, for instance), and how to deliver the right set of capabilities with a multicloud approach. This is done while leveraging common platform layers with various open source solutions backed by enterprise service level agreements (SLAs).

Solution blueprint

Constantly changing market trends, technology advancement, and business prospects drive the need for next-generation OSS and BSS solutions. At their core, OSS and BSS solutions aim to handle the essential processes of product management, order management, revenue, and customer management.

Using a multicloud strategy helps organizations scale time, cost, and agility better, which ideally results in a faster time to market. However, this new compute-as-utility paradigm also brings complexity because there are more technology stacks to manage.

[ A complimentary guide from Red Hat: The automation architect's handbook. ] 

Our solution blueprint leverages automation, managed services, and software-as-a-service (SaaS) to overcome this complexity and still provides SLA support. The solution blueprint connects the dots between market trends, technology advancements, and business success factors. Please note that this solution blueprint is still under development and undergoing detailed validation efforts.

We built our proposed next-generation OSS and BSS solution blueprint on a few fundamental design principles:

1. Layered solution: The solution separates OSS and BSS applications from a common platform (enterprise-grade Kubernetes-based application platform) and infrastructure (on-premises private cloud and hyperscalers). This approach captures OSS/BSS value within the application layer enriched by the platform and powered by infrastructure.
2. Break down and build up: OSS/BSS functions are implemented in an atomic fashion (such as fault management, performance management, alert management, and accounting) so that enriched and more complex value-added services can be built using these as constructs (such as service assurance, revenue assurance, mediation, and AI/ML-driven operations).
3. Self-organized autonomous systems: Self-aware and self-scaling complete OSS/BSS solutions, from infrastructure to platform to OSS/BSS application set, are integral to the design.

Layered solution

This solution blueprint recommends creating an abstracted, layered approach based on these application-set placement locations:

• Core: This is where the OSS/BSS solution core is deployed, leveraging on-demand high availability with a low-cost cloud multiregion, multizone infrastructure. The network fabric design part of the solution blueprint is architected to avoid well-known networking drawbacks (such as latency or replication durations). Using integrated cloud-native networking constructs and facilities (for example, unicast IPs, geoload balancers), the solution delivers the best experience with on-demand autoscaling when and where needed.
• Edge: This layer covers OSS/BSS solution extensions (such as element management systems [EMS], distributed API gateways, or data ingest proxies), benefiting from hyperscaler edge (local zones) as a proximity-based availability and nearby bursting option.
• Far edge: This layer operates on ingress data and interacts with the 5G/OSS/BSS solution core and on-premises low-latency solutions. This is where applications, probes, and agents are located, such as xAPPs (software tools used by the RAN intelligent controller, or RIC, to manage network functions in real time) and rAPPs (which manage non-real-time events within the RIC).
• Device edge: Similar to the far edge layer, this layer deals with interaction and interworking with edge components, including Internet of Things (IoT) devices, manufacturing facilities, and other network subscribers, ingressing data from these devices towards the OSS/BSS core.

Break down and build-up

TMForum's GB991 standard holistically describes core frameworks for OSS and BSS and covers the following domains: sales, customer, product, service, resource, and partner domains deployed on various enterprise segments.

Each domain includes many similar and different capabilities that can be implemented individually and in combination (a mesh of applications) through core functions (microservices) to construct a framework. As with a cloud-native 5G core solution, a domain is composed of multiple microservices addressing the functionalities and roles through specifications defined by 3GPP. Please see our article Edge computing: How to architect distributed scalable 5G with observability to learn more about how we've handled distributed 5G on multicloud infrastructure.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

To address the challenges with distributed and complex OSS/BSS solutions, we have applied some of the best practices from 5G core deployments and operations (distributed microservices with higher levels of automation and standards guidance). The result is a consistent model across different layers of an end-to-end 5G solution.

Within the 5G solution, each OSS and BSS microservice can either be integrated with a 5G core service over Kubernetes service exposure or implement an abstraction layer via an element management system (EMS, shown in Figure 4) and perform functional and logical breakdown underneath. Such an abstraction layer reduces integration points and network traffic complexity for OSS and BSS deployment and management and enables a single data governance point.

• Using service discovery by the EMS abstraction layer allows dynamic observability data aggregation for the logs, metrics, and traces across various 5G cloud-native network function (CNF) sets. EMS performs service discovery over 5G network repository function (NRF) communication, and each 5G CNF delivers (pull or push) all requested information elements by EMS.
• Collected OSS and BSS data (infrastructure, platform, and application telemetry data) can be processed and used to deliver data mesh, data-driven standalone applications, and a data-enriched external services portfolio. Each can be coupled with others, as well as hyperscaler-ready SaaS (for example, ML and AI engines), to bring complete value-added services to life. At the same time, cost and time to market are optimized (see Figure 5 for how data mesh and OSS/BSS services can be coupled to deliver complex value chains).

• 3GPP also defines basic functional entities for OSS/BSS for required capabilities and capacities to deliver service-based architecture (SBA) promises. A 5G CNF, such as access and mobility management function (AMF), SMS function (SMSF), session management function (SMF), and policy control function (PCF), may be able to provide a charging trigger function (CTF). This function delivers the necessary information elements to a 5G charging function (CHF) over an NCHF interface (the services and protocols of this interface are described in the 3GPP TS 32.290 and 3GPP TS 32.291 specifications), which is part of the new converged charging system (CCS).

CCS includes an account balance management function (ABNF), charging gateway function (CGF), and rating function (RF) as part of the solution (see Figure 7 for the relational model). Although in 3GPP flows, CCS is seen as a single box, it is actually a combination of multiple services talking to each other (east-west communication) and delivering a complex value-added service to the outer world (north-south communication). See 3GPP TS 32.290 for details.

CCS is often integrated with the rest of the BSS operations flow via an API gateway or performing ingress into another enriched operation flow directly to deliver holistic revenue and service operations (see external-api-gw and bss-ops-ingress in Figure 5).

• Network segmentation and isolation are important for OSS/BSS microservices. With OSS and BSS being business-critical solutions for a service provider, this portfolio of services must be kept in isolated networks and not directly connected to the internet. In the cloudification of OSS and BSS solutions, we can still use private networks for such deployments and use api-gw(s) or network address translation (NAT) or proxy abstractions to reach external cloud services for cross-pollination (enrichment).
• Open source technology stacks can accelerate OSS- and BSS-distributed microservices deployment, integration, management, and control with 5G core deployments. They also allow using standard backend services and visualization tools such as Istio service mesh, Kiali, Jaeger, Zipkin, Prometheus, and Thanos. Using the same open source stacks enables OSS and BSS solutions to be infrastructure-agnostic and offer consistent experiences with multicloud deployments.

Self-organized autonomous systems

As organizations deploy more applications across multiple clouds, new operational and business challenges arise. Some of those challenges include:

• Apps are difficult to manage at scale, and configurations are prone to errors.
• There is inconsistency with security controls across environments.
• Components are overwhelming to verify.
• It's hard to manage configurations, policies, and compliance.

GitOps helps manage such complex operational scenarios. GitOps is a means of accelerating and simplifying application deployments, infrastructure management, and overall operations tasks using Git version control as your system's "source of truth" and using Git pull requests to manage, automate, and track changes.

[ Download The path to GitOps to put the right tools, workflows, and structures in place to enable a complete GitOps workflow. ] 

GitOps principles:

• Everything as code: The entire state of infrastructure, applications, and configurations is defined declaratively and as code. This includes what the infrastructure looks like, how the application should be deployed, and how it should be configured across environments. Even the continuous integration and continuous delivery (CI/CD) infrastructure must be treated as code and follow the same principle.

• Git is the single source of truth: The state of infrastructure and applications are stored and versioned in the Git version control system to take advantage of the traceability and visibility that Git provides. Any changes to the infrastructure and applications must be represented in the Git repositories first.
• Operations through Git workflows: Provisioning and deployment are performed through routine Git pull-request workflows. The pull-request or merge-request workflow is an everyday practice for application developers. The idea of GitOps is to apply the same workflow to any change that goes into infrastructure and applications. Changes are proposed by issuing a pull request to the respective Git repository. After review and approval, changes are merged in the repository and then applied to the target infrastructure. The complete history of the changes, review process, and deployment is visible through Git history on the Git repository.

Kubernetes GitOps Operator (based on the ArgoCD open source project) enables application developers and consumers to start using GitOps workflows to declaratively configure their infrastructure and applications across multiclusters and multiclouds.

Abilities like multicluster management, end-to-end secure software pipelines, and extendable automation platforms provide a solid foundation for applying GitOps-style workflows to various use cases within the OSS/BSS service provider application framework. Using Git-based business operations, you can declaratively manage supply chain security, cluster lifecycle management and compliance, policy management, application delivery on edge, AI/ML workload through MLOps, and more.

The GitOps-enabled workflow comes together with using multicluster management to automate the deployment and management of the OSS/BSS core platform extensions, applications, control policy compliance, and enforcement (see Figure 10). The workflow uses automation platforms to automate everything outside of Kubernetes, such as configuration of networking, databases, load balancers, and firewalls. The automation platform empowers OSS/BSS teams to build a full end-to-end solution that includes the required infrastructure resources without wasting time. All tasks that would typically require interaction with other teams to automate can be performed within one single pane of glass.

Summary

The promising new abilities of 5G provide untapped opportunities for telecommunications, media, and entertainment (TME) service providers. They can now develop new business models and services based on new information and capabilities, such as performance, analytics, API exposure, and network slicing and segmentation.

To monetize the new business models and services, the OSS and BSS solutions must be revisited with cloud.

In summary, the overall enhanced 5G-ready OSS/BSS solution blueprint focuses on:

1. Mature and reliable 5G integration (with 3GPP specs guidance)
2. Preserved legacy charging systems usage with a transition to 5G converged charging systems and solutions
3. New B2B and B2C revenue streams (cross-value generation with data and service meshes)
4. Enabled data-driven evolution for OSS and BSS
5. Cloud-native core solution architecture (on-demand scaling where and when needed)
6. Encountered partnerships with hyperscalers (lowering the cost of building and maintaining such complex solutions)
7. Covered 3G/4G and IMS networks

In this blueprint, we delved into some key parts of the seven areas shown in Figure 11. We exposed the basic layers of a proposed solution, broke the OSS and BSS solutions into atomic subcomponents, reconstructed better approaches from atomic components, and pointed out the value of automation in creating self-aware and self-scalable OSS and BSS platforms and services.

This is a generic blueprint to accommodate a multicloud strategy execution for OSS and BSS modernization. Some parts can be enhanced or even changed with different approaches to address particular business needs.

Check out Red Hat Portfolio Architecture Center for an entire catalog of solutions that are all built off of successful customer deployments for telecommunications, media, and entertainment (TME) service providers.

This article originally appeared on Medium as The OBss strikes back and is republished with permission.