Telecom 6 min read

Modern telecom operator architecture: from monolithic BSS/OSS to cloud core

Transitioning from closed monolithic BSS/OSS to a modular API-first architecture based on ODA and 3GPP standards is essential for successful cloud integration and business agility.

Modern telecom operators are moving from monolithic systems to a modular architecture to accelerate innovation and prepare for autonomous networks. However, a significant obstacle arises: attempts to integrate new cloud services with legacy BSS/OSS limit business agility, slow down the launch of new tariffs, and reduce network management efficiency. Operators must find a balance between the stability of existing infrastructure and the innovation of cloud-native solutions.

Anatomy of a monolith: why the classic BSS/OSS bundle hinders operator development

Historically, telecom operator architecture was divided into two large and nearly isolated blocks: Business Support Systems (BSS), responsible for customer interaction, billing, pricing, and sales, and Operations Support Systems (OSS), which manage network resources, monitoring, configuration, and troubleshooting. Communication between them was typically built using proprietary connectors from specific vendors.

Monolithic architecture of past generations tightly couples business logic with operational processes, creating vendor lock-in and complicating the scaling of network functions. Any change in pricing or the launch of a new service package requires cascading changes in related systems. In addition to slow time-to-market, maintaining legacy systems without end-to-end access auditing deepens cybersecurity risks. Digital infrastructure and services account for approximately 27.7% of all data breaches among affected organizations, necessitating a transition to secure architectural models.

Transitioning to Open Digital Architecture (ODA): system decomposition in practice

To overcome the limitations of the monolith, the industry is guided by the Open Digital Architecture (ODA) concept from TM Forum. ODA replaces monolithic BSS/OSS with a component-based, API-first architecture, which is key to transitioning to autonomous networks. Instead of closed systems, the operator receives a set of standardized software components that interact via open interfaces.

A practical example of this approach is the implementation of Open APIs for integration between different business domains of an operator (e.g., between customer-facing frontends and billing or network orchestration systems). This allows for the abstraction of business logic from the technical details of network implementation. When a customer orders a service, the system sends a standardized API request to the core without requiring direct access to network equipment protocols.

Cloud-native and service-based architecture: how 3GPP standards are changing the network core

In parallel with the transformation of IT systems, the telecom network core is also evolving. According to 3GPP consortium standards, modern network architecture is built on the principles of Service-Based Architecture (SBA). The 5G core architecture (service-based) brings telecom operators as close as possible to cloud-native operating principles.

Migrating the network core to cloud technologies according to 3GPP standards to support 5G Standalone allows operators to flexibly manage resources by deploying network functions as independent services. It is important to understand that 5G is not a single standard or an instant solution for everyone—network evolution depends on specific 3GPP releases and each operator's individual migration strategy.

The integration challenge: combining legacy protocols with modern API-first platforms

The most difficult stage of modernization is building a bridge between legacy infrastructure (including softswitch, BSS/OSS) and the new cloud core. Since it is impossible to abandon old systems overnight, there is a need for a reliable intermediate integration layer.

Modernization of legacy OSS and the design of cloud-based telecom infrastructure are successfully implemented by teams from the Intecracy Group alliance (specifically through solutions from IQusion, which specializes in the telecom sector). The technological foundation for building such an integration layer is the UnityBase platform. This is a joint development by companies within the Intecracy Group, where InBase is a key, but not the only, developer.

By utilizing mechanisms of the UnityBase platform, such as a unified Domain metadata model, automatically generated REST APIs, and built-in audit trail subsystems, operators can quickly create flexible data buses. These combine the logic of legacy systems with modern API contracts. For telecom systems with high loads or increased security requirements, the official platform documentation recommends using commercial Enterprise or Defence editions, which support advanced access control mechanisms (RLS, ACL) and industrial DBMS.

Security during the transition period: protecting signaling channels during modernization

The transition period, during which an operator simultaneously operates cloud services and legacy infrastructure, creates additional vectors for cyberattacks. According to the ENISA Threat Landscape 2025 report, the exploitation of legacy signaling protocols, such as SS7 and Diameter, remains a significant security risk for mobile networks.

Furthermore, according to the CFCA Global Fraud Loss Survey 2025, global losses from telecom fraud in 2025 are estimated at approximately $41.82 billion. This forces operators to integrate authentication mechanisms directly into system architecture, particularly to combat caller ID spoofing in voice networks.

It should be remembered that the implementation of the ODA standard does not automatically eliminate all cybersecurity risks—it is primarily an architectural framework. To protect signaling channels and APIs, operators must implement Zero Trust models, strict microservice authentication, and end-to-end action auditing.

Maturity levels of telecom architecture during the transition to cloud-native

To assess the current state of infrastructure and plan migration, operators can rely on the following technological maturity scale:

  • Level 1: Monolithic. Tightly coupled BSS/OSS, proprietary interfaces, physical infrastructure.
  • Level 2: Hybrid. Partial virtualization of functions, implementation of APIs for specific new services.
  • Level 3: Service-oriented. Component-based ODA architecture, use of Open APIs, containerization.
  • Level 4: Autonomous / Cloud-native. Fully cloud-based 3GPP SBA core, auto-scaling, end-to-end orchestration.

Gradual decomposition of the monolith based on ODA principles, the transition to a service-oriented core architecture, and the implementation of standardized integration platforms allow telecom operators to ensure business agility and reliably protect their networks from modern threats.

FAQ

What is TM Forum Open Digital Architecture (ODA) and what are its benefits for an operator?

TM Forum ODA is a concept that replaces monolithic BSS/OSS with a component-based, API-first architecture. It allows for the abstraction of business logic from the technical details of the network, which accelerates innovation, reduces vendor lock-in, and is a key stage in the transition to autonomous networks.

How can legacy BSS/OSS systems be integrated with new cloud-based 5G components?

This is achieved by deploying an intermediate integration layer that translates legacy protocols into modern, standardized API contracts. An effective approach is using low-code platforms, such as UnityBase, which provide a unified data metamodel, automatic generation of REST APIs, and reliable transaction auditing.

What security risks arise when using legacy protocols and cloud APIs simultaneously?

According to ENISA data, the primary risk remains the exploitation of legacy signaling protocols (SS7, Diameter). To minimize threats, it is necessary to implement Zero Trust principles, robust authentication mechanisms to prevent caller ID spoofing, and specialized solutions for API protection.

Data sources

Sources & materials

Materials and sources used in this article.

  1. TM Forum: Open Digital Architecture (ODA) — web.tmforum.org
  2. 3GPP — Mobile Standards — 3gpp.org
  3. ENISA Threat Landscape 2025 — enisa.europa.eu
  4. CFCA Global Fraud Loss Survey 2025 — cfca.org