 Welcome to visit our booth today. We will show you the OVP test automation die-offs in our demo. As you know, the test process of traditional network elements, equipment, or system can be abstracted into four steps. Test topology design, test environment construction, test task execution, and the test result analysis. Each step requires cross-organizational coordination, manual statistics, and signature confirmation. Take the network element access test as an example. It usually takes about six months to get a new or renewed network access license before going online. Also, with the introduction of open source components and software layered decoupling in FV networks, the frequency of software upgrades and new service introduction increase. This makes tests become more complex and frequent. In order to reduce the test costs and import test efficiency, it is urgent to introduce their automated tools. In order to cope with about changes and solve the problems in traditional testing, it is expected that corresponding automation tools should be introduced in each test step to build the common FV automated test platform, realizing automatic test design, automatic deployment of test environments, automatic execution of test tasks, and automatic analysis and certification of test results. Finally, build complete end-to-end test setups to improve test efficiency and test accuracy. Also, based on the result of automated testing, we can build the self-service certification FV style. We believe that it will be an important means to cope with operators' open business ecosystem, such as 5G plus AI and 5G plus Edge. In order to achieve about goals, we do the function MyPim with OAP and ONAP. You can see from this picture, ONAP can cover most functions of automated tools. We can leverage SDC to design test topology using RxTreater components such as SO, VFC, FC to deploy the test environment, VTP to execute the test task, and collect the test reports. OAP also can provide the test result analysis and certifications. Here shows the true-based VNF testing workflow. In this process, three types of rules are involved. Test designer, test case developer, and the test executor. The overall input of this workflow is test specification. First, the test designer is responsible for the test topology design, which includes the test object, test tools, and network between the SDC based on the test specification, and upload test topology to RxTreater. Second, test case developer implements the required test case-based test topology design by a test designer and admit it with VTP. And the third, test executor is responsible for test task execution in test task management system. The basic execution unit of the test task management system is the test job. A single job can contain one or more test keys. In addition to the task management function, it also provides the test environments, tools, object registration, test definition, and test job monitoring, and other functions. The test case executor process will first interact with on-app executor to complete the deployment of the test environment, and then use the capability of third-party instrument to assist in completing the overall testing and collect the test result. Finally, the tested object then passes the test can enter the VNF marketplace automatically. Next, I will demonstrate the process of VNF entering the testing according to different rules. In this demo, we will use OpenWRT, which is an open source gateway as the tested object, and I use SDC Wave from Sprint as the virtual test instrument to complete bidirectional traffic forwarding test. First, test designer designs a test topology in SDC. Before you design the test topology, you should upload the SEOT VNF and the test instrument to SDC first. What we see here is the topology we designed in advance. In this topology, it contains three VNFs. One is SEOT VNF, the other two are the virtual test instruments, connected across one management network and two network for testing. We can also initial the network details and VNF information in SDC. After design, you can test and distribute this topology to on-app executor. Next step, we need to develop the test script and the test definition YAML file and look them really keeping. Here you see is the test case definition YAML, which is modeled with test case description input and output and also specifies the shell execution script. The test script is used to deploy the testing environment and the test data with simulated traffic. The steps involved are first set up cloud and subscription detail. Second, deploy the testing environment to use an on-app administrator. Third, generate the traffic deployed when as finally clean up the test environment. After the both steps, the test executor can trigger the real test. In this system, tested executor should register the related environment before the test is actually executed. You can register VNFM manual here. Now, the system only supports on-app type manual registration. In addition to the test environment, the test object and the test tools also need to be registered in the system. Here you see we have registered the SCOT OpenWRT and also the test instrument STCV. In the test specification environment, you will see all the specifications and the test case system supports. Click on the test specification, you will see all the test cases. We can also choose to enable or disable one test case. Once the test case is disabled, it shouldn't be displayed when you create a test task. You can also create your own test specification. As needed, when you choose the SCOT type or the test case supported for this SCOT will be listed. You can choose all parts of them to create your own specification. Then we can create a test job and execute. When you create the test job, you will see all the required information you should fill in. For compliance testing, we didn't rely on any environment, so we can skip the environment selection to choose test case directory. And then the test job has been created and we can start it. And in this page, you can monitor the execution process and status. Once the test is executed successfully, it will show one link here, which means you can upload the test VINF to the certified marketplace. Of course, you can download the test report. This report contains more execution information. For the VINF traffic forwarding test, because it involves VINF installation and dilation, the testing takes about 20 minutes, so we will use a task that has been performed before to illustrate. In this test job, we use the environment we registered before. We can also set the test case input parameters here, such as the SUUID, which should be consistent with the topology ID in SDC. Let's check the test status. In addition to the overall status of the test case, you can also see all the test steps it involves. Currently, we can also get some basic statistics of the system on the dashboard. Okay, about is all the demo content. If you are interested in our demo and have more questions, welcome to contact us. Thank you.