James Pearce, TelecomTV:
I'm delighted to be joined today by Sameh Talal, who is going to talk us through network APIs in action. Sameh, over to you.

Sameh Talal, Ericsson:
Thank you. We have noticed that CSPs are having problems with monetising their mobile broadband. Mobile broadband revenues have been stagnating for a while, which led us to think about how we can open up some new use cases for them to monetise beyond mobile broadband. That is where APIs come in handy. It is a standard, and CSPs can implement it with anyone. It opens up their network intelligence towards the external world, so they can open up to developers, applications, enterprises, and even their own internal developers, enabling new use cases for their customers and for enterprises.

Sameh Talal, Ericsson:
We have also identified three groups of use cases that most CSPs are asking us about. The first is fraud detection and protection. The second is fixed wireless access mobility monetisation and control. The third is a group of use cases that are QoD-dependent — that is, quality-on-demand dependent. But let us dig into the first one, fraud detection and prevention, because that is the top priority. In some countries, banks are actually liable for money lost from their customers' bank accounts, so they try to make transactions as safe as possible. They try to identify fraud as quickly as possible and stop transactions if something appears to be wrong. What we are doing here is this: a bank has its own IT systems and holds the phone number for each customer. When a transaction occurs — perhaps from a non-standard location, or involving an unusually large sum — the bank initiates an API call towards the CSP, using the telephone number as a key. That is the only action the bank needs to take.

Sameh Talal, Ericsson:
The CSP then carries out a number of checks. It identifies whether the subscriber is on an incoming call. It checks whether the call has been forwarded. It checks whether the device is roaming and reachable. It checks whether the device has been swapped recently. It checks whether the SIM has been swapped recently. It checks whether the subscriber is in a specific location. It can also authenticate the subscriber using their phone number. Each of these factors can indicate fraud. The results are returned in a single message to the bank, containing all the information requested. The bank then takes a decision: if the transaction looks fraudulent, it is stopped, and an SMS is sent to the customer explaining that the transaction has been blocked because it may be a scam. If the customer initiated the transaction legitimately, they can call the bank back and the transaction can be allowed through. This use case does have two main challenges. If a bank wants to implement it across a country, it needs integration with every CSP, because the bank does not know which CSP each customer belongs to. That integration with every individual CSP is cumbersome. An aggregated layer between the bank and the CSPs can address this.

Sameh Talal, Ericsson:
The second use case, which we consider a low-hanging fruit, is fixed wireless access mobility monetisation and control. When a customer has a fixed wireless access CPE at home with a large bandwidth allocation, they may be tempted to move it around and treat it like a mobile device. CSPs need to manage this, because their networks have not been dimensioned for that kind of usage. The simplest approach is for the CSP to cut off the CPE once it moves outside its designated area — but that does not generate any new revenue. A second scenario is to monetise that movement: once the CPE moves outside its designated area, the CSP detects this and sends the customer an SMS offering them the option to purchase a multi-location subscription via a portal. The third scenario is the reverse: prioritising premium mobile broadband subscribers over misbehaving fixed wireless access CPEs. For example, if a customer leaves their CPE at home downloading content while they are at work, that is their right — but if the nearby cell is approaching congestion and there are premium mobile broadband subscribers generating revenue for the CSP, the CPE can be throttled until congestion clears, at which point normal service is restored.

Sameh Talal, Ericsson:
The third use case is a group of use cases built around the quality-on-demand API. In short, QoD provides a higher bitrate for a specific subscriber for a defined period of time. There are several ways to monetise this. The first is through broadcasting at venues. At a live match, for example, multiple cameras may be in use but only one is live at any given time. Those cameras are equipped with 5G modems, and the broadcaster requests a specific bitrate for the event. The CSP provides that bitrate, and when a camera goes on air it receives the full bitrate allocation; when it goes off air and another camera takes over, the bitrate is redistributed accordingly. The same model applies to event venues, points of sale, and merchandisers. It can also work for consumers: an influencer attending an event, for instance, can subscribe in advance for a premium connection for the duration of the event, enabling them to upload content without interruption. For regular subscribers who are active at events, the CSP can identify their location, determine that they are at the venue, and push a notification offering them the option to purchase a similar pass. So that is how APIs can generate new revenues for CSPs.

James Pearce, TelecomTV:
It is really exciting stuff, Sameh. Thank you for joining us.

Sameh Talal, Ericsson:
Thank you.