 Hi everyone. Thank you very much for viewing our presentation. Today we will talk the challenges of network operator in transforming your infrastructure. And also we will introduce OpenStack Typecast approach to this challenge. Firstly, we introduce our speakers and this presentation agenda. In this presentation, we will speak by three speakers who belong to three different companies. First speaker, I'm Hirsu Tsuji from KTDI. I will speak in part one and part three about the challenges of network operator and introduce our case example for Tucker. Second speaker is Ogawa-san. He is Tucker PTR and belong to NTT Laboratories. Ogawa-san will talk about current OpenStack Tucker committee status in second part. Final speaker is Takashi-san. He is Tucker Core Developer and belong to NAC Corporation. Takashi-san will talk about collaboration with HNFB as implementation case example in final part. In first part, we will show some challenges of network operator. Today's speaker, entity group and KTDI is competitor. In Japanese mobile phone market share, NTT.com have about 40% share and KTDI have about 30% share. However, we have same challenges as a network operator. There are two challenges about controlization and manage vendor integration. Controlization cannot be avoided. However, we think virtualization will not go away soon. This reason is simple. We still ongoing to transform to virtualization. In addition, some network function not suitable for controlization such as user play network function and regression application. So, we need to operate network to define type of technologies together. Next second challenge is about much vendor integration. Thanks to standardization and open source technologies, it was accelerated. However, because of NAC architecture, it is increasing that's integration cost and verification cost, especially clearly shown around BNN manager. This reason maybe due to it has many interface is BNN and there are some implementation option in standard about BNN. And many BNN vendor is not comply with standard and also of course standard is not comply with. Besides, we need maintain higher service level so we cannot cut corner in that specification. OpenStackTack community is trying to solve these challenges as an open source generic BNN. For challenge number one, NACA is growing to adapt many environment and technologies such as CNN and BNN. So, we will introduce of TACA project updates in Victoria from Ogawa-san. For challenge number two, TACA is trying to solve with open implementation and standardization. We will introduce two specific case example from me and from TACA-san. Hi, my name is Yasun Yagawa from entity network services and laboratories. So, I would like to introduce our TACA project for realising our challenges. So, why TACA? Development of TACA was started about six years ago from 2040 by Newton guys for implementing NFV orchestrator and VNF manager on OpenStack infrastructure. Now, implementation of TACA becomes mature. We are focusing on provide its NFV standard based VNF manager and NFV orchestrator as main component of NFV. For TACA, several network vendors and operators such as NAC will get 99 crowd in there and so on. We sit here, have joined to development. We have implemented our requirements for realising commercial service on TACA. So, here is OpenStack TACA. It is an official project and OpenStack for providing features for VNF manager and NFV orchestrator. One of the main features of TACA is orchestrating virtualized infrastructure, especially for telephone. It is also including physical infrastructure. NFV all in TACA cooperate with OSS, VSS, VNF manager and VIM. VIM means virtual infrastructure manager responsible for controlling computing results. OpenStack or Kubernetes in this context. And OSS is for operational support system and VSS is for business support system. On the other hand, VNF manager has responsibility for managing VNF as named. So, here is a use case example of TACA. 5G Core weighs containerized VNF. We are expecting that some of the main network functions on 5G Core network will be deployed as containerized applications. So, mixed virtual machine and container environment more exactly. So, this diagram showed that VEPC, VIMS or 5GC containers managed from TACA with OpenStack and Kubernetes. We started to implement container support before OSS and more focusing on from Victoria. In its NFV standard, it's also started to discuss how to deploy network applications and services with container infrastructure service management. So, as Tsuri-san told in KTTI's requirements, much vendor support for VNF manager is one of the top priority for their requirements. So, it is not only for KTTI but also other operators. For meeting such a requirements, we have implemented TACA's design and implementation to provide standardized features of its NFV. It is including the latest ongoing requirements such as quality support or a new testing schema called as Robot Framework. It is so challenging. So, here is a list of proposal specs in the previous VPDG related to its NFV standard. For example, lifecycle management, LGM, notification, scaling, operation and so on. So, some of them are already raised in Victoria but not completed yet or yet, especially Kubernetes support and Robot Framework just started actually. So, we will continue to develop these features and make proposals for its NFV in the next wannabe release. So, as the last part of my session, I'd like to talk about our community shortly. TACA is not so large community actually but still growing. We have accepted 141 patches for TACA and its family in Victoria and it is 37% increased comparing with U3. The number of active contributors is also increased. In Victoria, we have 26 contributors for proposing patches and more for living from NAC, Fujitsu, DNC or SON. Fujitsu was joined to TACA again from Victoria. So, this is TACA's highlights feature released in Victoria. First one is for its NFV standard features. We have several features listed here but some features are not completed yet and it's still going on. And second one is Phoenix support in TACA from DNC. Phoenix is an open stack project for providing maintenance update, upgrade and scaling operations for their downtime services. We have implemented Phoenix Proving in TACA to enable users to use these functions. And final one is for Kubernetes support. TACA has Kubernetes support but not so mature actually. So, this update is to add a feature to support to load Kubernetes objects file from artifact specified in additional problems in and additional Kubernetes objects specified in Kubernetes resource and kind support. So, we will provide more sophisticated features required for generic NFM and NFVO in TACA as defect implementation. Thanks. Here, we will tell you about the case example TACA used in commercial service network by KDDI. Before talk about case example, I introduced my company KDDI. KDDI is fixed and mobile network operator in Japan and our fixed and mobile subscriber is totally over 16 million. And now, we adopt to TACA as open source generic BNM for fixed BNM system. Lastly, we describe background of adopt to TACA. Today, KDDI is operating another BNM manager. It is vendor specific BNM manager. Thus, BNM manager is too much to us. It has so many functions but we did not use all of them. However, it has no flexibility at interfaces and we had been in many trouble related that complex architecture. KDDI realize that it is needed some simple and small BNM manager. So, we think TACA can solve this pain. Why TACA can solve it? TACA have four benefits for network operator. First, it is lightweight BNM manager. TACA round just a single gate repository. Second, it is comprised to HCNFV standard. In other words, it have enough capability to connect other NLV system. Third, it is open source software. You know, open source software is not depend any specific vendor and any specific operator's environment. So, BNM vendor can integrate BNM to TACA itself and also can test themselves. Fourth, it is OpenStack project. In NLV, OpenStack is most popular solution for LFBI and BIN. So, we can share the knowledge to operating OpenStack, both BNM manager and VIN LFBI. It can reduce the learning cost for operators. In addition, one factor push to our design. TACA can use HOT sheet orchestration template as VRD virtualized resource descriptor. It was expected that use much vendor integration cost and verification cost. Because VIN vendor can verify VI-VNM interface themselves without VINM manager. And also, HOT is more popular and more flexible than TOSCAP BNM. However, TACA is not perfect. We found something missing in TACA by compare between TACA upstream code and our commercial use case. But we did not enough resource to fill this gap. It was a hard problem to KDDI. So, we decided to get help from NEC to fill the gaps together. NEC is one of most active TACA contributors and also NEC is KDDI long-time partner. KDDI provides use case of commercialization and NEC provides software development and upstreaming. And both KDDI and NEC provide commercial level test. Some of the achievements are now on upstream. For one example, TACA has issued to use multi-deployment player with HOT due to a bug. The bug was found in a discussion between KDDI and NEC. And now the patch was provided to upstream by NEC. On the case, in commercial system, neither consideration of abnormal case. In LCHM operation of abnormal case was not implemented in TACA. KDDI and NEC discussed its best KDDI operation policy. As a result, it was implemented and patch available in OpenStack, OpenStack TACA upstream too. Hello, my name is Toshiyaki Takahashi from NEC and the developer of OpenStack TACA. Today, I'd like to introduce collaboration with EtsyNFB. First, NEC proceeds to enhance the quality of TACA for telecom operators such as KDDI. Quality means, for example, proper NNV compliance or product high quality. That means a few bugs. But in my opinion, it is not efficient that one community proceeds with these activities on its own. For example, in the case of standards, it is very important not only to just reference, but also to give feedback from us or discussion with standards organization. So we suggest the importance of such collaboration. And this time, we focused on the working group called EtsyNFB TST. This is the NNV working group, which is creating NNV compliance test specification and test code. I believe that collaboration with TST will help us to achieve our goals. Okay, this is the whole picture of the collaboration, which I propose to EtsyNFB TST. NNV is promoting the release of API schema using OpenAPI. And the test code using the test framework called robot framework. Using this, the product community can ensure that the product is standard compliance. And in other words, ensure that the product can connect with other third party products. But I think the standard organization is not sure whether these tests can really work for real products, especially commercial products. Because focusing on the product or implementation is out of scope of standards. So we, Takochim, will use these test codes and give feedback to TST. So we can improve the TST test code with such feedback from product or implementation perspectives. And Takah will use improved test code again and NNV compliance with such improved test code. We aim to make such a good cycle. Okay, so why do we collaborate with TST? Because there are many benefits from each other. And those benefits are continuous benefits. First, for Etsy, improving the test can accelerate interoperability. And it is its main purpose. And the feedback from the implementation perspective will also lead to feasibility of the specification. Next is for Takah. First, we have a very simple reason. We can achieve automated API test code. And the next is we can strongly declare the NNV compliance. If Takochim make compliance test, they may contain our own understanding and which may be incorrect. So we should use a test code created by Etsy NNV. Finally, we have the same purpose as Etsy, as that is promoting interoperability with other products. Based on such background, we have started the very detailed and the concrete discussions with TST. First is test coverage. Of course, we should increase test coverage, but covering all is too difficult to implement. So now we have started to discuss what is important for standards and product development. Next is how to identify the TST code. And that is in other words, version control. So of course, both of Etsy side and Takah side have different version control. So we should discuss how to manage each version or we should discuss the relationship between two teams version. Finally, I asked TST members to write such clear description in the specification document. For proper collaboration, information should be shared in official document. Of course, Takah will also publish the information as well. These activities will lead to the realization of the automated API testing. And this automated API test can be useful for both standards and product development. This is the current Takah's development activity. And I'd like to introduce a little details work. First of all, we have started to create a system to simply download some specific code from Etsy repository and execute it in zoo environment. And the first target is API conformance testing that is called TST 10. However, we face small issues. This is one example. So how to implement the preconditions. Etsy and FB has defined the specification of preconditions, but does not implement preconditions. And the problem is preconditions are different for each API. So implementation and the maintenance is a little hard work. Therefore, we should discuss who and how maintains the preconditions. Who means Etsy or Takah? And how means one option is make all preconditions implementation and maintain. And another option is make some scenarios. And maintain scenario is a good way, but of course, scenario are not defined yet. So we need some additional work. Anyway, I'll make it an agenda for the next discussion with TST. Okay, so this is next step. So we plan to expand our activity in the future. First, we will complete automated API testing. Ideal goal is to be able to test by just downloading Etsy code and use some supported API list of Takah. And heavy test code is continuously improved. And the Takah continue to develop to support many APIs. And those changes should be reflected to test with minimal effort. So we want to just use TST code and Takah support list. But in order to achieve it, we need to continue to consider many things such as what we talked about today. So we will continue to discuss with TST. And the TST scope is not only API conformance. So we plan to expand our activities as well. Okay, that's all. So today, KDDR introduced the challenges as network operators. And we introduced Takah as open source generate BNFM to solve such challenges. And we also introduced Takah's growth by activities of many companies. Of course, we will continue to search activities. For example, enhance NFB compliance or have active discussion and active collaboration with NFB. We will discuss not only testing, but also specification itself. And finally, we think enrichment of samples and documents is very important to get many introductions. Okay, so that's all. I hope that everyone will use Takah and participate in Takah community activities. Thank you very much.