1. The WindRiver OpenStack VIM is configured with tenant information and provider networks
2. The WindRiver OpenStack VIM services (console, auth, neutron, image, glance, etc) are accessible from ONAP by IP

1. Add VIM from ONAP GUI with VIM location information, tenant authentication information
2. VIM default service url can be configured based on real VIM settings

1. VIM

1. is registered successfully
2. Tenant authentication information is stored correctly

1. The VMWare OpenStack VIM is configured with tenant information and provider networks
2. The VMWare OpenStack VIM services (console, auth, neutron, image, glance, etc) are accessible from ONAP by IP

1. Add VIM from ONAP GUI with VIM location information, tenant authentication information
2. VIM default service url can be configured based on real VIM settings

1. VIM

1. is registered successfully
2. Tenant authentication information is stored correctly

1. Each DC gateway has been manually installed and configured correctly
2. Each DC gateway local controller has been manually installed and configured correctly

1. Register each DC gateway local controller from ONAP ESR GUI with the needed information (location, IP, port, authentication information, etc)

1. The DC local controller is registered successfully
2. The DC local controller information is stored correctly

1. Each PE router has been manually installed and configured correctly
2. SDN WAN controller has been manually installed and configured correctly
3. All PEs are managed by SDN WAN Controller

1. Register SDN WAN controller from ONAP ESR GUI with the needed information (IP, port, authentication information, etc)

1. The SDN WAN controller is registered successfully
2. SDN WAN controller information is stored correctly

1. All VNF vendors' SVNFMs have been installed and configured

1. Register all VNF vendors' SVNFMs using ONAP ESR GUI with the needed information (IP, port, authentication information, etc)

1. All SVNFMs are registered successfully with ONAP
2. All SVNFM information is stored correctly in ONAP

1. All VNF vendor's EMS have been installed and configured

1. Register all vendors' EMSs using ONAP ESR GUI with the needed information (IP, port, authentication information, etc)

1. All EMSs are registered successfully with ONAP
2. All EMSs information is stored correctly in ONAP

1. All vIMS

1. VNFD csar files can pass VNFSDK checking
2. All vIMS VNFs have been onboarded
3. All VNFs images files have been uploaded manually into ONAP

1. In SDC create vIMS service with the following VNFs
   1. vPCSCF
   2. vI/SCSCF
   3. vTAS
2. As part of vIMS service composition, create Virtual Links (VL) to connect the VNFs together according to vIMS service design

1. vIMS service is created successfully
2. vnfmInfo is correctly pointed to vendor's

1. SVNFM
2. vIMS service is successfully stored in catalog

1. WAN underlay network template (.yaml) has been defined and packaged in a CSAR file
2. WAN overlay network template (.yaml) has been defined and packaged in a CSAR file

1. In SDC create

1. a VL resource and upload WAN underlay network CSAR file. Make sure controllerInfo property is set to SDNC in the template
2. In SDC create a VL resource and upload WAN overlay network CSAR file. Make sure controllerInfo property is set to SDNC

1. WAN underlay network resource onboarded successfully and shown in catalog
2. WAN overlay network resource onboarded successfully and shown in catalog

This test uses CLAMP to configure closed loop for VoLTE. There are 4 configurations:

1. Provisional rules for Policy
2. Correlation rules for Holmes
3. Holmes microservice Blueprint for DCAE
4. VES configuration (in R1, there is no configuration needed)

1. DCAE template has been imported (R1 SDC doesn't support DCAE template design)
2. Holmes blueprint has been imported
3. Holmes correlation rules have been defined

1. In CLAMP, choose

1. VNF SPGW and events (VNF Fault and

1. VM Fault) to monitor
2. Bring up CLAMP configuration policy GUI and copy Holmes correlation rules in it
3. Bring up CLAMP provisional policy GUI and define

1. healing provisional policy
2. Save the configuration

1. Closed loop template and blueprint for Holmes are distributed to DCAE
2. Configuration policy has been distributed to DCAE
3. Provisional policy has been distributed to Policy engine

1. All external systems (VIM, SDN WAN controller, SDN local controller, vendors SVNFM and EMS) have registered with ESR
2. VoLTE service has been created, V00011 has passed
3. Closed loop has been configured, V00012 has passed
4. PEs have been configured and integrated with corresponding SDN WAN controller
5. DC GWs have been configured and integrated with corresponding SDN local controller
6. EVPN VXLAN tunnel has been set up manually between edge and core DC gateway. At this moment, underlay network between PEs has not been set up yet, so EVPN and VXLAN tunnel is configured but may not be working, but it's ok.
7. Install a web server in core data center

1. ONAP user

1. logins Usecase UI GUI

2. Usecase UI will guide the user to

1. fill in

1. or verify all needed parameters for vEPC, vIMS, WAN underlay and overlay
2. User will click a button to deploy VoLTE service

1. vEPC service is instantiated successfully, including all vEPC VNFs and VLs
2. vIMS service is instantiated successfully, including all vIMS VNFs and VLs
3. WAN service is instantiated successfully, including underlay and overlay networks
4. Holmes analytics container is brought up correctly by DCAE
5. Client UE can access network through mobile network, e.g. access the web server

1. VoLTE service has been instantiated
2. Closed loop for VoLTE has been configured and started

1. ONAP user uses Usecase UI GUI to check system performance, such as CPU, memory and disk usage
2. ONAP user views the VNF alarms collected by ONAP

1. System performance (including system CPU, memory and disk usage) is shown on ONAP Usecase UI GUI
2. VNF alarms, specified in CLAMP for the closed loop, are shown in Usecase UI GUI

1. VoLTE service has been instantiated
2. VoLTE closed loop has been configured and started
3. SPGW VNF supports event generation
4. VNF guest OS supports event generation
5. MultiVIM supports event collection from guest OS and event forwarding

1. Manually shutdown standby MPU VM inside SPGW VNF. This should trigger the VNF and VIM to generate alarms

1. EMS collects standby MPU offline event from SPGW VNF and sends the event to VFC
2. MultiVIM doesn't receive heartbeat event from standby MPU guest OS for a period of time and triggers alarm which is sent to DCAE VES collector
3. Holmes receives MPU offline events
4. Holmes receives MPU guest OS heartbeat missing events
5. Holmes does correlation of the two types of events and generate one signature event and sends it to Policy
6. Policy triggers provisional policy and

1. healing action is sent to VFC
2. VFC uses

1. SVNFM driver to

1. heal standby MPU VM
2. Standby MPU is

1. healed
2. Clear event is sent from SPGW VNF about standby MPU back online
3. Heartbeat from standby MPU VM is received by MultiVIM and clear event is sent by MultiVIM about heartbeat recovery
4. Holmes does the event correlation and sends Clear signature event to Policy
5. Policy stops the

1. healing action