 Welcome everyone and thank you for joining GTC. I also would like to thank you for joining us in this session today. This is a very special session with NTT and Red Hat to talk about NTT's multi-access edge computing platform, which was built to deliver edge AI services. Before we start, I'd like to remind everyone that we are available to answer any questions over chat during the talk. So as questions come up, please click on the chat button on the bottom right of your web browser to submit any questions you have and you happily answer them. Let me introduce myself. So my name is João Gomes, and I have the privilege to work at NVIDIA in lead or telco edge solution development efforts. Which with me today, I have a few distinguished colleagues from NTT and Red Hat. The presenters will introduce themselves as we proceed to the different parts of the presentation. As you can see, we have an extensive agenda to cover today. Highlighting different aspects of the NTT's Mac platform. For the first topic highlighted in green here, Richard G will present with me. Rich, why don't you introduce yourself and kick us off. Thanks, you're welcome. Yeah, my name is Rich G. I'm a Senior Director in Red Hat Industries and Global Accounts Group, and we've got a lot to cover today, so let's get started. So why NVIDIA and Red Hat? Well, at its core, the strength of our partnership is the shared cloud data vision based on open-source technologies to drive flexible deployment models for on-premise, private, public, and edge cloud. João, what are some of your thoughts on our partnership? Yeah, so as we know, NVIDIA is the AI competing company, which you see on the left. And Red Hat is the open-source solution company on the right. And we have established a very broad collaboration to really accelerate and simplify the development and deployment of AI and graphics application. All of these align with cloud-native principles and open-source technology. And because of that, working with the ecosystem is key to our collaboration. Rich, why don't you expand on that for us a little bit? Sure, we'll be talking today quite a bit about our leading platforms, but ultimately it's together that we build a broad ecosystem to deliver innovative solutions on an open-hybrid cloud application platform. In this session, we'll see how entity has leveraged our partnership and our platforms to deliver new 5G AI and edge services. In case you're not that familiar with Red Hat or OpenShift, here's a few important things to know. First, all Red Hat software development is done in open-source. So you probably know that we participate in and create community-powered upstream projects. Then we integrate multiple projects to foster community platforms. Finally, we stabilize these platforms and projects together with a rich ecosystem of services and certifications. The colored blocks represent an example of our platforms. Red Hat OpenShift container platform is an enterprise-ready Kubernetes container platform with full-stack automated operations to manage hybrid cloud, multi-cloud, and edge deployment. It's a unified platform that has integrated many open-source projects, tools, and the service is critical for both developers and operations. Here you can also see a sampling of some certified partners which shows the breadth and depth of our ecosystem. In many ways, OpenShift is an ecosystem platform for creating and managing cloud-native applications. The emergence of containers, Kubernetes, and DevOps-centric application delivery has been driven by many different open-source projects. So being able to leverage a robust ecosystem is key to any successful digital transformation. Let's look at how NVIDIA and Red Hat work together to accelerate AI and address some common industry challenges. Thanks, Rich. That was good. Well, this session is about NTT's MAC platform, that leverage capabilities that both Red Hat and NVIDIA have built together. And what you can see on this picture are some of the foundations of this solution. EGX at the bottom is the NVIDIA platform that enables different AI applications such as intelligence video analytics, augmented and virtual reality, robotics, and 5G. These applications, they leverage GPU-accelerated compute to implement different AI, deep learning, and graphical technology required by the applications. And the key here is to enable independent developers to create these apps using different application frameworks that NVIDIA has built. As you can see here in the picture, Metropolis, CloudXR, Aereo, Isaac, and others. These frameworks, they provide tools and SDKs to speed up development time and also ensure compute efficiency of the applications. This in turn creates a large ecosystem of applications from dependent software vendors that service providers like NTT can benefit from. These applications, they need to rely on open source software to access GPU compute and run as cloud native software. And this is a very important part of the collaboration we have with Red Hat. Rich, would you mind expand a little bit on the open source collaboration and the different things we're enabling like the GPU operator and others? Sure. So in addition to our certified ecosystem, I showed you over there, we have many open source projects helping with hardware and workload acceleration. One of them being operator framework. Operate framework is an open source toolkit to manage Kubernetes native applications called operators in an effective, automated and scalable way. We collaborate on NVIDIA's CPU operator to simplify and automate the management of all software components into provision and market GPUs. As mentioned previously, OpenShift enables customers, partners, and developers to easily leverage technologies and modern application models to rapidly create, deploy, and manage new services. All these frameworks working together will enable many industry solutions, especially as we move to the edge. The intelligent video and analytics use case you will hear about today is in the telco and retail industries, but it's applicable for many other industries such as logistics, manufacturing, and healthcare. Let's take a look at how we've worked together with at the East to create a new telco edge offering. So telcos have been transforming their networks to be flexible through control and user plane separation and hardware and hardware desegregation. Software driven networks have embraced open architectures, complete off the shelf systems, and open source software. Cloud data technologies have been adopted with categorization of network functions in the 5G core and radio access network. However, it's not just about deploying higher bandwidth speed and low latency networks. The end goal is really to rapidly offer new edge services to customers, which cannot be done with infrastructure and application silos. OpenShift is the unifying hybrid cloud platform for the telco network functions and the enterprise edge application. My redhead colleague, Suzy Atmoson, will be highlighting how it is deployed for 5G from the cloud and network core through all the edge layers. He'll cover how entity issues open shift to create a cloud native multi-access edge computing AI platform offer deployed across their edge sites to drive new services. He'll also describe how we help with the developer pipeline to improve application delivery. Van Hashimoto-San from NTTE will talk about how this new cloud native Mac platform offer is speeding up creation and deployment of applications and how it's more scalable. Then he'll share a retail use case with intelligent video analytics, which shows how we improve customer service and sales. Dual, can you tell us a little bit more about NVIDIA and intelligent video analytics? Sure, so before we hear from Suzy Atmoson and Hashimoto-San, let me conclude this intro and hand it over for them. So NTTE has built this edge platform to deliver AI applications based on our common technology. One of these applications is computer vision or also known as intelligence video analytics. Intelligence video analytics is truly one of the most amazing technology of that AI and edge computing enable. And in this diagram, what you see is on the left some video cameras acting as IoT sensors. These cameras, which can be connected over 5G or fiber send video upstream for processing at the edge with AI and deep learning techniques. AI running at the edge detects objects, patterns, behaviors in the video streams, which then provides actions and insights for applications. IVA is being used today by all the major industries and verticals like SMBs, stadiums, sports arenas, retail, you name it. And IVA is a very nascent technology, it's a new technology and the way we enable the ecosystem is with the application frameworks we built, like Metropolis as you can see on the top right corner on this diagram. Metropolis being an application framework provides SDKs, APIs and tools for developers to build these applications. And ultimately what Metropolis creates and enables is this large number of apps from hundreds of independent software vendors that service providers like entity can leverage to create new services. And that is in a nutshell what this is really about. I will now hand it over to Sugiyama-san that will share more details on how this is actually implemented by entity with Red Hat and any video technology. Hello everybody, my name is Haru Sugiyama, chief architect at Red Hat. From my side, through this talk, we'd like you to know that latest edge trend in Japan and open-seat foundation technology that is advantage of entity is Mac AI platform. First off, let me briefly talk about what edge type we are covering and our Red Hat positioning of edge. Edge covered many areas. This slide illustrates tiered edge structure and the deployment pattern. I summarize four types of edge in this slide. Device edge, custom-premise edge, telecom edge and centralized cloud edge. We have a two edge products, REL and open-sheet content platform. REL can be deployed as a device edge and custom-premise edge and radio access network distributed unit. Open-sheet content platform can be deployed as custom-premise edge and telecom edge, including far edge, near edge, regional edge. Far edge is a local access site, such as entity group center. Near edge and regional edge are the regional aggregation site. And we focus on the telecom edge in this session, especially to the regional aggregation sites. In the telecom edge area, we have a flexible design to deploy open-sheet Kuberlis node with a machine config pool that service provider can select design it the machine type, such as DRAM, distributed radio access network, CRAM, cloud radio access network and cloud native Mac in each Kuberlis cluster. We have three unique design for open-sheet cluster in addition to the standard Kuberlis cluster. Open-sheet three node cluster, open-sheet remote worker node cluster, and we have plan to release single node open-sheet cluster this year. Open-sheet three node cluster integrates open-sheet worker and the supervisor node to each of the three server in the single cluster. Open-sheet remote worker node cluster can extend single worker node to near edge or far edge from open-sheet supervisor node placed in the regional edge or core site. Single node open-sheet will be integrating worker and the supervisor in the single server. So we have a solution for zero-touch provisioning across telecom edge and telecom core. Japan is now heating up edge computing deployment, 5G core standard on deployment, 5G radio access network deployment and local 5G or private 5G deployment. Actually, I already had a joint session with NVIDIA at the GTC Japan last year to talk about open-sheet 5G radio access network with Aurel GPU SDK. Open-sheet supports full stack of NVIDIA GPU. Open-sheet can be designed as DU, CU, MEC, and 5G core. File, open-sheet can be also designed as an air edge platform. In the current trend, of course, we are now in the 5G era, but we also know that we are entering AI era in the market demand of 5G and beyond 5G to 6G in the next decade. Entity East is starting to launch a project called REIWA. They are deploying new style of MEC AI platform through the project REIWA, leveraging regional edge with interconnected wide area network. As you might know, most mobile network operators in Japan are using facilities in Entity Group Center to build their radio access network. And most service providers are also using Entity East fixed access network in each Entity Group Center, already placed in the nationwide Japan with many optical fibers. Each regional edge node aggregates Entity Group Center in each region. The project REIWA provides heterogeneous computing resource with CPU and GPU, and the resource of data storage in addition to the network resource in each regional area through their MEC AI platform to help to accelerate co-creation edge business together with business partner and customers. So it's time to Hashimoto-san. He's based in the Entity East headquarters in Tokyo. He will talk about the business case on MEC AI platform accelerating by OpenSeat and NVIDIA GPU. Hello everyone from Japan. In my part, I'd like to introduce about a video analysis AI platform we're developing for this summer. This is a MEC platform integrates networking and computing to make video analysis more accessible. First, let me introduce myself. I'm Yuuki Hashimoto from Entity East. I'm new business development for IBA. Then we Entity East are a Japanese leading telecommunications company with over $16 billion in sales a year. We operate in a wide range of domestic markets by utilizing the customer base and the expertise in communication networks and ICT. We have 1244 million FTTH subscribers and our fiber optic lines cover about 95% of the population in Japan. In recent years, we're particularly focused on digital transformation with AI. Just a few years ago, the communication services we provided, such as telephone and internet were people centered. But recently, the requirements for communication services have been changing dramatically because we're all in the IoT age, where everything is connected to the network. Now we're contributing to the realization of a smart world. The way to realize the world smarter is FMEC, a combination of FTTH and edge computing. But just the moment I think about it, when you think of just Mac, you probably come up with being built by 5G operators. FMEC we propose integrates at the high-level FTTH, which is a low latency, low electricity and high security with computing resources. It only makes it possible for us to build FMEC because of our high FTTH penetration rate in the country. We originally have a large number of telecommunications and telecommunication facilities stationed in the buildings throughout the country. We can install edge computing and vacant our buildings because we've been working on upgrading them continuously. We're moving forward with constructing a new architecture that integrates networks and computing to meet IoT age needs while making the most of our original facilities. We believe that video analysis is one of the fields where the capabilities of FMEC are most practical. That's because our FMEC has the power to transmit and analyze the massive amount of real-time stream images captured by cameras all over the city. Okay, let me tell you quickly about IVA markets in Japan. The domestic IVA market is expected to grow to $1.4 billion by 2023. More than 1 million IP cameras, the key devices that support it, are shipped annually. It's estimated that there's more than 5 million IP cameras in your production in Japan and they're widely used in all kind of industry and business categories. Therefore, it's assumed the infrastructure of IP cameras has sufficient potential to expand IVA business. On the other hand, even though there's a very high level of interest in using AI for video analysis, the number of cases where it's actually being used is very limited. Why? Our hypothesis is that delivery method is a main problem. The current mainstream is an unpremise style. It resizes images and analyzing them through an AI inference model by computing on cameras. But we're considering this way has three major pain points for ISVs. First, they have to install user-specific systems like system integration. Second, it needs to manage multiple locations from start to end. Last, high cost. This is the concept we're actually aiming for. We'll have a platform with GPU servers to consolidate the AI analysis. We want to collaborate with many ISVs to create a world where customers can easily add their AI to IP cameras and enjoy multiple AI applications. Fewer servers at the base, more computing resources on FMIC. So, we've already started our POC. We've made the application containerized with Docker and lifted them to FMIC. We're also developing the infrastructure to accommodate more cameras on a single Docker host. Through this development, the platform has been configured like this. We're going to provide a network, GPUs, and the container orchestration environment so all ISVs have to do is containerizing their applications. Our goal is to be the best-choice platform for all ISVs. The keyword is 3S. Let me show you one by one. The first S is about speed. Our priority is how to enable ISVs to deliver IVA applications faster with FMIC. We're not only adopting container orchestrations, but we're also trying to make various features available on a managed basis. It seems that there's each ISVs for each development environment, so we make it possible they can use the domain they already used. They can develop AI application and models in their current environment, update them, and push them as a container images to AWS ECR. We're planning to use our managed services for automatic deployment to the container. So why containers? The answer is straightforward, portability. Once you package your application into a container in the development environment, you can carry the container image from staging to the production. We understand that it's very convenient, and that's why containers are widely used. Then why container orchestration? We know it's handy for us to use a container like scheduling, outhealing, etc. But when you try to make agile circles of CACD like this with containers for the ability, we need to design and manage infrastructure declaratively with Kubernetes manifest. That's where OpenShift comes in. We think the current best practice is GitOps. We'll have to introduce it later. Stay tuned. Okay, let's move on to the following as scalability. Suppose you build a service on premise at each location. In the case, you need to manage project for each customer and each site. On the other hand, even if you provide cloud services, you still need to take care of the network and the security. These things are nothing to do with developing AI itself, right? Don't you think it's considerable burden for ISPs? They can control customer sites all over the country at once by fMIC. Do you want to fly 200 miles far away just to install the Edge machine? Do you want to run to POC places for every single application update? Do you want to bring the Edge machine back to your office and update them manually? It's scheduling for on-site visits. Not really what you should do. And the only way to scale your business is to leave everything from AI development to fMIC. There's no reason not to use fMIC. Okay, last as sustainability. Even after the POC finally starts, there's still many problems like this. Service spaces, GPU resources, heat, getting unplugged, and on-site maintenance. That's different to your office, of course, when ISPs want to keep scaling their service agilely. Okay, how about outsource all the rivally and field operation issues to entities in fMIC? You can get the sustainability for scaling the AI businesses. We can organize the maintenance work after selling the AI. That's because our one strong point is an ecosystem which supports the local community that we have cultivated as a regional telecommunications carrier. You can focus on enhancing your AI applications by letting entities handle the field work, which is heavy burden for both systems and costs. As you know, fMIC has three keys to support ISPs perfectly. We've already received inquiries from many IVA ISPs. And they've already started POC with customers on fMIC platform. Today, let me show you use cases in regular markets. Let me introduce a use case of a trial company, Fukuoka Japan-based, that runs grocery stores nationwide. They've started using RSI's behavior analysis technology in their stores. Let me explain you the background first. Generally speaking, the retail industry in Japan is suffering from a chronic workforce shortage. Moreover, they have to take many COVID-19 measures, such as social distancing, temperature checks, disinfections, and setting up petitions. Hiring new people, it's not a practical way to solve the problem of workforce shortage. That's why we need to keep introducing AI to take place what people originally do. If customer service declines, so will profit. So we've introduced customer behavior to reduction in AI in cosmetic areas where trial company wants to reinforce customer reality. It knaves for store clerks to find a very easily high-agency and engaged customer with notification from their smartphones. It's possible to find out potential loyal customers and use it as a warning to deter shoplifting as well. It's a way to suggest the best method to serve customers so that the clerks can do it effectively with the least amount of operation. This is the use case of increased sales and steady decrease in shoplifting, as shown by the highly satisfactory customer services. IVAI introduced here can be a customer service support tool to solve work for shortage. Okay, now is the time to wrap that handover. NTTFMAC is a combination of the customer's existing cameras and teaching management services and the ISV's AI application. ISV can use this architecture as the minimum configuration. We realize the integration of SaaS-based AI applications, secure high bandwidth FMIC, and existing cameras. Customers can start AI analysis in the amount they want to use with cameras all they have without new system integration. Next, Red Hat will show you container-based GPU optimization that provides managed capabilities of application deployment and supports easy integration with ISV development environments. Thank you all, thank you. Okay, let me dive into the technology for NTTFMAC AI platform furthermore to see key points of their new AI service planned to release this summer. This slide shows the example for the IVAI, Intelligent Video Analytics Service. Typical traditional AI service needed embedded GPU IP camera for the single customer to deliver the single AI service. As Hashimoto-san mentioned, NTTFS allows partner and customer many type of AI workload on the opposite GPU MEC platform at regional aggregation edge. The customer can deploy simple IP camera to get multiple AI services. So, single IP camera can be leveraged for many IVAI services such as shop lifting detection AI service, face recognition AI service, people flow analysis AI, and behavior analysis AI. It's more economic way delivering the right service to meet each of customer demand. Also, NTTFS is transforming the service delivery method through GitOps practice. That I'll tell you later. IVA business partner just deployed their post processing application so that they can deliver AI service with GitOps on the NTTFS MEC AI platform running OpenShift and GPU. NTTFS provides common service elements including RTSP client application port and AI workload port to each IVA business partner in each project name space on OpenShift GPU MEC platform. Each IP camera is an RTSP server and RTSP client content application on OpenShift GPU MEC platform can connect to each specific RTSP server of IP camera to collect video image by assigning RTSP URL address in OpenShift config map. And each IVA partner runs AI workload in each project name space to analyze collected video image on AI inference engine to get inference result data so that each IVA partner runs their post processing application for their IVA business. How can NTTFS share GPU resource with each IVA partner? Well, we have NVIDIA GPU operator technology to allocate designate GPU resource to each AI workload on OpenShift MEC platform. NVIDIA GPU operator enables OpenShift to schedule AI workload that requires use of GPUs. In order to expose what feature and device each node needs, we first need to deploy node feature discovery, NVIDIA operator. Once NVIDIA operator deploy, NVIDIA operator recognize GPU and labels node. Then the GPU operator is deployed to enable OpenShift to schedule each AI workload that requires GPU resource. The GPU operator automatically installs four types of the content in the name space called GPU operator resource, cryo-prugin-demo set, NVIDIA driver-demo set, NVIDIA device-prugin-demo set and node-exporter-demo set. Cryo-prugin-demo set works on the NVIDIA GPU content runtime via Kubernetes standard cryo. NVIDIA driver-demo set is to enable the CUDA driver. NVIDIA device-prugin-demo set is an important part to allow the AI workload request GPU resource to run the GPU enabled part. In this example, you can see that making requests of one NVIDIA GPU that OpenShift will expose to the AI workload. NVIDIA node-exporter is to run the DCGM data center GPU manager to expose node-level information monitoring to Prometheus. NVIDIA GPU operator is already released in the OpenShift operator hub. GPU operator for OpenShift will help to simplify and accelerate computing business machine running or deep-running modeling tasks for data scientists. Adlers have running inference tasks across NVIDIA's Mac AI platforms. Lastly, before handing over to the U.S. team, I'd like to highlight one more unique point in NVIDIA's cloud-net Mac AI platform, which is GitOps. NVIDIA is now working on the GitOps practice for finding the way to new continuous delivery on OpenShift Mac AI platform. The application is packaged in the container image and automated testing and deployment. In order for smooth delivery together with the partner and the customer, current best practice they found is GitOps that Kubernetes committee is already doing. GitOps is a set of practice to use Git pull request to manage infrastructure and application configuration. Git repository in the GitOps is considered only the source of the tool and contained entire state of the system so that state of change to the system state are visible and audible. In this deployment scenario, the partner is keeping its own CI pipeline and submitting the PR pull request through the deployment Git for deployment repository when they need update application with manifest file. The application is deployed in the NVIDIA East staging environment for testing and then will be deployed in the NVIDIA East production environment under the same CD pipeline if the test was successful. So they are now following GitOps principle in the GitOps principle configuration system can be treated as code so they store it and have it automatically manage the version in the deployment Git that way they can roll out and roll back change in the system in the easy way. Using Git pull request they can manage in the easy way how change is applied to the store the configuration. On top of that they can leverage Git security mechanism in the order to ensure the ownership so they don't need to share their cluster credential with anyone. The person committing that change only needs access to the deployment Git repository where the configuration is stored. They only need software that makes sure no configuration drift are present. Let us recently released a new OpenShift GitOps tool adapting ROCD for operators along with the new OpenShift pipeline tool adapting Tecton for application developers. We improved GitOps to carrier-grade oriented system furthermore with OpenShift GitOps for the next step. That's all from my side. Wow, that was a lot of information. Let's recap. NTPE has created and is ready to deploy a cloud-native MEC AI platform at aggregation edge sites to deliver various services over their 5-to-the-home footprint of regional edge with interconnected wide area. They use the latest technologies from Red Hat OpenShift Container Platform and embedded GPUs to build their new MEC platform with GitOps practice to help accelerate their customers' digital transformation. This innovative platform enables rapid co-creation projects with partners and customers by turning each IP camera into a target for leveraging various AI services. NTPE shared a retail use case with trial where it improved in-store customer service in a year-over-year sales increase of 105% and 30% reduction in losses. Alright, and I think with that we conclude this session. But just before we go, I would like to share some other Red Hat related sessions we have at GTC. Some might be relevant for you. A lot of good content there. And in addition to this Red Hat related sessions, there are a lot of good content regarding related to EGX, NVIDIA EGX, Metropolis, CloudXR, Aero and many others. So with that, I would really like to thank NTPE and Red Hat for this session and also thank you all of you for your time. And I hope you enjoy GTC. Until next time.