Episode VIII: The OBss Strikes Back

Authors: Fatih Nar Chief Architect, Aviv Guetta Chief Technologist, Patrick Farley Senior Solution Architect and Ishu Verma Emerging Technology Evangelist

Introduction

Operational Support Systems (OSS) is a term used to describe the information processing systems used by operators to manage their communications networks, which are now becoming so much more sophisticated to support new networks and new business models. They allow an organization to coordinate customers, services, resources, processes and activities. They assist service providers to design, build, operate and maintain communications networks. OSS, traditionally, aimed to provide network-facing or network-operations-facing functionality, including fault/performance management (assurance), subscriber/service activations (fulfillment), asset / inventory / configuration management, network security and much more.

Figure-1 Pyramid of OSS/BSS for Fulfillment vs Assurance

Business Support Systems (BSS) on the other hand is the term used to describe the business and/or customer-facing functionality. BSS tools allow an organization to connect with their partners and customers (e.g. customer relationship management or CRM), create offerings for them, issue customers with bills as well as inter-business transactions (settlements, point-of-interconnect).

Figure-2 OSS/BSS Re-visited with Cloud Computing for Next-G

Together, OSS and BSS aim to enable network operators to efficiently (faster time to market -ttm-, low operational and capital expenditures -opex/capex-) and reliably (distributed on multi-clouds, powered by ai/ml operations) offer existing services with lower cost and the new services with better revenue models towards enormous numbers of subscribers & devices/terminals/machines (dynamic infinite scale) on some of the world’s most complex systems such as; global communications & media & entertainment networks.

In this study, we visit the next generation cloud ready OSS and BSS solution blueprint, what it can offer for next generation (next-gen) communication solutions (ex; 5G/6G) and how to deliver the right set of capabilities with a multi-cloud approach while leveraging common platform layers with various options and open-source platform solutions, backed with enterprise service level agreements (SLA).

Solution Blueprint

At the core, the OSS and BSS solutions aim to handle the essential processes of; product management, order management, revenue management and customer management. The constantly changing market trends, technology advancement and business prospects (Figure-2) is driving the need for the next-gen OSS and BSS solution.

The use of multi-cloud strategy helps us scale better in terms of time , cost and agility (faster ttm). However, this new compute as utility paradigm also brings complexity in terms of more technology stacks to deal and manage. The solution blueprint leverages automation and managed services / SaaS (software as a service) to overcome this complexity , and still provides the service level agreement (sla) support. The solution blueprint ties the dots between market trends, technology advancements and business success factors.

Figure-3 Logical Solution Diagram for OSS/BSS

Our proposed next generation OSS & BSS solution blueprint is built on few fundamental design principles:

1. [Layered Solution] Separation of OSS/BSS applications from common platform (enterprise grade kubernetes based application platform) and infrastructure (on-premise private cloud, hyperscalers). This allows for; capturing OSS/BSS value within the application layer enriched by platform, powered by infrastructure.
2. [Break-Down/Build-Up] OSS/BSS functions implemented in atomic fashion (ex; fault management, performance management, alert management and accounting) so enriched and more complex value added services can be built using these as constructs (ex; service assurance, revenue assurance, mediation, ai/ml driven operations and more).
3. [Self-Organized, Autonomous Systems] Self-aware and self-scaling complete OSS/BSS solution, from infrastructure to platform to OSS/BSS application-set.

Layered Solution

This solution blueprint recommends; creating an abstracted layering approach based on application-set placement locations :

• Core: This is where the OSS/BSS solution core is deployed, leveraging on-demand, high availability with low cost cloud multi-region/zone infrastructure. The network fabric design part of the solution blueprint is architected to avoid well known networking drawbacks (latency, replication durations etc). Using pre-integrated native cloud networking constructs and facilities (unicast ip use, geo-load balancers etc), the solution delivers the best experience together with on-demand auto-scaling when and where needed.
• Edge: This layer covers OSS/BSS solution extensions (ems, distributed api gateways, data ingest proxies etc), benefiting from hyperscaler edge (e.g; local zones) as a proximity based availability and/or near-by bursting option.
• Far-Edge: Application probes and agents resides at this layer, which; process and operate (e.g; xAPPs/rAPPs on the Near Real-Time RIC), ingress data and/or interact with the 5g core and OSS/BSS solution core, interact with the low-latency solutions running at on-premise.
• Device Edge: Similar to far-edge, this layer deals with interaction/interworking with edge devices like IoT devices, manufacturing facilities and other network subscribers, ingressing data from these devices towards the OSS/BSS core.

Figure-4 5G with OSS/BSS, Solution Layers

Break-Down/Build-Up

TM Forum describes core frameworks (ref; GB991) for OSS and BSS holistically, covering following domains; sales, customer, product, service, resource and partner domains deployed on different enterprise segments. Each domain includes many (literally) similar & also different capabilities that can be implemented separately/individually as well as commonly (i.e. mesh of applications) via core functions (micro-services) to construct a framework. As with cloud native 5g core solution, it is also composed of multiple micro-services addressing the functionalities and roles through well defined by 3gpp specifications. Please see our detailed work on distributed 5g on multi-cloud and how we have handled such complex solutions in the referenced work (ref;Link).

To address the challenges with distributed and complex OSS/BSS solutions, we have applied some of the best practices from 5g core deployments & operations (i.e. distributed micro-services with higher level of automation with standards’ guidance) so there is a consistent model across different layers of an end-to-end 5g solution.

Figure-5 EMS Service Discovery with Service Mesh + 3gpp NRF use

Lets focus on the OSS/BSS part inside the 5g solution; each of the OSS and BSS micro-services can either be integrated with a 5g core service over kubernetes (k8s) service exposure and/or implement an abstraction layer via an element management system (ems shown in Figure-5) and perform functional/logical breakdown underneath. Having such an abstraction layer reduces integration points as well network traffic complexity for OSS and BSS deployments and management and also enables single point of data governance.

• Using service discovery by ems abstraction layer, allows dynamic observability data aggregation for the logs, metrics and traces across various 5g cnf sets. Ems performs service discovery over 5g nrf communication and each 5g cnf deliver (pull and/or push) all requested information elements by ems.
• Collected OSS and BSS data (infrastructure/platform/application telemetry data) can be processed and used to deliver data mesh, data driven standalone applications and/or data enriched external services portfolio, each of which can be coupled with others, as well as hyperscaler ready to use saas (e.g. ml/ai engines) offerings, to bring different complete value added services to life, while cost & time to market is kept optimal (see Figure-6 for how data mesh and OSS/BSS services can be coupled to delivery complex value chains).

Figure-6 Data Mesh Driven Service Flow

• 3gpp also defines basic functional entities for OSS / BSS in terms of required capabilities and capacities to deliver service based architecture (sba) promises. A 5g cloud native network function (cnf) can/may have ability (ex; amf, smsf, smf and pcf) of charging trigger function (ctf), that delivers the necessarily information elements to 5g charging function (chf) cnf over Nchf interface (the services and protocols of this interface are described in 3GPP TS 32.290 and 3GPP TS 32.291 specifications), which is part of the new converged charging system (CCS).

Figure-7 GPP Charging Topology (Ref: 3GPP TS 32.240)

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

Figure-8 Service Delivery Charging Flow (Ref: 3GPP TS 32.290)

CCS can (usually is) be integrated with the rest of bss operations flow via an api gateway and/or perform ingress into another enriched operation flow directly (see external-api-gw and bss-ops-ingress in Figure-6) to deliver holistic revenue/service operations.

• Network segmentation/isolation has importance for OSS/BSS micro-services. With OSS and BSS being business critical portfolios of a service provider, this portfolio of services have to be kept in isolated networks (ex; not directly connected to the internet). In cloudification of OSS and BSS solutions we can still use private networks for such deployments and use api-gw(s) and/or nat/proxy abstractions to reach external cloud services for cross pollination (enrichment).
• Use of open-source technology stacks can accelerate OSS and BSS distributed micro-services deployment, integration, management and control with 5g core deployments, as well as allow the use of common backend services and visualization tools (such as istio service mesh, kiali, jaeger, zipkin, prometheus, thanos etc). Using the same open-source stacks enable OSS and BSS solutions to be infrastructure agnostic and offer consistent experiences with multi-cloud deployments.

Self-Organized Autonomous Systems

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

• Apps are difficult to manage at scale and error prone
• Inconsistency with security controls across environments
• Components are overwhelming to verify
• Difficulty in managing configurations, policies, and compliance

This is where 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” using Git pull requests to manage, automate and track changes.

• Everything as code: The entire state of infrastructure, applications, and configurations is defined declaratively and as code. That 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 needs to be treated as code and follow the same principle.

Figure-9 GitOps Mantra

• Git is the single source of truth: State of infrastructure and applications are stored and versioned in the Git version control system in order to take advantage of traceability and visibility that Git provides for the entire state of infrastructure and applications. Any change that is available somewhere on the infrastructure and applications, must be represented in the Git repositories first.
• Operations through Git workflows: Provisioning and deployment performed through familiar Git pull-request workflows. The pull-request or merge-request workflow is a familiar practice for application development and developers. The idea of GitOps is to apply the same workflow to any change that goes into infrastructure and applications. Changes are proposed through issuing a pull-request to the respective Git repository, and after reviews and approval process, gets merged in the repository which is 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 (K8s) GitOps Operator (based on ArgoCD open source project) enables application developers and consumers to get started using GitOps workflows to declaratively configure their infrastructure and applications across multi-cluster and multi-clouds.

Figure-10 Autonomousity with GitOps

Abilities like; multi-cluster management, end to end secure software pipelines and extendable automation platforms provide a solid foundation for applying GitOps-style workflows to a wide variety of 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, etc.

Figure-11 Core Platform Automation

GitOps-enabled workflow comes together with (Figure-11); using multi-cluster management to automate the deployment and management of the OSS/BSS core platform extensions, applications, control policy compliance and enforcement, and using automation platform to automate everything outside of Kubernetes — such as the configuration of networking, databases, load balancers, firewall, etc. The automation platform empowers OSS/BSS teams to build a full end to end solution that includes the required infrastructure resources without having to waste time. All of the tasks that would normally require interaction with other teams to automate, can now be performed within one single pane of glass.

Summary & Closure

Promising new abilities brought by 5G, provide the unseen/untapped opportunities for tme service providers, to develop new business models and services based on new information & capabilities such as; performance, analytics , API exposure and network slicing/segmentation and more.

In order to monetize the new business models and services, the OSS and BSS solutions have to be revisited (with cloud) and in summary overall enhanced 5g ready OSS/BSS solution blueprint shall focus on (Figure-12 with clock wise explanation with marked numbers);

(1) Mature and reliable 5G Integration (with 3gpp specs guidance).
(2) Preserved legacy charging systems usage with transition to 5g converged charging system/solution.
(3) Aimed 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 partnership with hyperscalers (lowering the cost of building and maintaining such complex solutions).
(7) Covered 3G/4G and IMS networks.

Figure-12 OSS and BSS Modernization with Cloud Summary

In this blueprint work we have delved into “some of the key parts” of these seven areas with; exposed the basic layers of a proposed solution, broke the OSS and BSS solutions into atomic sub-components and re-constructed better approaches from atomic components, pointed the value of automation to create self-aware and self-scalable OSS and BSS platforms and services.

What we have presented here, is a generic blueprint to accommodate a multi-cloud strategy execution for OSS and BSS modernization, some parts can be enhanced , even changed with different approaches to accommodate particular business needs, if you need assistance and value driven partnership we are humbly at your service.