Guy Daniels, TelecomTV (00:24):
Hello, you are watching the Telco as a platform summit part of our year-Round DSP Leaders Coverage. I'm Guy Daniels and today's discussion looks at how APIs and middleware can support vertical applications. Telcos are rallying around a common set of network APIs that can hopefully unlock value from their networks and lead to new services. But given the API sprawl that developers already face, will a new set of interfaces be welcomed and adopted? And will API gateways or a new middleware layer provide the keys to help telcos realize this opportunity? Well, to answer these questions, I'm joined on the program today by Peter Arbitter, who is SVP of Mace Magenta, API Capability exposure at Deutsche Telekom. Beth Cohen, SDN Network product Strategy for Verizon Business Group. Paul Miller, chief Technology Officer at Wind River and Petar Torre principal engineer with Intel Corporation. Hello everyone. It's really good to see you all. Thanks so much for taking part in our discussion today. First of all, I'd like to ask, what is a telco network, API and can we support this definition with any current, well-known examples? Peter, I'm going to come across to you in the role you are playing at Deutsche Telekom. Can you first of all summarize for us what a network API is?

Peter Arbitter, Deutsche Telekom (02:03):
Yeah, happy to do so. So APIs, our application programming interfaces, so they allow us to talk to our network, to our network infrastructure. And actually, and I want to be honest, I do not like that term too much because it's pretty telco centric and it's pretty inside out. So I'd rather like to describe those APIs as business APIs, but no matter, so there are two kinds of categories of these APIs. So one category allows you to get some additional information out of the network. So we sit on tons of information and with the APIs we provide you access through these information. So that's one category. And the other category allows you to get some additional functionality because we allow you to at least to certain extent, configure parts of the network. So examples for the first one would be like device location information. You get information about the location of a device directly out of the network. An example of the second category would be the wellknown slicing or quality on demand API where you can get an additional or an uplifted performance out of minute.

Guy Daniels, TelecomTV (03:27):
Thanks very much Petar. Interesting shift of emphasis there from network APIs to business APIs. Beth, let's come across to you for your views on what constitutes APIs.

Beth Cohen, Verizon Business Group (03:42):
I agree that there are network APIs, but we're finding that we have contributed quite a few APIs that are focused on, as was said, business APIs, which is APIs that our customers use to pull data about their network that they can incorporate and integrate with their own ITSM systems. And those are actually business because it's ticket information, it's performance information, it's information that it makes the information that we're providing to them more meaningful to them. And then many of our customers are taking that information and integrating it or rather correlating it with their applications to really understand what's driving their application performance. So I've been saying this for years, we really need to have a better integration of applications with network and unfortunately I think the telcos are mostly driving it. The developer community I think has little understanding of networking and so therefore kind of ignores, it just sort of happens, which of course in reality it doesn't. So I think these APIs can allow us to get to that next level where the correlation between the network performance and its impact on the applications can really be understood and I know that some of our more sophisticated customers are in fact doing that.

Guy Daniels, TelecomTV (05:22):
Great. Thanks very much. Beth, you raise a good point there about developer engagement, which has always been quite difficult for the telecom operators. Paul, let's bring you in now and your comments about network APIs and APIs within the industry.

Paul Miller, Wind River (05:38):
Yeah, it's an interesting conversation today guy. Thanks. We're one of the vendors that is underneath the hood, right? Providing infrastructure and network elements within the service provider environment. And the couple of things I'd add here is it's really important for those of us that are in that role. There's of course hundreds of vendors that contribute components into the carrier network to actually extend northbound APIs out of our systems, whether it be infrastructure or applications orchestration and automation functions, analytics elements. We're providing many of those things to service providers. But if you don't extend visibility northbound out of your systems with rich APIs, then the conversation about things like API brokers and API gateways and the way the service provider can aggregate those API functions into something that's consumable for a business purpose becomes very difficult. That's one thing. And the other thing I'd mentioned, and I think we've had this conversation already today, is that it is really centered on a business purpose, right?

(06:38):
If you can't monetize that service through some way and certainly an API broker and gateway is a way to measure that, right? And apply a monetization engine if you will underneath it. But fundamentally there needs to be core business values and the capabilities that the API is exposed. For example, if you look at connected systems, connected automobiles for example, the ability to provide access to high definition information about where vehicles are can help drive self-driving applications or advanced parking algorithms that look for empty spaces, then you've got a monetizable value, right? So at the high level you have to be able to realize an actual application that a consumer or business is interested in and then at the lower layers you have to expose all those services via APIs and continuously grow that API set as the new services are launched into the network.

Guy Daniels, TelecomTV (07:30):
Yeah, absolutely Paul. And then you mentioned the business case there, which brings us very nicely onto our next question, which is how can telcos use and monetize these APIs? And also equally, how can developers use them to enhance their applications and services? Petar, let's come across to you. What's your view here from what you are seeing with the developer community and the interest to them?

Petar Torre, Intel Corporation (07:57):
So there are two sides to it, two sides to it. One is exposing APIs so that those valuable network IT and other assets that we will figure out as we go. Now when the priority is set on that and hopefully culturally we'll be able to execute on it, that this will be the exposure part and we will look into how exactly this gets exposed. There are different mechanisms, we'll touch on it in this panel. Now on the developer side, it is these developers, we need to differentiate them as per end customers. And those can be normally in communication, service, product solutions, they come through print integrated solutions that they're going to smaller customers because amount of integration and customization is super limited. So something that is prepackaged for consumer, small office, home office, small and medium businesses is one type of developer ecosystems and use cases completely different.

(09:03):
One is various custom integration for huge enterprise verticals and government and they have their own ecosystems. Now what does not make it easier is that all of that is very fragmented in those major categories. But then per use case, when we from Intl site develop software frameworks and those that top optimize and run best on different harder options underneath selected during the runtime, we have a lot of adoption for that where we create value for those developers. Now you already mentioned at the beginning in the intro that they do have a lot of different API categories as option, and then Beth was mentioning that they don't comprehend the way how the telcos vertical in general we were trying to get across to them. Now there are good initiatives with the right design principles that have focused on delivering developer friendly. So something that is easy to adopt ideally provides the value so that it's even being discussed.

(10:17):
But the hurdle to adoption is not like in the past when from comms vertical, we would go and try to develop the APIs, but what was coming across with desired stated goal of interoperability, I mean in reality this was not even within telco specialist developers interoperable and definitely not with some webscale developers. So we'll need to as we go down that path beyond exposing APIs towards consuming them, this includes ecosystem enablement of those very fragmented ecosystems. So whoever has good programs towards that. And from Intel side, I would claim we have decent ones because we do it over decades plus they will be mapping between a lot of operators that we have. And ideally when we enable a lot of developers, we need to figure out how this mapping works. It can be to every connection. So there will be some sort of aggregation in between. And even when all of that is done still we to go to market program so that eventually something that is enabled, stitched together from APIs still enabled use case that brings value still somebody needs to do the go to market at the end of it.

Guy Daniels, TelecomTV (11:34):
Thanks very much Petar for that perspective. You all want to come into this question. So let me start with Paul and Paul, let's come back to this whole point of monetization and what's in it for the telcos and the developers.

Paul Miller, Wind River (11:46):
Thanks guy. I'll try to be quick. Three basic points. One is that to be attractive to developers, one major component of that is the tool chain that a developer consumes a portion of our business obviously feeds as I mentioned a moment ago, equipment and capabilities into the service provider, but we also directly sell to developers at a variety of different customers and we created a completely cloud native DevSecOps tool chain. And this helps a software developer manage everything from requirements definition to coding in an IDE to building the final software, product testing digital twin capabilities. This is the modern software development environment that a developer lives in and you need the modularity and the libraries to be able to bring in the APIs that are published by the service provider into this environment so that a software developer can easily consume it if it's not easily consumable.

(12:39):
It creates a natural friction for a developer or company to build applications that leverage the service provider's APIs. The second quote I talked to is API revision management, right? As you go from V one of an API to V two, if you're really good at maintaining backwards capabilities and those APIs as they evolve, you're very attractive to a developer. If however you break that as you move forward, that becomes very painful and costly for a company and a developer to deal with. And then the third piece, which is probably pretty obvious, but if we look at things like Linux Foundation's Cera project, it's actually really important to have commonality across service providers for similar network services and similar APIs. And the reason for that is obviously if you're a developer and you build an application for one network and say Verizon or Deutsche Telecom, and then you try to move it to the other carrier and you can't, then you have to rebuild the entire application and API services. So having commonality across the service providers through things like the Cera project are great ways to solve that problem.

Guy Daniels, TelecomTV (13:42):
Thanks Paul. Great points there to be aware of. Peter, let me come across to you then I go to Beth, but Peter, your thoughts on this?

Peter Arbitter, Deutsche Telekom (13:49):
Yeah, let me share with you that, I mean this is not new to the telco industry. I mean APIs have been there around for almost 15, 15, 20 years looking at what happened with CPOs. And from a telco perspective, we just weren't capable to really bring these capabilities to the market because at the end of the day we did not understand the developer play, let's be honest to ourselves. And that's mainly because we as telcos are typically regional or national players while this developer market is a global one. And so I believe that now a few things have changed that we have better understood and what we need to do. And Paul is absolutely right. We have to ensure that is absolutely easy and interop needs to be given that this is not a Deutsche Telecom specific API or Verizon specific API, it has to follow a somehow global standard. And these things have changed, but we have a legacy which unfortunately wasn't that successful,

Guy Daniels, TelecomTV (14:56):
Very honest Peter, but so true of what we've seen over the past decade or so. Beth, let's get your perspective as well.

Beth Cohen, Verizon Business Group (15:05):
So I'll kind of build on what the others have said, which is we don't understand the developer community. We've never been able to understand that, but we've also not been able to convey to them the importance of the network for their applications to work, particularly as applications have moved out into the cloud and then back out to the edge, the network is more important than ever and it behooves us to step up our work with the developer community. I know Paul mentioned camera, but there's also Nefi and there's other projects within LFN that are focused on more collaboration with the developer community, with infrastructure, the CSPs as well. nefi is sponsored by CSP, so I think we're going in the right direction, but nothing is easy and nothing is going to be fast, but I think that we're going to see more use of APIs.

(16:19):
I mean we're seeing it with our enterprise customers, more use of APIs on the operations side of things because I think there's more bang for the buck or rather quicker bang for the buck, which is when you can coordinate those, correlate those tickets that you're getting from the service provider with the tickets that you're getting from your user community complaining about the poor performance of the application. Well hey, that's a super useful use case that you can act on right away. So it's worth spending the time to do the work to integrate those and correlate those two systems together.

Guy Daniels, TelecomTV (17:05):
Thanks very much Beth. Well let's develop this thread about how we can help with the engagement effort. Now we're speaking with the GSMA later today in the summit about the open gateway initiative, but perhaps we can touch on that now. And also some of the other initiatives we've already heard mentioned a few of them there that are in place to help telcos with APIs. Let's find out what progress they're making. Peter, perhaps we could start by hearing from you.

Peter Arbitter, Deutsche Telekom (17:32):
Yeah, there's a lot of going on. I mean you just mentioned GSMA open gateway. I mean that was really a great initiative which really also helped us to drive that governance forward and to somehow sort out the go-to market travels and we are seeing quite some momentum at NA WC with the local champion activities all around GSMA open gateway. So that was really successful, but for me even more important had been kamara because that for me also showed a different mindset because this now is an open source foundation project and with that it's not about that everyone thinks about what could be done and should be done. This is really hands-on this is whenever someone has an idea, there's no need to wait, just get the act together and go with the API. And this is why we see more than 50 APIs, which have been described in a lot of momentum and we see more than 300 companies being really active within these first two years that kamara on this existing and also then the forum where the operate API would happen. So a lot of momentum and I believe that this one helps us really driving that topic forward.

Guy Daniels, TelecomTV (19:01):
Yeah, thanks very much Peter. And there has been a lot of momentum recently from various industry bodies. peta, let's come across to you because I know you are closely involved with Kamara as well.

Petar Torre, Intel Corporation (19:11):
So indeed I'm Intel representative into it from before it got started. And also just to share perspective, I was also representative to some of the previous incarnations of industry attempts to go after that problem statement. The huge difference now is that first there is urgency on this and this is really properly resourced, like number of mentioned companies, a number of experts over there. We have not had something like that in the past and this is obviously a huge difference, the understanding and design principles to get this to be developer friendly and easy to consume. We didn't have this type of things in other previous attempts either. And what is really great to see is how complimentary different communities can find themselves in their efforts in terms of who is doing the API category definitions towards developers. What EM forum is doing what GSMA open gateway initiative with the gateway specs and the certification for that is doing this all somehow meaningful. It fits together to get towards the exposure part. What we will need to all work to figure out is how to get the adoption of that also.

Guy Daniels, TelecomTV (20:32):
Yeah, a lot of hard work has been done, but as you say, there's still a lot more to do. Paul, let's bring you into the conversation at this point and your thoughts about the industry groups and how they're contributing.

Paul Miller, Wind River (20:47):
I certainly want to echo the positive comments about Linux Foundation's Chimera project. The description is accurate, right? There's a GI repo, there's actual code being developed and that will drive further adoption of the technologies versus just creating standards or speculation as to what should be done. So that's real action, right? From a software company perspective. The other thing I'd say is that it's really important to recognize how these things will be used. If we look at, for example, in February the automotive edge computing consortium came out and announced a partnership with Project Cera, and that's really about connected vehicle services. So here's an example of a use case and you really need that open source consortia Camaro working to expose the APIs so that you can realize connected vehicle services. And that's interesting to us because a portion of our businesses in the automotive sector, our parent company is there as well, and we provide some of the infrastructure used for next generation software-defined vehicles and connected vehicles are a key part of the future of the automotive sector, whether you're looking at over the air update, compute, offload into the carrier network, cellular V two X applications like many service providers are pursuing.

(21:59):
This is the first time that we've seen service providers coming together with the automotive industry to generate new use cases and revenue. All of that is enabled by API access to the services of information and controls that are within the carrier network. So seeing project Amira happen and seeing some of these use cases come about through electrified modern self-driving vehicles, I think we're finally at the cusp of seeing API adoption really happen.

Guy Daniels, TelecomTV (22:24):
Good to hear, Paul. Thanks for sharing that. Beth, let's come across to you for your additional thoughts.

Beth Cohen, Verizon Business Group (22:31):
I just wanted a couple thoughts. One is to follow up with Paul, the automotive industry and the connected auto is clearly a huge use case, which the APIs need to be fully integrated with those applications and there's a real business opportunity there. Increasingly, cars are, some of the car companies are treating a car like a subscription, so it's a subscription model instead of you buy a car and you keep it for 15 years. So that's going to require a whole different way of thinking about those applications that are sitting in the car and the network connectivity, which is of course a paramount interest. And so the fine grain, for example, to make car auto drive self-driving car, you need very precise geo coordinates. What's currently out there is not good enough. It has to be if going to have a car park itself, it needs to be very precise.

(23:50):
And so I see there's a lot of opportunity to have the code interact more. I'm thinking there are other GSMA tends to be more standards oriented, but NEFI is code, kymera is code MEF is producing APIs that are code as is of course TM forum. So ironically the standards bodies and the open source community, which I've been an advocate that they really need to work together for APIs to really take off and be adopted by the industry. The coordination and working together needs to happen even more than it already is. And the good news is that the standards bodies and the open source communities do understand that they're really two sides of the same coin and really do need to work together to further the technology to build on these use cases and these business cases that are getting developed.

Peter Arbitter, Deutsche Telekom (25:02):
Great.

Guy Daniels, TelecomTV (25:02):
Thanks very much for sharing that. Beth. I had like to move on to an approach where seeing a little bit more of this year, and that's how a separate middleware layer can encourage and simplify the deployment of vertical applications and systems at scale. Now, does such an approach work alongside API gateways or is it a replacement for gateways? How does this all fit together? Peter, perhaps we could come across to you for tapping into your expertise here.

Peter Arbitter, Deutsche Telekom (25:38):
Yeah, so this is absolutely spot on and it needs to sit on top of the existing gateways because there are some additional challenges we need to solve. And let's pick one of those where it becomes really obvious. This is the consent management. So there are APIs where you need to get the consent of the user and unfortunately this is not standardized across the globe. So based on the regulation within the country, you might run into explicit consent or legitimate interest or any kind of solution which you need to ensure that you have. And this has to be handled by that additional layer, by that middle layer you talk about. Because at the end of the day, since there will set an application on top of whatever we talk about, this needs to roll through to the application and we need to ensure that this can be revoked and then it needs to walk back its entire way. And we also need to consider what if that device is roaming in a different country and the consent regulation in the own country is different to that foreign country. So there's a lot of complexity and that describes the need of such a middle layer, and that was just one function, not talking about all the others like the advanced billing, like the identity, the additional security things you need to ensure. So there's absolutely a need of that additional.

Guy Daniels, TelecomTV (27:21):
Great, thanks, Peter. Very interesting one for us to follow in more detail on telecom TV as the year progresses. I think I have a final question I'd like to put to all of you because we've been spending a lot of time looking at collaboration and gateways and amalgamating various APIs and approaches. Why can't a telco simply create and expose a set of APIs and offer direct access to developers? Why do we need to bridge some kind of bridge to network functionality through gateways? And Paul, perhaps I could put that one to you. Why can't individual telcos just do it themselves and go direct?

Paul Miller, Wind River (28:01):
Well, certainly they can, but then you have some complexities that arise from that. Really the function of the gateway and broker that it sit in line with the APIs is multifold. Many of the things that Peter described are accurate and those are stateful interactions and managements of the underlying APIs. In many ways, the underlying APIs in the network are quite unintelligent, right? If you ask for some data, it will provide it. If you look to engage a control to configure, say a network slice, it will take action on that. The question is, does that user have permission to do that? Is there a restriction in the network that would prevent that from happening right now? Should it be visible? Is it private data that somebody's getting access to or you look at the country and roaming boundary problems? What that means is that you really have in this broker and middleware and gateway kind of functionality, if you group that upper layer of functionality together, you have management of the APIs, you have throttling, you have access control, you have aggregation.

(29:01):
In fact, the API that a network provider, a service provider may want to extend externally to a developer that API may trigger multiple APIs being exercised inside the network and the management and successful stateful closure of those API events needs to be completed before success is returned to that developer from that single aggregated API call. Otherwise, you have the exposure of thousands of internal APIs from the service provider network directly to a developer. And of course from a security and feasibility standpoint, that's a non-starter. So the functionality we're talking about, the gateway, the broker management, permissions control, all of these things are very, very important to offer an API service that's truly consumable by external companies.

Guy Daniels, TelecomTV (29:48):
Great, thanks Paul. I can start to see why this might not be a desirable approach to take. Now I know you all want to come in on this final question. So let me start with Beth and ask you about the need for this collaborative kind of approach.

Beth Cohen, Verizon Business Group (30:02):
We in fact do have a portal where we share APIs and as others have said, we're not software companies. Yes, we can write these APIs and we do, but we don't fundamentally understand how our users are using the APIs. And so if you look at our portal, it has a bunch of APIs that are really focused on operations. So again, pulling information about the customer's network performance. And then we have a set related to some of our business related to automotive and telematics, but we really don't expose our internal APIs and pulse spot on to manage the network. We don't allow our customers to manage our network and we don't allow them to have access to any of that. That's all private. All those management layers are private. And so we're never going to expose them to our customers. So we have to be very careful about what gets exposed and what doesn't.

(31:18):
And that middle layer is essential to do that because we haven't talked much about it, but security is a huge component and as network integration with security is progressing a pace, I will say our messaging to our customers is, Hey, don't just buy pipes. You have to think about the security of the pipes you're buying and how those are secured. And there's APIs related to security as well. So the complexity grows pretty exponentially. So yeah, the middle layer has to be used to simplify that. I mean the whole purpose of APIs is to simplify things and somehow we haven't made it any easier for anybody to use them. So yeah, middle layer is essential.

Guy Daniels, TelecomTV (32:17):
Yeah, that's telecoms for you Beth, isn't it? We don't like to do things simply. Thanks very much Beth Petar, let's come down to you for your thoughts on this. So

Petar Torre, Intel Corporation (32:29):
To compliment this, but also from a view on how it gets even further complicated is there are operators running in 20 plus countries that each of those networks is a special design, like a snowflake on its own and it is very non-practical if we ask developers to go and have anything to do with that directly. Okay? So all of that gets obstructed. Common APIs get exposed and they will go in two broad categories like Peter was saying. One is pretty much getting the call, querying the information and sending the information back that is easier to implement than something which is session-based, create get notification, tear down that across different network domains and generations and country implementations. It's already serious integration thing to do and as its own, it needs to be normally separate platform that has all the required logic in that it comes either from the existing vendor of all the other elements in the network or from a third party that is specialist and can still pull it through and has all the integration partners to get it done.

(33:47):
So that's how we get it simpler, exposed out. And then still once it's exposed, we have so many countries and then operators per country. And if you make it technically super easy, you still have all the commercial and legal terms to sort out going to developers, which is why even when all of that gets done, there will be aggregation channels and marketplaces as a way how this big number of operators is going to connect with big number of application vendors or enterprises implementing all those use cases. So there will be additional level of integration that all still needs to be implemented.

Guy Daniels, TelecomTV (34:40):
Great. Thanks for explanation, peta. We really start to see the complexity that's involved here. Now Peter, let's come across to you for your input on this question.

Peter Arbitter, Deutsche Telekom (34:51):
Yeah, I'm still Polish as you can read on my shirt. I believe that they'll overcome the technical challenges. I know that these are complex, but I see these ways out. I like to build on what Patron has said. I mean the technical thing is the one side, the commercial thing is the other side. And this is why there are some important and larger telcos sitting together and thinking about how to do that application. Because at the end of the day, we also want to ensure that it's from a commercial perspective, easy to consume these APIs and the developer could just look at a country like Germany, you have three, but you also need to consider the virtual network operators where you have to have at least look at four or five additional ones to get the full coverage of the country. So that means that you have to come up with 7, 8, 9 contracts. You have to then have in place for a developer to get access to the APIs across that one single country. But I believe that we have understood what we need to do and we are working on this one, and this is why I'm really positive that the middleware layer is needed, but we are working on this

Guy Daniels, TelecomTV (36:14):
Great Peter, and that's where you're hashtag bullish and I think we all should be hashtag bullish on this subject. A lot of work to do, but the rewards are rather great. Paul, I'm going to come across to you for some additional thoughts to round out this show.

Paul Miller, Wind River (36:32):
Yeah, I think everybody's done a great job of exposing some of the issues. There's certainly complexities when we talk about these API middleware layers and the functionality they need to have. Imagine in your mind these APIs being exposed and a customer calling them a thousand times a second. How do you deal with that? How do you manage the rate of use, right? What if you have 20 customers and they aggregate to a thousand times a second? Does that cause a problem in the network? And how do you have a policy to throttle down the use of that across those different customers with the different commercial contracts that Peter just mentioned? How are you managing monetization of those API calls and how are you doing that in a way that produces profit for the business but doesn't create undue complexity with respect to the subscriber to the API service? So you can see when all this is going on that it is unfortunately a pretty complex problem both from a business and technology perspective, but I also agree with Peter, I think we have enough experience now that we understand actually how to do this and with some of the companies involved, we directly interact with the developer community and that helps close some of the gap. So I am also quite bullish that we're heading in the right direction and we'll solve the problems here.

Guy Daniels, TelecomTV (37:44):
Good to hear. Thanks very much, Paul. Well, we must leave it there and I'm sure we will continue to debate this topic during the rest of the summit. For now, thank you all for taking part in our discussion. If you're watching this on day two of our telco as a platform summit, then please do send us your questions and we'll answer as many of them as we can in our live q and a show, which is coming up later. The full schedule of programs and speakers can be found on the telecom TV website, and that's where you will also find the q and a form and our poll question. Please do complete the poll if you can, but now though, thank you for watching and goodbye.