GSMA Open Gateway API initiative and the associated Open Linux Foundation’s Camara Project creating new cross-Telco API standards; the Open API initiative provides a new approach to connecting business and enterprise into real time network and context data. The common approach adopted benefits both developer and telco with the underlying use cases enabling the discovery of a combination of data about the user, device and network combined with current context information about access and to establish authorization or to engage in additional services such as increasing network capacity dynamically. These are core use cases which drive to a more connected, agile network and service experience.

That said, new API implementations also need to comply with the telco grade environments that exist today – in terms of data protection, access restriction, security protection, scale, and efficiency. Looking at it from an individual perspective a user will have both data and voice connection with the network and perhaps 5-10 active policies (in 5G this may extend to 20). An IoT device will have a data connection and perhaps 1-2 policies. The complexity comes from scale; in the case of users it is the number of policies and devices that may be associated to a person, and for IoT it will be the sheer number of devices. As an added complexity discovering where the data to respond to queries may be stored (network data centre, cloud, hybrid) becomes an issue in distributed environments.

In design terms the challenge is frequently abstracted into an API gateway to map from external to internal.  It is convenient to think about API gateway as a single external event mapped and responded to by a single internal event, but that is rarely, if ever, the case. A single external event may trigger multiple internal events  to different internal systems– the results of which would have to composed, refactored and, potentially encoded into a response. In some cases, making an internal query may also result in wider set of data which can be used to answer further external queries more quickly – e.g. if you are asking for SIM identification perhaps the system will retrieve and cache data on billing/location etc. to respond to a potential follow up queries. A smart implementation will cache the additional data, providing an ageing process to manage its integrity, to avoid unnecessary ‘dips’ into subsystems for additional queries.

In any API access consideration should also be given to a framework for notification, to track when individual or complex data items have been changed. This is an inherent part of the 3GPP framework for service based interfaces. In part Camara has adopted this e.g. for Quality on Demand, but in our view there is a additional scope for notification extensions for other use cases.

Additional considerations & extensions in control-based use cases (e.g. QOD, network on demand) are also useful for authorization, billing, callback and reporting, e.g. is it authorization for a group, location, which additional services are available etc.

These implementation points may be familiar to vendor software teams who have been adapting interfaces – as the telecom infrastructure of network and BSS systems is a mixture of old, new and ‘you break it, you bought it’ type environment – where internal systems must not be overloaded i.e. servicing a new set of commands while trying to do the task they were originally intended for. Additionally in terms of security protection they data they provide may already be governed by strict rules for encoding and protection.

It is against this backdrop that we, as Enea, are presenting our product options, both in support of a new multivendor environment but also with extensive experience of telecom system interfaces, cloud native scale and data management. The core parts of this are a data management engine, the Enea Stratum, provide the ability to map data attributes into more complex forms, to provide different views/access paths for different applications of data, to distribute data closer to requesting applications, the notification framework etc.

The value that Enea also brings is in knowledge and flexibility on APIs and protocols. On the front end the API is the new definition but on the back end the data lives in older telecom systems and any API gateway solution needs to conform to these existing systems, which are often a mix of LDAP, Diameter or REST interfaces. The experience of protocol implementation is also combined with the agility of the platform to handle the variances of authentication, access control and load restrictions.

The combination of flexible API and data mapping & storage and general notification handling provide the real basis for a production based system for engaging applications across multiple user, IoT and potentially inter-telecom environments.

Don’t be surprised that you need a data strategy – embrace it and be Enea Ready. Talk to Enea today and we can tell you more on how we have helped world leading Telcos in their digital transformation, future proofing their data management strategies.