5G BSS: Evolving BSS to fit the 5G economy

Ericsson CTO Erik Ekudden’s view on how BSS must evolve in tandem with 5G rollout

The 5G network evolution has opened up an abundance of new business opportunities for communication service providers (CSPs) in verticals such as industrial automation, security, health care and automotive. In order to successfully capitalize on them, CSPs must have business support systems (BSS) that are evolved to manage complex value chains and support new business models. Optimized information models and a high degree of automation are required to handle huge numbers of devices through open interfaces.

This Ericsson Technology Review article explains how 5G-evolved BSS can help CSPs transform themselves from traditional network developers to service enablers for 5G and the Internet of Things, and ultimately to service creators with the ability to collaborate beyond telecoms and establish lucrative digital value systems.

5G offers communication service providers an unprecedented opportunity to enhance their position in the value chain and tap into new revenue streams in a variety of industry verticals. A successful transition will require business support systems (BSS) that are evolved to fit the 5G economy.

The rapidly expanding Internet of Things (IoT) and all the new capabilities available in 5G have opened up a wealth of opportunities for communication service providers (CSPs) beyond their traditional markets, particularly in verticals such as automotive, health care, agriculture, energy and manufacturing. To monetize them, CSPs will need to meet the expectations of a broader range of stakeholders and be able to handle complex ecosystems.  

One of the primary roles of business support systems (BSS) is to manage a CSP’s relationships with its stakeholders by keeping track of agreements, handling orders, generating reports, sending invoices and so on. In the past, these stakeholders were generally limited to consumers, resellers, partners and suppliers. In the 5G/IoT business context, though, more complex ecosystems are arising that BSS must evolve to support. To do so, the requirements of a larger, more diverse group of stakeholders must be taken into account, and mechanisms must be established to manage the relationships between them.

Examples of new stakeholder groups that need to be considered in the 5G/IoT business context include:

• Enterprises and industry verticals that require solutions beyond telecoms
• New types of suppliers such as IoT device providers and suppliers of eSIM (embedded SIM) and related technologies
• Platform providers that specialize in specific IoT or edge clusters or groups of use cases such as massive and broadband IoT platforms, industrial IoT platforms and content data networks
• Integrators that specialize in specific verticals such as asset management, mission-critical services or automotive that combine capabilities from multiple stakeholders to address consumer needs.

Network developer, service enabler or service creator?

Looking ahead, the capabilities that a CSP needs in its BSS solution will depend on the role it plays – or aims to play – in the IoT ecosystem. Figure 1 illustrates the three role types: network developer, service enabler and service creator.

In the traditional network developer role, a CSP acts solely as a cellular connectivity provider by offering solutions such as radio, core network and communication services. In this role, the CSP’s business models are consumer focused. Its role in the IoT ecosystem is limited.

In the service enabler role, the CSP extends its services by incorporating additional capabilities such as cloud/edge and IoT enablement and shifts focus to business customers and industry verticals. The CSP becomes a service enabler for 5G and the IoT, acting as a supplier of connectivity and platform services. As a service enabler, the CSP’s business models are extended to business-customer focused with respect to 5G IoT.

In the service creator role, the CSP transitions from being a connectivity and platform provider to creating new digital services and collaborating beyond telecoms to establish digital value systems. As a service creator, the CSP partners with suppliers to deliver new services all the way up to full IoT solutions, taking on the roles of integrator, distributor or co-seller.

BSS for all three CSP roles

Traditional BSS support the CSP in the network developer role, in which the CSP charges for voice, text and data services based on consumption or subscription level. The main requirements for these BSS are:

• Customer management, traditional partner business (roaming partners), charging and billing, and finance modules
• Order capture and order execution for new telco subscriptions and/or add-on offerings
• Charging and balance/quota management in BSS, as well as mediation
• Interaction with operations support systems (OSS) for network provisioning.

Evolving BSS to support a CSP in a service enabler role requires a shift in focus to the needs of enterprise customers and IoT use cases. The BSS must be transformed into a system that is able to monetize IoT/5G platforms and edge deployments, which requires significant changes in both the functional and non-functional space. In the non-functional space, this mainly involves scalability – that is, enabling the BSS to handle traffic and a large number of devices at IoT scale.

In terms of functionality, the BSS enhancements required by service enablers include:

• Automation of full life-cycle management for devices/IoT resources supported by flexible orchestration, including exposure of services for managing relationships with business customers
• Support for batch orchestration, flexible supply agreements and contracts for non-telco services with associated charging models
• Service exposure of network capabilities, so that IoT providers can bundle their offerings with connectivity and sell them on to their customers
• Service exposure of BSS and OSS capabilities to enable efficient ordering processes, especially with regard to the management of mass subscriptions.

Supporting a CSP in the service creator role, where the full life cycle of partners must be taken into account, requires BSS with further functional extensions. The stakeholder ecosystem of service creators is significantly more complex, as the customer base broadens to include verticals and the CSP starts offering full solutions beyond telecoms. As a result, BSS for service creators must include extensive and flexible partner relationship management. Supply chain management is especially important.

The capacity to expose network capability as well as BSS and OSS capabilities is critically important to a CSP’s ability to deliver on service creation beyond telecoms, so that partners can develop tailored applications and deploy them on the operator’s infrastructure.

Finally, the new business models available to CSPs as service creators require new monetization models for charging and billing. For example, multiparty charging, revenue sharing and profit sharing all require extended billing and reconciliation functionality.

BSS solution levels and key capabilities

Table 1 organizes and sequences key BSS capabilities based on technical dependencies and/or level of complexity. One by one, these capabilities add on to each other, continuously increasing BSS maturity and transforming the BSS into a system capable of supporting all the new use cases and business models that characterize the 5G/IoT ecosystem.

The first evolution step – ‘5G enabled’ in Table 1 – provides support for new 5G standards and concepts, which enables a drastic increase in data transmission throughput while maintaining focus on traditional consumers. Applying containerization and a common technology stack will assure the scalability of the BSS solution to meet the increased throughput demands of the network.

At the next solution level, IoT and edge monetization, the focus shifts to business customers. These new capabilities enable the CSP to provide extended support for enterprises when it comes to 5G and IoT use cases by covering IoT device management, support for non-telco service charging and multi-party charging as well as IoT and/or edge-platform monetization. In addition, service exposure enables self-service for enterprises along with application development for the optimization of IoT devices. The number of 5G/IoT use cases that the CSP is able to support increases drastically at this stage.

The addition of partner capabilities at the full 5G ecosystem level allows the CSP to address totally new customer segments beyond telecoms and provide industry-specific solutions to verticals. A CSP can create new services (even deliver BSS as a service), and offer these services on a marketplace to reach new segments of business customers. The multitude of partnerships require support for new business models that allow flexible charging, revenue sharing and billing.

Table 1: Key capabilities of the three BSS solution levels

5G reference architecture for BSS

From a high-level architectural viewpoint, BSS in the 5G/IoT ecosystem closely resemble traditional BSS, with similar interfaces to surrounding systems. The BSS architecture in Figure 2 is presented in the Open Digital Architecture format [1]. It is divided into party management, core commerce management, intelligence management, production and engagement management. Production includes the southbound application programming interface (API) layer to the network infrastructure, IoT platforms, cloud/edge and OSS, while engagement management includes the northbound API layer to customers and partners.

5G and the IoT place several challenging requirements on new capabilities in the BSS architecture that are not directly visible at a high level. All functional areas are affected by the 5G evolution and are extended to support the new requirements and possibilities, most notably in the areas of mass-device management, device and resource life-cycle management, subscription management, charging models for non-telco
services and multiparty charging.

IoT-scale mass-device management

The sheer number of connected devices in the 5G/IoT world is a major challenge for BSS to manage. While current BSS architectures are scalable, they will be too costly for IoT use cases due to the large data footprint and processing need of each device. Scalability alone is not enough to handle massive amounts of devices. To address this, 5G-evolved BSS must have a persistence and management model that is lightweight enough to allow a large number of devices to use the same footprint as one traditional device. This can be addressed using concepts such as herding, where each individual device only requires a minimal data footprint. The behavior of each individual device is determined by the herd configuration, which is a single specification per herd.

Life-cycle management of IoT devices and resources

Managing the life cycles of IoT devices and resources is another significant challenge for BSS. In many emerging IoT applications, the ability to monitor the state of the device throughout its life cycle is not sufficient. For example, contracts that cover large herds of devices are likely to be based on recurring charges per active device. In these scenarios, the aggregated numbers of devices per state become key parameters in the calculation of charges.

The calculation of charges related to IoT devices is also complicated by the fact that the state of the device can influence the charged party. One example of this challenge is IoT devices that are mounted in vehicles at a factory. The factory personnel will likely want to test that the device is working before shipping the vehicle to the reseller. The reseller may then want to demonstrate the service the device provides to prospective buyers, before a consumer ultimately buys the vehicle and starts using the service. At each of these stages, the charged party and charging model may be different depending on the state of the device. Overcoming such challenges requires a BSS architecture that can provide up-to-date state information per individual device or resource as well as aggregated information to the rating, charging and billing functions.

Subscription management for IoT devices

Subscription management is another area that must evolve to fit the new 5G/IoT business context. Traditional BSS are built to manage consumer subscriptions. They are not capable of handling the massive number of devices in IoT use cases in a cost-efficient manner. Subscription management in 5G-evolved BSS requires a high level of automation and solutions that reduce the processing footprint to onboard and manage devices, services and products. One effective approach is to expose APIs and tools that allow partners or even consumers to onboard and manage devices.

To gain efficiency and minimize management, pools of services and products can be linked to herds of devices, instead of applying individual services to device relationships, which is the common practice in BSS today. The service instances linked to herds are kept to a minimal footprint and the majority of the parameters needed for processing can be kept on specification level. This change will enable more efficient processing in BSS and reduce the number of scenarios that require mass provisioning.

Unlike traditional BSS, 5G-evolved BSS must be able to capture and create the network charging data records (charging function). This task provides the BSS with a unique opportunity to determine which charging, balance management and aggregation functions must be performed, and use this knowledge to monetize the usage of the 5G network. For instance, the BSS can monitor allowances and balances in real time, if so required by a partner agreement, or decide to postpone the rating and balance management to a near real-time asynchronous flow.

Allowing the BSS to decide the importance and risk level of each event based on agreements, Service Level Agreements (SLAs) and operator business rules makes it possible to accommodate multiple charging models simultaneously. Among other things, this approach enables real-time monitoring of individual device herds, while at the same time providing partner ratings for one or multiple involved partners in a continuous, near real-time, flow for individual device sessions.

Charging models for non-telco services

5G-evolved BSS must also support the management and monetization of services that are not traditional telco services, such as those for the IoT platform or application hosting at the edge. In the past, BSS have traditionally relied on a well-defined set of parameters provided through standardized protocols, but this approach will not be sufficient when entering the non-telco service arena. To monetize on non-telco services, the 5G-evolved BSS must have the flexibility to use previously unknown identifiers and parameters, especially in the charging and billing systems.

The usage of a non-telco service can be monetized using something as simple as a network slice identifier to determine how to aggregate and charge for a service. In other instances, a much more complex model must be used, involving multiple input parameters for each event to determine which party or parties should be charged and which charging model should be applied. Consequently, the charging and billing solution in 5G-evolved BSS must provide the flexibility to map and evaluate non-telco identifiers and other parameters at configuration time.

Multiparty charging

While traditional BSS are able to handle roaming partners and wholesale agreements, they are not equipped to handle the dramatic increase in different types of partner agreements in the 5G/IoT ecosystem. The ability to handle a wide variety of partner agreements and support the onboarding of partners and related charging models will be crucial to CSPs’ ability to monetize on expected IoT growth and avoid becoming bit-pipe wholesalers.

In the 5G/IoT ecosystem, a single event that BSS receive from the 5G core network can trigger a complex value chain that requires multiple parties to be charged or share revenue. A CSP cannot rely on traditional techniques to handle this complexity – doing so would mean postponing charging or revenue share distribution until the bill run.

To deliver up-to-date information to the relevant partners, the CSP needs BSS that can process the entire value chain as soon as any activity occurs that impacts them. This does not mean that everything must be processed in real time, but rather that events must be handled in an online asynchronous process. For example, when BSS grant consumers the right to access specific services, the event is followed up by a post-session process to calculate and distribute the charges/revenue share for the involved partners. As a result, the relevant partners have access to up-to-date information within seconds, rather than at the end of the day or at the bill run as they would in traditional BSS.

In 5G-evolved BSS, different events for the same service can have different charge or revenue share distribution. One-time fees, recurring charges or usage fees can all have different distribution rules and include one or more partners. For example, it is possible for an operator to charge a one-time fee to a consumer and keep all of the revenue, while also charging a recurring fee to the same consumer and splitting that revenue with a partner that provides the consumer device on a rental basis.

Digital BSS architecture for 5G and the IoT

Figure 3 shows the key components of Ericsson’s digital BSS architecture. The color scheme indicates the relationship between the components in this architecture and the functional ODA architecture shown in Figure 2.

The front-end channels in the customer and partner interaction layer and the BSS exposure layer are deployed as a microservice architecture to facilitate business agility, scaling and the introduction of customized solutions as per operator needs.

Further down in the stack, the architecture is based on mini services, primarily to optimize footprint, performance and latency.

Table 2 maps out the 5G evolution areas in BSS to the main functional blocks in our digital BSS architecture. Containerization, microservices and a common technology stack are common to all blocks.

Table 2: Prioritized 5G evolution areas in the main BSS functional blocks

Conclusion

The 5G network evolution presents communication service providers with the opportunity to transform themselves from traditional network developers to service enablers for 5G and the Internet of Things, and ultimately to service creators with the ability to collaborate beyond telecoms and establish lucrative digital value systems. Along the way, this journey opens up substantial new revenue streams in verticals such as industrial automation, security, health care and automotive. To successfully capitalize on this opportunity, CSPs need BSS that are evolved to manage complex value chains and support new business models.

5G-evolved BSS enable smooth collaboration between connectivity providers, service creators, partners, suppliers and others that results in the efficient creation of attractive and cost-effective services. Optimized information models and a high degree of automation are required to handle huge numbers of devices through open interfaces. Deployment in a cloud-native architecture ensures flexibility and scalability. It is important to keep the business logic, interfaces and information models of 5G-evolved BSS flexible, so they can be adjusted to suit the value chains and business models of the different industry verticals.

At Ericsson, we will continue to evolve our BSS offering to support our customers on their journeys from network developers to service enablers, from service enablers to service creators and beyond. As part of this work, we are also firmly committed to driving and contributing to relevant standards in the BSS area and participating in open source and developer communities to promote openness and interoperability.

References

1. TMA, Open Digital Architecture Project
2. Read more about CI/CD
3. Network slicing