Aside from network deployment and operational challenges the key question in CSP agenda is how 5G will help maintain and grow their present revenue generation ability. In finding new ways to make it easier to establish business to business relationships and achieve a win-win in revenue generation we have seen the emergence of the GSMA Open Gateway API initiative and the associated Open Linux Foundation’s Camara Project creating new cross-Telco API standards; The initiative is gaining significant momentum with 240 organizations currently signed up and increasing daily.

To understand the landscape a little better it is useful to look at the business problem, neatly laid out in a recent blog by Don Alusha from ABI Research. In his blog 5G Innovation Maturity Strategies for CSPs: Seizing High-Risk, Long-Term Growth in the Telecom Industry  he highlights:

• CSPs revenue (75% to 80%) is dependent on their consumer-centric business.
• Saturating subscriber growth leads to additional revenues but revenue growth in not robust.
• 5G brings potential to develop new business lines based on Slicing, Private networks, IOT, Data exposure.

The business imperative is for CSPs to capture new growth from untapped 5G potential. Looking at one aspect of this, data exposure, which we know has been a recurring theme. However, its realization and commercialization has had little success. To repeat history would be unwise, so it is better to review the key challenges faced; in overall terms it may be simply put that the telecom environment is not a greenfield site – it is a real mix of systems – some of which, once operational, the network teams would rather leave alone.

So what were the challenges before, and what can we learn?

#1 Bridging the technical divide

The data assets (e.g. subscriber profile, device information, session & policy data, location) are distributed across organizational silos; Network operations, IT, Customer care, etc. Each with its own technical attributes (interfaces, protocols, information management, etc. and software solution mix).

At a fundamental level for Data Exposure to have practical use these data sets need to be seamlessly accessed and harmonized so that bespoke applications may be able to draw and provide insights and information from them.

#2 Bridging the operational divide

The stakeholders for each of the silos are responsible for the performance of their function. Understandably, their priority is keeping their function in service and secure, meeting their SLA commitments. As such, interfacing with other silos takes a lower priority on their agenda, especially if the impacts and ownership of such integrations is unclear.

For instance, if an application required information from Customer care and the Network operations.

• Customer care would be concerned on the secure handling of user specific data, right to access such data (governed by GDPR or data security rules) and leading to the potential risk of data breach.
• Network operations would be concerned about secure access to its systems in service. Potential to disrupt service, exposing the network operations to additional load and resiliency concern. Any data exposure query may have separate response time requirements which may be beyond the designed performance limits.

Direct external access for data exposure probably won’t pass operationally – what is needed is an abstraction layer / platform / gateway providing the northbound API but internalizing all of the interlocks needed to the source data systems.

#3 Uniformity of service

The data exposure customer external to the CSP has to invest in implementing the application that integrates with the CSP to fulfil it’s use case. In so doing they need to meet the CSPs API specifications.

The challenge, before, is that the enterprise may integrate with multiple CSPs for the same use case, as they may own subscriptions across them. However, if each CSP exposes a different service API the enterprise would need to invest in the creation and upkeep of multiple CSP specific implementations making things operationally complex and expensive, i.e. not reusable nor scalable.

#4 Network security

Communication networks are strategic targets or national importance. Enabling access to data assets requires CSPs to put in place a security framework that is able to;

• Administrator access control to the API suite
• Protect each system through independent secure access.
• Secure access to exposed services
• Granular access control to a specific API

The above needs to be automated to streamline the interaction between the enterprise and the CSP.

#5 Scalability

Cloud-native is an integral part CSP infrastructure to build highly scalable networks. This aligns well with exposure requirements enabling CSPs to adopt a secure and efficient deployment. To provide the range across the backend systems and integrate multiple data sources quickly a modular, cloud native architecture us needed so that the distinct use cases may be deployed as independent containers each scaled separately based on demand.

In meeting these challenges should not be case where a new API is bolted on to an older system; that will simply preserve data silos & fragmentation and not enable the very business case the new thinking on data exposure is developing. In essence it needs an API distribution and composition platform.