 Hi, my name is Yasui Miyagawa, PTR of TACA project. It's a project update of TACA in yoga. So I'd like to introduce a project with highlights and next plans in that race. TACA is a VNF manager, generic VNF manager more specifically. VNF is for virtual network function and it is deployed as a dedicated network function as a component of complex network service system. There are several requirements of NFVs and NFVs VNF managers such as durability, availability or performance for realizing high qualified network services. For the purpose of providing carrier-grade network services it's NFV has contributed to define its standards. Top-left diagram is an overview of relationship of entities in its NFV standards. TACA has developed originally as a set of NFV orchestrator and VNF manager. Both of them are responsible for managing VNF. Although we have more focusing more on VNF manager. VNF manager is the central part of the features of managing VNF's managing life cycle of VNFs. For example, instantiate terminate who are outfilled them or so. And bottom-right is an overview of implementation of TACA. It consists of two processes, TACA server and TACA conductor. TACA server behaves as an endpoint of API request for calling back-end services. And TACA conductor is a core of services. You can request TACA to deploy virtual machines or containers as VNFs on TACA and Kubernetes via its NFV standards APIs by using TACA. So project background. So TACA was founded during Grizzly release. We had 19 contributors in yoga from several carriers and vendors. NTT, Fujitsu, NHG, KDD and so on as described in the diagrams. In addition to contributions for OpenStack, our team has developed relationship with standard groups. We are building alliances with its NFV and ORAN software communication for providing sophisticated software and its specifications for covering wide-range services from legacy to the latest 5GNC. So here is a highlight of new features in TACA for yoga release. First one is multi-API support for its NFV specifications. Its NFV specifications have been developed for several years and had two major versions named as version one and version two. As a recommend from operators, both versions should be supported because they have been running long lifetime services while introducing the latest services for users' demands. So TACA has introduced multi-version mechanism and implemented both of V1 and V2 APIs for supporting such a recommend. The APIs provide features for failure management here or ritual operation for high availability. It also provides and change current weakness package feature for rolling update. And second one is persistent volumes for Kubernetes cluster support with TACA's management driver. And next one is multi-tenant policy management for operators for their deployment strategies. This feature enables users to separate resources such as VMs, VNF packages and virtualizing network function lifecycle management interface related to VNF management concern tenants and Ansible driver for configuration of VNF deployment. TACA has provided configuration of deployment by using a shared script called as a user data but it's not enough for some more complex use cases. So this feature is to support such a use case with Ansible. And last one is introduce robot framework and for automation test of its NLV TAC. It's automated testing framework defined in Etsy NLV TAC group for keeping highly interoperability among components. These tests run on the set of test scenarios of functional test. And finally, I'd like to show features development brands for that reason. The feature of acceleration for VNF and CNF is for support VNF using hardware acceleration such as GPU, FPGA, ASIC. It's expected to be more important in five-digit error. And next CNF outfilling with Prometheus is for enhancement of LSM operations for outfilling or auto-scaling with Prometheus. And we are also going to provide highly availability to TACA itself. So now TACA is deployed as a single entity and not considered as recovering from failure without resorting by system decurrently. This feature is for the recovering, introducing some deployment options for a high availability such as act standby or enact model. And last one is for improvement of test coverage for quality of our products. Yeah, that's all. Thanks for watching.