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.
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.