Guy Daniels, TelecomTV (00:24):
Welcome back to the Telco as a platform summit, part of our DSP leaders coverage. A time now for our live q and a show. I'm Guy Daniels and this is the second of two q and a shows. It's your final chance to ask questions on APIs, gateways, platform services as a service models and so on. It's an extensive and somewhat complex topic as we found out earlier today when we held a panel discussion on how APIs and middleware can support vertical applications. Now, we've already received a number of questions from you, but if you haven't yet sent us one, then please do so now and use the q and a form that you can find on the website. Let's now meet our guests who are going to help answer your questions and joining us live on the program today are 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. Thanks so much for returning for this q and a show. Let's get straight to our first audience question and this viewer asks, which is better between these two options and why an operator specific API marketplace or a telco industry level API marketplace? Paul, can I come across to you for your views first?

Paul Miller, Wind River (02:09):
Sure, thanks guy. That's actually a pretty interesting question, very through question from the audience. When you look at the operator specific APIs, the attraction of that path is it allows the service provider to innovate and move at their own speed. If they want to bring certain services to the market, they're able to do that under their own, their own discretion and with a set of capabilities that they define. The issue with it though, when you look at the attraction of telco industry APIs, now you have commonality across service providers the ability to roam services between service providers and especially important for a developer if they build an application leveraging APIs, that application is portable to multiple service providers globally and in fact they get to write their application once and monetize it across multiple service providers. So from that perspective, I tend to prefer the more industry level standardized APIs because it's going to drive more adoption in the developer community, but it does create certain challenges because then the velocity of those industry standard APIs as a standardized activity has to stay in front so that the operator's not restricted by that common PI set that's available blocking them from bringing new services to market or new API capabilities to market.

(03:23)
That also implies there needs to be some flexibility in the API definition that allows a service provider to create custom payloads and that sort of thing. So very interesting question, but I fall on the side of industry standard APIs.

Guy Daniels, TelecomTV (03:36):
Great, thanks very much Paul. And yes, it's an interesting choice, isn't it, and lots of factors to consider there. Beth, what about you? Do you favor one approach over the other at Verizon or are you looking at both?

Beth Cohen, Verizon (03:50):
In fact, we've actually implemented both and as Paul mentions, there's pluses and minuses to each approach and what we have found, I think I'd say we probably lean more towards supporting industry standards, but there's a much longer lead time and so it tends to lag in terms of our ability to bring it to market. And so we've also done some custom APIs that we expose to our customers. We have a portal that's available for customers to come in and use these APIs, and I think there's always going to be a place for both to a certain extent because there's some things that we do that are sort of special sauce, if you will, that don't make sense to put them out as industry standards, but I think those are in the minority and that the vast majority should in fact be industry standards. Now of course there's the question of which industry, which industry standard organization to go with.

(05:06)
We've been active mostly with TM Forum and have published several dozen APIs in TM forum. However, I know we're also active with math as well, so that's another factor that takes we have to take into consideration. I mean the number of people that are working in the standards out of Verizon, yes, we're a big company, but the number of people actually working in the standards in the open source community is relatively limited, and so we don't want to spread ourselves too thin across those activities. So I personally am more active in the open source side of things as opposed to the a p standards side of things, but there's place for everything.

Guy Daniels, TelecomTV (06:02):
Great. Thanks very much Beth. And as you said, there were a lot of organizations working at different aspects of this, right. Let's go to our next question because we are getting quite a lot of questions coming through. So this next question says, given the different components that are built into various platforms, how will CSPs distinguish themselves from the many platforms that are out there? Petar, can I come across to you for some thoughts on this one?

Petar Torre, Intel (06:36):
Thanks. Yes. So there are few views here. So as developer, I mean for building prototype applications there is always the question for certain category of functionality which APIs to use, and from Intel side, when we release different software development kits, then we always go through the same questions with developers because they ask that it's unavoidable. Now here from the telco service APIs, there will be some that are clearly differentiating. For example, if you have existing session on the current public network, either you can ask for certain quality parameters there or you cannot. I mean this is not replaceable with another, I don't know, network or how to get to that. So there will be some that are easier to argue the usage of it. There will be some that have to be better explained. Like for example, and this is fair question that was asked by somebody commenting on one of the posts on Kamara threats on LinkedIn, like, okay, I can get device location information from many different sources, so how is this one really differentiating?

(07:56)
And there will be per API clear answers per particular clear use cases on what exactly the differentiation is. Sometimes it'll be easier, sometimes it'll be more to be discussed over there and more to be proven, but that's pretty much the process that goes per API category. Now when we answer enough of those per the category, then having from trusted telecommunications company provided a longer list of such APIs that can be accessed by having the same legal and commercial contract and same authentication and same API style, then this sounds like much better offering than what was said in the question. Like many different platforms, each of them having their own way of doing it.

Guy Daniels, TelecomTV (09:00):
Yeah, thanks Petar. Thanks very much for explaining that and giving your views on, that's great. And Beth, did you want to come in as well with some thoughts on this one?

Beth Cohen, Verizon (09:07):
I did. I think we overlooked the fact that there's actually multiple different types of APIs that have different functions. And I'll use an example, we have something called the digital enablement platform, which is a set of APIs that are specifically designed to work to be used by our customers to integrate with their ITSM systems. So these APIs essentially expose the data lakes associated with their services, their network services that they're buying from us and so that they can incorporate information about their network's behavior. But it also incorporates a lot of operational API type activities like ticket coordination and the ability to interface allow our customers to interface with their applications. So event correlation and those types of things. Those are very different types of APIs than are the type that are used like in math where the APIs are designed specifically for telcos to peer and the telcos to peer with other telcos or peer with cloud service providers. So those are to a certain extent orthogonal and much more really require standards than the APIs that we use for our customers. And we do provide some standard APIs for our customers as well, but mostly these APIs are designed to interface with our own internal systems and make it easier for our customers to consume that information and that those just don't lend themselves to standards in the same way.

Guy Daniels, TelecomTV (11:13):
Great. Thanks very much Beth. And yeah, I guess the view here is also asking service differentiation. It's always been front and center of telcos and if we're providing a common platform approach, how does that happen? Paul, did you want to come into this question as well?

Paul Miller, Wind River (11:29):
Yeah, it's funny you mentioned that because that is what caught my interest in the question. The idea that CSPs can distinguish themselves from the other API platforms that are available out there. I think the way that question was asked was a little bit different. It's not the CSPs distinguishing themselves amongst each other, it's against the other platforms that are out there. And that is a really good question because if you look at, there's just an absolute ton of API services out there and it's worth noting that the CSPs have the ability to connect an API user, a developer application builder with actual devices. So if you think about the automotive sector with over the air update, compute offload and CV two X, these APIs extended out of a service provider are unique to a service provider. There are a lot of edge devices that are actually connected into the 4G and 5G network that only a service provider can provide access to.

(12:24)
And so that data and networking services that goes with access to those edge systems can expand to private 5G and industry 4.0 and medical systems that is very unique capability in the service provider. So as you look at differentiation in comparison against other API services that are out there, you can build applications on top of A CSP or DSP that are impossible to build through other API services. So I do believe there's a tremendous amount of differentiation that will come out from that. On the more nuanced question about between CSPs, you're going to see CSPs that have certain focuses, right? That even though an API exists doesn't mean that it's richly supported by a particular CSP. So if you're looking to build an automotive application or an iot application, you may find that a particular service provider differentiates themselves with respect to the rich support of those set of API services.

Guy Daniels, TelecomTV (13:17):
Yeah, very clear. Thanks very much Paul. And Beth, did you want to come back in and pick up on something there?

Beth Cohen, Verizon (13:22):
I did. So I wanted to pick up on Paul's talk about the automotive industry. That's an area that is particularly growing with the 5G cars are no longer mechanical devices. They're really, if you will, 5G or they're wireless devices. And you're absolutely right that there's a lot of work around providing APIs that allow these systems to interact with our network. And yes, they are unique to our network. I was actually in a call where we were talking about a new product and somebody mentioned, well, the devices, anybody can get onto our network. And the answer is no. The devices to get onto our network have to be certified. We will not allow any old device to get onto our 5G or 4G network. Verizon has to do testing, et cetera. And obviously the SIM is unique to us, but those devices have to use APIs that work with our systems. So as Paul pointed out, those are unique and on the flip side, on the automotive side, their APIs are unique to each one of the car companies. So the things that Ford has developed are different from the things that GM has developed. So we end up having to work with all of that, and of course the scale is huge, so there's less motivation to create standards in that part of the industry.

Guy Daniels, TelecomTV (15:23):
Thanks very much Beth and I love how this format gives us time to really explore the questions that we receive from our audience viewers, right? Talking to which next question coming up and the viewer asks, is there a danger that telcos create APIs for services that they want to offer rather than create APIs for actual problems that developers face and will such a telco first approach ultimately end in disappointment? Lots of questions we're getting focused on the telcos here. So Beth, can I come across to you for your thoughts? First,

Beth Cohen, Verizon (16:02):
We're a business at the end of the day and we're in the business of making money and providing services to our customers. So it does not behoove us to build APIs that just serve us. I mean obviously when we, and I can say based on our work with our APIs, we've built APIs, the digital enablement platform, which I mentioned. Those are APIs for our customers. We don't need them, but our customers do. So why would we build anything that is not useful to our customers? Another example is we've built a lot of APIs for the automotive industry and the fleet management, which is a very hot area. Again, we're not doing it for ourselves, we're doing it for our customers.

(16:57)
We have internal APIs that we develop for ourselves, but we don't share them with our customers, particularly we're using them internally to manage our own networks and manage our own systems. So there's zero motivation for us to build APIs that aren't useful, useful for our customers. And how we do it is we go out and ask our customers what they're looking for and what would benefit them. The digital enablement platform was actually developed by one of our solutions architects. So he talks to customers every day, that's his job, and he said, Hey, customers want to connect their internal systems with the information that we have about their networks so that they can be more proactive about it. And that was the modus, that was the motivation and the impetus to create that whole program, and it has been very successful. Our customers do in fact want to be able to tap into the data lake about their networks so that they can correlate with their own systems. So yeah, I don't know. Yeah, why would we build something that nobody wants to use?

Guy Daniels, TelecomTV (18:20):
Well, indeed, Beth, maybe there's a bit of frustration from our viewers there about perceived APIs that they're having to work with. I dunno, maybe we can get some more comments from our audience and we'll include them in the program. We're going to talk to Paul and Petarr a second for their views. So Paul, why don't we start with you first and then come to Petar next. So Paul,

Paul Miller, Wind River (18:45):
Yeah, thanks guy and very interesting commentary there by Beth because I think that is always what we attempt to do in the telco industry and we look at what service providers are offering for API sets, there's always an intent to enable the application that the developers trying to build. I think though historically the service providers have had a difficult time understanding the software developer ecosystem and particular in the question asked, providing APIs that solve actual problems that developers face, that requires really understanding software development and the internals of building an application. I think the service providers tend to really understand a service that they're trying to launch that they believe they can monetize because as she said, every service provider is a business and the intent of offering these APIs is to enable monetization of services. And so that's always very clear and the prioritization is to what services to offer and which produces the greatest value is the subject of much research inside a service provider. There's a difference between that though in offering APIs that actually solve what a developer needs and I think there has been a gap there in the past and a difficulty in the service provider market of really understanding what software developers need for APIs to actually implement their application.

Guy Daniels, TelecomTV (20:01):
Thanks for those insights, Paul. Great. Petar come across to you for your views on this.

Petar Torre, Intel (20:06):
I'll just follow up on what Paul was saying. So yes, there was this type of attempts in the past and there were these type of gaps and the difference that we are hoping now is that by creating those developer friendly APIs, they are easier to consume than the previous versions of telco specialist APIs and simply have to start from somewhere and that somewhere is to expose network and IT assets that telecommunications companies have. I mean, what kind of other assets should they try to expose? I mean those are the ones and do this by doing pilots with enterprises and learning from those and contributing that in kamara different work groups and agreeing there to the best possible level of that that the teams are capable of agreeing, use that for further application enablement and get the feedback and interact fast on that and to try to ensure that feedback loop in that community. There is also developer customer representatives up to SC.

Guy Daniels, TelecomTV (21:26):
Great. Thanks. Thanks. Yeah, that's great insights. It obviously appears that we're trying to listen and bridge this gap between the telcos and developers. Beth, you wanted to come back in though and have some additional comments.

Beth Cohen, Verizon (21:41):
I will concede. Telcos are not software developers. That is not their role and we are very focused on delivering services, although I would argue that with cloud now many applications are services have come to be services, so the developers need to think about their applications or delivering a service. However, and I've said this before, there's a real gap in that the telcos are being asked to develop APIs that allows the applications to be more or rather the way to say it properly is we're being asked to provide application aware services, application aware APIs and we're doing it as much as possible. However, what's the real gap is that there's very little network aware APIs for developers and that I think is a serious gap that really would benefit developers to be able to have an API that connects to the network and figures out what's the optimum way that this application should work within a network framework because applications do run on networks and most developers know nothing about how networks work. And so providing that set of APIs would really benefit everybody in having the applications work. The application performance is something customers are always asking for from us and we only have one half of the equation. We have the network piece of it, we don't own the application piece of it.

Guy Daniels, TelecomTV (23:41):
Absolutely. Thanks very much Beth and to all our viewers, what do you think? Let us know. Send us an email, contact us on LinkedIn, use the q and a form on the website, however you want to get in touch, please do get in touch and share your views. Now talking about your views, it's time to check in on our audience poll for the telco as a platform summit. The question we are asking you this week is what are the main benefits to network operators of a telco as a platform strategy and the real time votes have just appeared to my right here, creating new service opportunities in the enterprise market is still leading the field but not by as much as it was yesterday. If you have yet to vote, then you are running out of time. We will keep the polls open until the end of today and then we'll analyze the results on telecom tv. Right. We still have time for more of your questions and here's our next one and the viewer asks, to what extent is the platform as a service strategy dependent upon developer access to telco SDKs that house network as a service APIs? Okay, very specific question there. Petar, perhaps you could help us out with some thoughts.

Petar Torre, Intel (25:11):
So I'll give some very practical examples of how from API definitions that are cleanly done, you can go and generate the right language bindings and use them as modules, so that's a part that is established for pretty much all the other APIs. Now the example that I'll explain is a prototype application, something we built for mobile work congress that was shown on AWS boots with orange and abstract intel and few other companies were part of that. Basically the developer experience of consuming initially was QDAI. Then we went for traffic influencing API, which is much more complicated in terms of handling sessions and modifying them is normally the way how to get hold of APIs is important module and call the function and how exactly that module implements that particular call in this case was handled by an abstract and from me developing that application I did not have to worry about how did they actually implement the module as this little as the K that connects to the API they exposed.

(26:27)
And so this is just to say that yes, that developer access to telco SDKs is obviously part of the application enablement and it can went planned for it can be properly decoupled from the rest of the application logic so that eventually what the application was doing, we were finding plastic orange fruit visual analytics would trigger the logic that would go called the API on the network side and all of those type of functionalities, they're just imported and used without me in this case as developer having to worry about all the details of that and an abstract was the one providing it and nicely shielding me from the complexity of how exactly this was implemented in this case of reconfiguring orange network.

Guy Daniels, TelecomTV (27:27):
Fantastic, that sounds really interesting. I'm sure a lot of our viewers were MWC and we're lucky enough to see that, but there's obviously a lot of interesting developments happening as we speak. Paul, what are your thoughts on this?

Paul Miller, Wind River (27:42):
Yeah, so I'm going to have to emphatically agree with Petar that the SDKs are actually critical and the way a service provider should think about these is really eliminating friction for adoption of their APIs. I spoke in the main session about the concept of DevOps and the tool chain that we provide as a business called studio developer that these type of tool chains are in modern use today for software development, managing everything from requirements management and code and IDE, automated test environments, artifact management, on and on, digital twin, et cetera. The tool chains that people use to develop software are quite comprehensive, and so if a service provider offers an SDK that can be loaded into one of these tool chains, as Petar described, the bindings to your base language that you're using in your application are immediate and you can exercise those modules or libraries to make the API calls without knowing how that's implemented.

(28:37)
You don't really need to know. You can just make function calls to interact with those API systems. So that's a friction reducer for somebody who wants to adopt these network APIs. Imagine for example, that one operator offers an SDK and another operator does not, which is the software developer naturally going to fall in line with, right? They're going to pick up the SDK and more rapidly develop an application. The other thing that's really important about these SDKs is forward and backwards compatibility and the evolution of the APIs. If you look six months from now or three months from now or a year from now, these APIs evolve into different versions and they're extended and added to continuously. If these are brought in via an SDK library, you can just load the new library and instantly you have access to new functions that exercise the newer APIs rather than creating a burden for the developer to create all those binding the themselves. So I think SDAs, and it's a really good question here, SDKs are very important for the developer adoption and removing friction so that people actually use the APIs that are extended out of the service provider.

Guy Daniels, TelecomTV (29:41):
Great, thanks Paul. Emphatic answers there. Beth, do you have views on this as well from the operator side?

Beth Cohen, Verizon (29:49):
I do. Both Paul and Petter are absolutely right. Unfortunately from the telco perspective, SDKs is kind of foreign language to us. So again, we're service providers, so we think along those lines when we're developing our APIs that they'll be in continuous use, they'll be integrated with our systems on the customer side as well. So thinking about how customers use these APIs to create new applications and making it easier using SDKs I think as a foreign language for us and I think that has held us back from making them more usable and gets back to my earlier comments about what we really need and that real gap of having very few tools that allow applications developers to incorporate network intelligence into their applications.

Guy Daniels, TelecomTV (31:02):
Yeah, thanks for those insights, Beth, especially the operator specific insights into the SDK question, right? Let's have a look at what else we've received from our audience. There's another one here. Well there are two very similar ones actually. One has come in a few moments ago. What are the thoughts of our panelists on the most effective go-to market strategies for telcos to sell their platform capabilities to the enterprise and also for developers to access these APIs direct sales via hyperscalers, via developer ecosystems. What is the optimal approach? Beth, can we maybe come back to you first to kick us off?

Beth Cohen, Verizon (31:54):
That's a great question. We've been struggling with that for a couple years now actually. And right now we have a portal that advertises the APIs. I have no idea whether the developers even know that it exists because we don't go around advertising particularly that we have APIs. It usually comes up in conversations with our customers as part of a larger conversation around designing their network for them. And we design global networks for extremely large companies and APIs do come up in conversations. They frequently show up in the RFPs, so that's where we inject that conversation. Hey, yes, we do have APIs. Yes, we do support the open source community and the standards bodies and developing them, but we don't do a great job of advertising that we have them because I think the majority of our sales teams don't even really think about them and we certainly don don't run Super Bowl ads saying that we have standard certified APIs.

(33:25)
So the message absolutely has to get out there. Now one good way, and I know we are pursuing this, is leveraging the standards bodies and the open source community itself to really spread the word, and I know we do do that. I personally give talks at various open source and standards conferences about the APIs that are available and our support for the API community, the API developers community. But there's another factor which I think has made it harder, which is that the developer communities themselves have gotten very fragmented and so it's hard to get the message out to the right communities that would have the best use, be able to best use the APIs that we have developed.

Guy Daniels, TelecomTV (34:25):
Thanks very much, Beth. Yes, communicating and getting the message out. Can you come in on this one as well? What's your views?

Petar Torre, Intel (34:34):
I'll focus on few keywords. So one is what another one is enterprises. So the way to get there is to start from what are those developers serving enterprises there are either in-house or there are some of their system integrators. It can be very fragmented per industry, country and so on. So obviously, I mean my favorite example is if somebody wants to sell to mining in Chile, knows to know how to spell this thing properly and have all the right context to get there and need to understand the environment, the use cases for this is of value, those that are currently being invested because there is chance to change something if this is static environment, how to disrupt it with all the ways on how it's correct to do that and then eventually has chance to have the discussion and to prove that those APIs and capabilities are of value and actually get adopted. And this is what makes it challenging. The fragmentation, the engagement of all the different enterprise vertical ecosystems is a very nontrivial thing to do and was explaining how this thing is currently being done and how to do more of it.

Guy Daniels, TelecomTV (35:52):
Great, thanks Petta, because as you rightly say, there are lots of varied enterprise ecosystems out there to deal with, right? Let's move on and see what else is coming from our audience and we've got another question here that's telco specific. So Beth, I'm hoping I can come to you with this one first and the viewer asks, there are multiple API standards, different industry bodies, there's vendor influence, there's open standards, telco has all these different aspects to deal with, but are these challenges a hindrance to telcos or are there opportunities that telcos can leverage?

Beth Cohen, Verizon (36:40):
I think they're both the number of people that participate in the many standards bodies. The great thing is that there's lots of them within the industry. Verizon as well as the other telcos are pretty limited and the people that participate tend to be, it's a longer term view, right? Developing standards, investing in developing open source code, developing open source reference models. I personally have been working on the ATE project for coming on six years now. And yes, it is a mature project but that's a lot of time and effort, but that's not my full-time job. My full-time job is developing products for Verizon and so I find that it's a struggle to get the company. It's not that Verizon is not in support of standards bodies, don't get me wrong. We absolutely are. I actually just read that our chief product officer, DECA is the president, chief chairman of the meth organization. So clearly we do sponsor open source and as well as standards bodies, but probably we have to weigh the cost and how long it takes for these standards to develop against very real pressure from the investment community in Wall Street to get successful products out the door. So it's a challenge and we do have to pick and choose what standards we support and what standards we don't support or rather we don't actively support, if you will.

Guy Daniels, TelecomTV (39:02):
Yes, absolutely. Thank you Beth. Lots for individual telcos to consider that to what their strategies should be. Petar, let's come across to you if you've got additional thoughts on this one.

Petar Torre, Intel (39:19):
So I do, and there was, I can remember some board of advisor type of discussions 15 years ago we would debate how much could we use open source more to compliment and eventually to speed up what was perceived as a very slow process within standards development organizations. Now fast forward through the years where it was really nice to observe how telecoms and vendors learn how to cooperate in these type of communities and where communities have very clear purpose, desired outcome, limited scope and eventually when the magic happens that they're properly resourced. In the meantime, there is a good understanding of what the process of contributions is. Good culture over there develops and a lot of exchange and this hurdle, I mean this overhead of dealing with other companies were suggests on our own or operators on their own trying to prove that they can build telco cloud better than the next operator.

(40:38)
I mean it's possible, but it's huge task to do. And one of the communities that mentioned, I'm also part of that, so I look at writing the specs. Yeah, you can give it a try. Write 300 pages of high quality specs. It took us six years over there to get that. Now other people, other communities are trying to implement some type of this type specifications into running environments because individually each of these companies is struggling with lifecycle management of such clusters using tools that are incompatible beyond even versions, definitely not with other vendors. So there are challenges in simply adopting amount of technology that is coming into telco vertical that there is requirement to collaborate across boundaries of a single company because those technologies are non-trivial to cope with and there is much higher chance if there is little lower head to go into community share what we have, get everything from others and everybody gets smarter out of it.

Guy Daniels, TelecomTV (41:52):
Great. Thanks very much Petar. Thanks very much for those comments. Well, looking at the time, I think we might have time for just one more question. Let's squeeze in this late question from the audience and it's a question that really picks up on the earlier panel discussion and the questioner asks, what is the timeline for the industry to move beyond consumer use cases to address enterprise and IOT use cases? We've been doing this for years with APIs and middleware for example, one M, two M partnership. What has changed now? Why is it different today? Anybody would like to hazard a view on this one as to why today we find ourselves in a different situation than we maybe did 10 years ago and why developers should have more trust in us perhaps for our offerings. You mentioned this in the panel discussion didn't you, about how there's a sense of urgency now. Do you want to weigh in with an extra thought?

Petar Torre, Intel (42:59):
Yeah, a sense of urgency is great motivation. I mean we can read number of financial statements and come to conclusion on ACT now. There is a cultural evolution, evolution in terms of understanding developer requirements and make it developer friendly. This is a very strong design principle for defining this type of API categories. There is understanding on why this thing needs to be done through innovation in open source versus trying to agree in standards development organizations. So yeah, time is right for it now

Guy Daniels, TelecomTV (43:38):
That's good news. Petar, let's also hear from Beth and Paul starting with Beth. Beth, what do you think? Why is the situation different now?

Beth Cohen, Verizon (43:48):
So I'm going to talk about the pendulum swings of between consumer and enterprise and I have the gray hairs to say that I have seen that happen several times and right now the pendulum is swinging back toward the technologies leading enterprise development, technology development is coming out of enterprise. So somebody recently told me 5G at the end of the day is an enterprise play because the real benefactors are the enterprise. And I thought about that and I was like, yeah, that is true because the average user, if they're using a cell phone, doesn't matter whether it's 4G or 5G, they don't really see the benefit. However the enterprise can see real benefit for smart cities for for iot, we talked about the automotive industry really revolutionizing the capabilities for smarter cars, drone technology, all sorts of technologies. Oh, industrial, IOT, industrial manufacturing in general, supply chain, all of these are enterprise applications that really need APIs, applications, cloud, all of that to work together to be successful. And that's why I think enterprises is pushing the technology boundaries forward today. But 10 years ago it was a different situation. The consumers, the rise in smartphones and the drive toward developing smarter use of phones and how people interacted with their devices, mobility devices was very different. So enterprise winning today, maybe in 10 years it'll be different.

Guy Daniels, TelecomTV (46:02):
Great, thanks very much. Beth Paul. Times are different now. So is this why the prospects are better for the enterprise market, enterprise services?

Paul Miller, Wind River (46:15):
No, I think what we've really seen from market data is that whereas if you go back 10, 15 years ago, there was a huge build going on for public cloud and centralized computing and this sort of thing. But what we're really seeing now and the market data shows us that by 2027, about 70, 75% of compute compute is actually going to be done on the edge of networks. Now that's really interesting and it's driven by the expectations of the contemporary consumer. Everybody kind of expects now to have a self-driving car that will bring them to work a S level three and four self-driving electric vehicles. They expect drones from Amazon to deliver their packages to their front yard. There's the idea of remote telemedicine and IOT that Beth was talking about. And what all this means is that there's a huge amount of applications being built at the far edge on the devices that as we all know, they're all connecting via 5G and eventually six G into the service provider network.

(47:14)
So I think that's the thing that's changing. If you went back as little as 10 years ago, you'd be hard pressed to find an automobile that had a cellular connection. Now I would challenge anyone to go buy a car and find one that doesn't come out of the box with a cellular connection and overthe air update services to it. So that's fundamentally different. All these edge devices, the movement of compute and AI to the edge is really driving all of these systems that connect to the service provider network. And those are then of course getting exposed via APIs to enable new applications and revenue generation to happen. And that's happening right now. Several questions ago, Beth mentioned the importance of the automotive sector and what's happening there with over the air updates and compute offload and cellular vehicle to infrastructure and vehicle to vehicle accident avoidance. There's a ton of stuff going on there. Again, all driven by what's being built on these edge devices that connect to the carrier networks.

Guy Daniels, TelecomTV (48:09):
Great. Thanks very much Paul. It does seem to be a lot more opportunities at the moment. Well, we are out of time. Thank you so much to you all for joining us for this live program and that's a wrap for this year's very first Telco as a platform summit. Thank you to all of you who submitted questions. We try to cover the most representative ones in the limited time we had available. If you missed any of our programs featuring all of these industry guests, then you can watch them on demand from the telecom TV website. Our DSP leaders coverage continues next month with digital support systems, another new summit for you. Until then, thank you for watching and goodbye.