 Hello, this is Lássos Szilály from Ericsson North America and the North America Chief Technology Office. I'm responsible for network exposure, including go-to-market and technology strategy, use case discovery and partnering strategy. In today's presentation, we will discuss how mobile operators can accelerate 5G adoption in the technology ecosystems with third-party application platforms. The key thesis of this presentation is that besides directly exposing 5G network capability APIs to developers, we should consider interworking these APIs into third-party application platforms and then position these higher value at higher abstraction services on the leading API market places. Today, first, we will go through the 5G economic impact and key segments to set the stage then discuss the network capability APIs, which are relevant for Edge and 5G application developments, then discuss the mobile operators go-to-market challenges with these APIs and how tapping into the existing ecosystems with third-party platforms can potentially mitigate these challenges. Then we will discuss and overview the platforms and any blurs relevant for 5G and Edge. What are the typical integration patterns occurring if you want to integrate with these platforms on scale? Then we will discuss some examples in detail. When it comes to the 5G economic impact in a recent BCG study, it was estimated that the impact of 5G on the US GDP in the next decade will be beyond $1.4 trillion, and this figure is a composition of multiple segments from manufacturing, professional services, construction, healthcare, trade, finance, real estate, entertainment, transportation, education, and agriculture. What we see is that we are talking about a very wide range of requirements towards the network. If we want to simplify it a little bit, we can talk about maybe three main requirement segments, massive machine-type communication with use cases like logistics, tracking fleet management, smart cities, smart agriculture with key characteristics including low energy, small data volumes, massive numbers, then we can talk about the Enhance Mobile Broadband segment with ultra-high-density video broadcasting, ARVR gaming with characteristics including extremely high throughput, improved capacity, and improved coverage. Then we can talk about the critical machine-type communication segment with traffic and safety control, industrial applications, and remote surgery use cases with key characteristics including ultra-reliable, very low latency, and very high availability. What we see here in general is that in order to create these applications on scale with flexibility and efficiency, we need applications to be able to dynamically interact with the network infrastructure, and this interaction is implemented by APIs and network exposure. So what sort of network exposure capabilities we are talking about? We have three main categories, network configuration APIs, network information query APIs, and notification APIs. When it comes to configuration, quality of service is enabled to developer to specify guaranteed betrayed or priority requirements towards the network infrastructure. Sponsored data enables the developer to sponsor data sessions, so the specific application is not affecting the data plan of the user. Background data transfer can optimize firmware upgrades on scale for IoT devices. Device onboarding enables IoT applications to seamlessly integrate with the network infrastructure. Size selection API is the interface for network slicing. Traffic routing is key capability for edge computing. Then when it comes to information query, location enables cellular positioning. Network performance provides real-time or predictive information about congestion, bandwidth, latency, and coverage. And then the developer can also subscribe to notifications about client location change, IP address change, reachability, user activity change, and roaming status. And as you can see, these capabilities can really enable dynamic interactions between the networks and the devices for these advanced next-generation use cases, but we are still facing some challenges. Some of these APIs are pretty low-level, and this might slow down the adoption in the technology communities. Then also some of these APIs are actually implemented pretty sensitive configuration capabilities, so some of the mobile operators might be reluctant to completely expose these APIs. And then we can also talk about APIs which are potentially exposing relatively sensitive information, and some of the mobile operators might be not willing to share real-time information about their network infrastructure. And this also affects the go-to market with these APIs. So on one hand, some of the mobile operators are not willing to expose all of these APIs to a marketplace towards developers. Then also some of the exposed APIs might be relatively low-level for some of the developer demographies. And this is where we come to the key thesis today that we should consider interworking these network APIs with third-party application platforms or higher-value application development platforms, which can on one hand lower the barrier of entry for developers and with the higher abstraction, thus actually accelerating the innovation for the ecosystem. Then it can also abstract away the sensitive network configuration and information APIs. So mobile operators can keep the control of these assets. So what are the typical platforms and enablers for 5G and Edge in this discussion? First of all, we have XR with rendering acceleration and localization acceleration on the Edge, and with 5G connectivity for connectivity guarantees. Then when it comes to gaming, again, rendering acceleration and connectivity guarantees for streaming analytics with AI inference and stream processing, SLAM, which is simultaneous localization mapping of IVU's technology for drones and autonomous moving robots and even augmented reality, again, point-out processing on the Edge, low latency messaging with message queues, databases with real-time databases, content delivery with video and other static and dynamic assets, leveraging Edge acceleration and digital twins with real-time digital representations, including HD maps, leveraging the low latency of the Edge and the guaranteed connectivity characteristics. So that being into the technology ecosystem with 5G, in practice means that integrating network capability APIs with the leading third-party platforms from these verticals and offering these higher value-add services on the leading marketplaces. At the end of the day, from the developer, it is a true cloud or platform as a service experience, going into an API marketplace, be it a cloud marketplace or any other relevant third-party marketplace for the specific technology, then subscribing to the service on the marketplace, configuring the service parameters like geography, service level, and retrieving the necessary API and keys and instructions to go on with the development, and then actually implementing the service, configuring the service, uploading the necessary contents and artifacts, and integrating the service to the client applications and to the rest of the application stack. And as you can see, we are talking about no direct exposure to network APIs or the Edge environment. It's a complete platform as a service experience, and Kubernetes is a key enabler to make this happen. So when it comes to implementation, we should go into the platform lifecycle and the platform integration patterns. So first of all, when it comes to the lifecycle, we are talking about service introduction first. So this is the time when the service provider makes the service available, then we can talk about the service subscription. This is when the developer subscribes to the service, and then the service consumption when the end user uses an application relying on the service. And depending on when the application runtime environment gets provisioned at which stage from this screen, we can categorize the previously discussed application platforms into three main patterns. The first being introduction trigger runtime pattern, or subscription trigger runtime pattern, or the consumption trigger runtime pattern. And this is what we will discuss in the following slides in a little bit more details. So first of all, when it comes to the introduction trigger runtime pattern, we are talking about applications like databases, real-time messaging, and CDN. So these are the applications where all the components of the service gets provisioned at the time of service introduction. And then the developer is subscribing to such a service, then actually the access configuration is what is being triggered. And the developer is accessing a multi-tenant environment. And when it comes to the service consumption, actually the service consumer client is basically retrieving the artifacts and configurations which the developer has created in that multi-tenant environment. When it comes to subscription trigger runtime pattern, we are talking about applications like analytics with AI inference or stream processing, simultaneous localization and mapping and digital twins. So in this case, at introduction time, the control plane is getting provisioned. And actually the service subscription is triggering the application runtime, the developer-specific status instance to be provisioned, which means that each of the developer gets a dedicated environment. It's a single tenant environment for the developer and it's a multi-tenant environment for the consumers. And the consumers are accessing these environments used by the developer. And then we can talk about finally the consumption trigger runtime pattern. These include cloud gaming and XR. In this case, at service introduction time, the control plane is getting provisioned. And the service subscription is basically provides the developer access to upload the developer assets and configure the runtime parameters. And the actual service consumption is triggering the runtime provisioning. So when a cloud gamer or cloud gamer or XR user is using this at service, the specific resources are getting spinned up. So let's look at into some concrete examples when it comes to implementation. So first, when it comes to introduction triggered runtime pattern, RevitMQ is a good example. So RevitMQ is the most widely deployed open source message broker, supports multiple messaging protocols, including MQTP and AMQP, supports plugins, wide range of client libraries, supports distributed deployment with clustering and federation. And it's multi-tenant platform with its virtual host capabilities. And the network API use cases we can consider includes guaranteed bandwidth and priority for the message delivery, which can rely on the quality of service API, then latency, which can also rely on quality of service and the location API in that work with DNS. And when it comes to geofencing, we can rely again on location. So we can make sure that a specific service only available in a specific area, where we can provide the SLA, depending on the edge deployments. We could also consider slicing and traffic routing for the guaranteed bandwidth and latency use cases, but for simplicity, I'm leaving out these APIs at this time. So when it comes to service introduction, it's important to mention that we should leverage the operator pattern at Kubernetes to implement this service life cycle management we are talking about. And according to this one, at introduction time, we are deploying the operator and operator controller, which is also involves provisioning the Revit MQ clusters, the marketplace integration, and the bad portal for the developer. And we also have the network APIs onboarded. We can integrate the quality of service and location APIs, leveraging the Revit MQ plug-in capabilities. And we also need a DNS with location API integration. So when DNS queries are processed, the location API can be leveraged for picking the IP address of the processed edge Revit MQ instances. When it comes to subscription, this is when the developer is specifying the requirements on the marketplace. And using that specification, the operator can configure the virtual host with quotas using the Revit MQ O&M APIs, the Revit MQ APIs, configure the DNS with the developer specific URL for the service that can configure the access to the developer web portal and can provide the client here and URLs for the developer. And then the developer can platform the client SDK integration to use the service. And then at the consumption time, the client accesses the service via the provided URL, then DNS routes to the closest edge using the location API as discussed, the Revit MQ plug-in that can trigger the quality of service API for that specific client. And if the client is outside of the geofence message delivery area, then the message delivery can be suspended. For subscription-triggered runtime pattern, let's discuss the NVIDIA Deepstream as a platform example. NVIDIA Deepstream SDK is a stream analytics toolkit for AI-based multi-sensor processing video audio understanding. And it's very well integrated to NVIDIA ecosystem. And there are multiple deployment options, including from embedded JSON devices up to the high-end GPU servers in the cloud. When it comes to the relevant network API use cases, again, we can talk about guaranteed bandwidth, latency, and geofencing. But we can also include sponsor data for video streaming, because it can be very significant data traffic, and video stream optimization with network bandwidth and network congestion information. When it comes to the service introduction time, again, operator controller deployed, then we need to container registry with the pre-configured Deepstream flavors, because we are not exposing the Deepstream SDKs directly, but we can also abstract away the details of the configurations and create pre-configured Deepstream images in the container and store it in the container registry. And once the developer specifies its requirements, the proper image can be selected and provisioned. Then we need a model repository for the developer, which is, of course, empty at the beginning. And we need a WebRTC media server for handling the video streams. And this is where we also need to reintegrate the media servers with the quality of service, also the location network bandwidth, and congestion information. And we can also talk about, we can also, we need also need to deploy the marketplace integration and the web portal for the developer. Then at subscription time, the developer again goes to the marketplace, specifies the runtime parameters of the marketplace, including bandwidth and disposal data options. And then the developer can upload the models. And then the operator will deploy the matching pre-built Deepstream flavor with the specified model on board, configure the WebRTC server, configure the DNS, configure the access to the web portal, and the developer web portal, and provide the client key and the URL for the developer to integrate the clients to the service. Then in consumption time, the client accesses the service via URL, the client, the WebRTC client, and then the DNS routes to the closest edge using the location API, the device connection to the media server will trigger a quality of service API and sponsored data API, and which will provide for that specific device for the video streaming. And the media server that patches the bandwidth and congestion information continuously to optimize the video streaming. And again, if the client is outside of the geofence, the area difference can be suspended. And finally, we can let's discuss the service consumption regard runtime pattern. Here, the example is Unity Render Streaming. Unity itself is a cross-platform game engine, and it's also used all across the industry outside gaming. And it's one of the good engines for XR applications and has very good integration with XR devices and related technology platforms. Unity Render Streaming is an application stack which provides rendering ability for browsers using cloud resources. And the use cases include viewing card configurators and architecture models via browser or on mobile devices, and it also leverages WebRTC. When it comes to the network API use cases, we are talking about the exact same APIs and use cases and capabilities. The difference is that at this time, we are not uploading the data but downloading from the edge. So when it comes to the service introduction, we start with operator controller, then we have a container registry for the three-dimensional application servers. So this is the kind of three-dimensional content and application plus the rendering server previews together. And this can be then uploaded by the developer and stored in the dedicated container registry. Then we have the WebRTC signaling servers and the stuntern servers, the marketplace integration, and the web portal for the developer. Then at subscription time, again, the developer specifies the runtime parameters on the marketplace plus bandwidth and sponsor data options, upload the 3D application server with the content and the rendering build on their own machine. And then the operator will configure the DNS, configure the access to the web portal, to the tiny web application needed for the specific 3D application and provide the client and the URL for the developer to integrate with the client devices. And then when it comes to consumption, the client connects to the web app via the URL. The operators will spin up the three-dimension 3D app serve on the closer stage. Again, using the location API, the operator invokes the quality of service and sponsor data APIs for that specific session. The signaling server then will establish the WebRTC session and the rendering server can use the bandwidth and congestion APIs to optimize the streaming. And again, if the client is outside of the specified geographic area, the geofence capability with location API can neglect the service. Finally, before we finish, some notes on the network and an edge infrastructure. So mobile networks are three-structured and when it comes to the edge infrastructure, edge is sitting on some of the nodes of these trees. And as the networks are developing, more and more edges will appear on these nodes and deeper and deeper in the network infrastructure, starting with the IP exchange points on closer to the outside world, going deeper into the network infrastructure, ending up on the cloud-run sides, which are really close to the client, mobile client devices. And especially when we are talking about nationwide and multi-operator scenarios, there are multiple trees involved in a use case. And there are also multiple edge vendors. So multiple hyperscalers and other third-party vendors need to cover a specific area or will likely be covering a specific area with edge computing. So when it comes to orchestrating workloads across larger geographic areas, we are definitely talking about multiple Kubernetes clusters, video operators, and even especially across operators. We have a south-north dependency on the performance, which means that the closer we put the deeper vProvision workload in the edge, the lower the latency can be. So basically then this placement act is an SLA fulfillment activity. And we also have an east-west dependency, where it comes to, so not between the client and the edge like previously, but between the edge-to-edge communication, which can be key for certain applications. And we have to consider that when it comes to communication between edge nodes between these trees, the latency between the edge synchronization or between the edge nodes can be larger, the deeper vProvision an application in the edge infrastructure. And this can be a critical factor for some of the demanding applications like message queues where multiple edge nodes are involved or gaming where certain networking or mobility scenarios require real-time synchronization between neighboring edge locations and certain databases. But there are also some less demanding applications like inferencing or stream processing or XR SLAM when the focus is really about the client edge communications. So we need to consider this when designing a platform service. So as a summary, today we discuss the economic impact of 5G and the key segments. The 5G network capability APIs relevant for edge computing application developments. The mobile operators go to market challenges with these APIs and how tapping into existing ecosystems with third-party platforms can potentially mitigate these challenges. Then we have been discussing the typical platforms and enablers relevant for edge computing and how can we categorize these enablers into platform integration patterns. Then finally discuss some concrete implementation examples. Hope you enjoyed the presentation. Thanks for your attention and if you have further questions feel free to reach out. Goodbye.