The journey to a cloud BSS – Ericsson

BSS sits at the center of the telco network this is where product, order, revenue and customer management take place in order to transform operators assets into revenue. Borne of technology that is now decades old, traditional BSS didnt give vendors much choice. Complex applications spanning multiple services running in bare-metal servers with local databases are still present in many CSPs around the world. Proprietary tightly coupled integrations were built to serve as the glue that connects all these necessary functions.

In recent years there has been much progress in the way BSS applications interact with the underlying infra-structure, mainly through virtualization. But this was not enough to meet the growing CSP demands of automation, speed, lower operational costs and agility. We are at a critical juncture, especially now that we are entering a new era with 5G monetization challenges and opportunities. A re-architecture to cloud BSS is the answer.

Cloud BSS is the evolved BSS applications architecture that leverages all the benefits of the cloud infra-structure, such as deployment automation, automatic scalability, resources usage efficiency and built-in high availability. Despite the lack of consensus around what constitutes cloud-native BSS applications there are several principles that must be followed to simplify BSS architecture and get all the benefits of cloud architectures:

Even though there were some standards and architectural principles, in the past the traditional BSS was created and evolved mainly to solve customer needs as quick as possible as the network technology rapidly enabled new products and services. In a lot of cases a new development was done wherever it was easier and faster to deliver a new feature in order to get products and services to market. The result is that today many CSPs have big infra-structure footprints tied to their BSS applications, with complex architectures to guarantee high availability, distributed databases across different systems and large modules handling different capabilities that didnt have much to do with each other. Their software systems became a patchwork of home-grown systems and systems bought from multiple vendors over a long period of time (some more than 30 years ago). This puts a special burden on CSPs in terms of upgrading both these systems and the skills of their staff. CSP businesses have many moving parts that require substantial planning and execution effort, with associated capex and opex burdens.

If we compare the traditional and cloud BSS side-by-side, it is quite impressive to see that even the terms and descriptions are getting simpler:

TRADITIONAL BSS

PRINCIPLE

CLOUD BSS

Coupled hardware and software

Choices

IaaS

Monoliths, highly customized

Decomposition

Mini and microservices

Complex, expensive HA solutions

Resiliency

99,999% availability

Local databases, distributed states

State optimization

Stateless applications

Complex O&M with long maintenance windows

Orchestration and automation

Continuous Delivery / Continuous Integration (CI / CD)

Proprietary customized integrations

Openness

Open APIs

There are multiple benefits in moving BSS to a cloud architecture. Software application development using microservices architecture (or miniservices, a more pragmatic approach to microservices for BSS focusing on achieving business objectives) is currently the fastest way to develop and deploy software applications while separating functionalities, integrations and databases. It allows the broad adoption of DevOps software engineering principles that allows optimized and automated deployment and operation and maintenance (O&M). In addition, it becomes much simpler and faster to deploy high availability and resiliency by bringing containers up and down. As a result, CSPs can save capex and opex and shorten the time it takes to launch new services to the market.

The benefits of cloud BSS are quite impressive but there is no one route forward the journey is dependent on the unique combination of components and connective tissue in place today. Most operators are still using many legacy business support systems that were designed for on-premises deployment in CSPs operational environments. Customizations are everywhere. Implementing a completely new, side-by-side stack while maintaining the legacy one isnt really an option. A gradual, stepwise re-architecture of BSS components to a cloud architecture is needed in order to get the benefits of the cloud while safeguarding existing revenues.

The first step is to identify which BSS applications offer a compelling case to migrate. For example, front-end digital systems are a good place to start because they are usually new, and speed of adoption is unpredictable, so a quick payback is possible from the elasticity that cloud delivers. By starting with this outer layer, CSPs can develop the expertise and competence they need to tackle more challenging migrations at a deeper level at a more gradual pace. Such as OCS (on-line charging system) and billing, where most of their monetization is coming from and are heavy on customizations and have critical real-time and/or availability requirements. In these cases, modules decomposition into mini and microservices enhanced with new cloud capabilities and separation of data is the way to introduce a cloud architecture along with existing legacy functionalities. Finally, to simplify integration between front and back-end systems, new cloud-based layers can sit between front and back-end applications to decouple them, making full use of TM Forum Open APIs to simplify and speed-up the integration of multiple vendors systems. Multiple small steps in tandem will allow the stepwise introduction of CI/CD pipelines across all the delivery process.

Modernizing BSS is a critical component on the journey to becoming a digital service provider. As digital service providers seek competitive advantage, they need a consistent application foundation to foster innovation and speed. The introduction of 5G, its new use cases and monetization models are already posing challenges to existing traditional BSS. At the same time CSPs must balance the needs of the existing customer base that brings them the revenues they need to invest in the new technologies, new business models and new revenues opportunities.

Thats what we have in mind here at Ericsson while evolving our telecom BSS products to the cloud. By evolving our portfolio, we want to leverage previous CSPs investments with a clear path to 5G monetization. This allows migration at a flexible pace to a cloud native microservices-based BSS architecture, integrating legacy applications as needed. Then, slowly but surely, the benefits of cloud BSS will transform the monetization capabilities of the telecom business.

Read what operators are saying about 5G monetization. Download the MIT report

Read morte about Telecom BSS

More:
The journey to a cloud BSS - Ericsson

Related Posts

Comments are closed.