diff --git a/docs/installation_guide.md b/docs/installation_guide.md
index 7523866..a28d4ac 100644
--- a/docs/installation_guide.md
+++ b/docs/installation_guide.md
@@ -4,38 +4,21 @@
 
 ## Hardware Requirements
 
-M-CORD by default uses the NG40 software emulator including the RAN, an MME,
-and a traffic generator. For this reason, it does not require any additional
-hardware, other than the ones listed for a “traditional” [CORD
+Beside  the ones listed for a “traditional” [CORD
 POD](/install_physical.md#bill-of-materials-bom--hardware-requirements).
+M-CORD 5.0 by default uses UE and standalone eNodeB hardware.
 
-> Warning: The NG40 vTester requires a compute node with Intel XEON CPU with
-> [Westmere microarchitecture or
+> Warning: The NGIC requires a compute node with Intel XEON CPU with
+> [Haswell microarchitecture or
 > better](https://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures).
-
-## NG40 vTester M-CORD License
-
-As mentioned above, ng4T provides a limited version of its NG40 software, which
-requires a free license in order to work. The specific NG40 installation steps
-described in the next paragraph assume the Operator has obtained the license
-and saved it into  a specific location on the development server.
-
-In order to download a free M-CORD trial license, go to the [NG40 M-CORD
-website](https://mcord.ng40.com/) and register. You will be asked for your
-company name and your company email. After successful authentication of your
-email and acknowledgment of the free M-CORD NG40 License, you can download the
-license file called `ng40-license`.
+> Note that 4.1 recommends at least `Westmere` microarchitecture but 5.0
+> highly recommend to use at least `Haswell` microarchitecture.
 
 ## M-CORD POD Installation
 
 To install the local node you should follow the steps described in the main
 [physical POD installation](/install_physical.md).
 
-As soon as you have the CORD repository on your development machine, transfer
-the downloaded M-CORD NG40 license file, to:
-
-`$CORD_ROOT/orchestration/xos_services/venb/xos/synchronizer/files/ng40-license`
-
 When it’s time to write your pod configuration, use the [physical-example.yml
 file as a
 template](https://github.com/opencord/cord/blob/master/podconfig/physical-example.yml).
@@ -44,7 +27,7 @@
 
 As cord_scenario, use `cord`.
 
-As cord_profile, use `mcord-ng40`.
+As cord_profile, use `mcord-cavium`.
 
 > Warning: After you’ve finished the basic installation, configure the fabric
 > and your computes, as described [here](/appendix_basic_config.md).
@@ -52,7 +35,7 @@
 ## Create an EPC instance
 
 The EPC is the only component that needs to be manually configured, after the
-fabric gets properly setup. An EPC instance can be created in two ways.
+fabric gets properly setup. An EPC instance can be created inside XOS-UI.
 
 ### Create an EPC instance using the XOS-UI
 
@@ -62,17 +45,10 @@
 * From the left panel, select `vEPC`
 * Click on `Virtual Evolved Packet Core ServiceInstances`
 * On the top right, press `Add`
-* Set `blueprint` to `MCORD 4.1`
-* Set `Owner id` to `vepc`
-* Set `Site id` to `MySite`
+* Set `blueprint` to `MCORD 5.0`
+* ......
 * Press `Save`
 
-### Create an EPC instance using the XOS northbound API
-
-```shell
-curl -u xosadmin@opencord.org:<password> -X POST http://<ip address of pod>/xosapi/v1/vepc/vepcserviceinstances -H "Content-Type: application/json" -d '{"blueprint":"build", "site_id": 1}'
-```
-
 ## Verify a Successful Installation
 
 To verify if the installation was successful, ssh into the head node and follow
@@ -81,10 +57,13 @@
 Verify that the service synchronizers are running.  Use the `docker ps` command
 on head node, you should be able to see the following M-CORD synchronizers:
 
-* mcordng40_venb-synchronizer_1
-* mcordng40_vspgwc-synchronizer_1
-* mcordng40_vspgwu-synchronizer_1
-* mcordng40_vepc-synchronizer_1
+* mcordcavium_vspgwc-synchronizer_1
+* mcordcavium_vspgwu-synchronizer_1
+* mcordcavium_hssdb-synchronizer_1
+* mcordcavium_vhss-synchronizer_1
+* mcordcavium_vmme-synchronizer_1
+* mcordcavium_internetemulator-synchronizer_1
+* mcordcavium_vepc-synchronizer_1
 
 Check that the ServiceInstances are running on the head node. Run these
 commands on the head node:
@@ -97,13 +76,17 @@
 You should see three VMs like this:
 
 ```shell
-+--------------------------------------+-----------------+--------+------------+-------------+---------------------------------------------------------------------------------------------+
-| ID                                   | Name            | Status | Task State | Power State | Networks                                                                                    |
-+--------------------------------------+-----------------+--------+------------+-------------+---------------------------------------------------------------------------------------------+
-| 9d5d1d45-2ad8-48d5-84c5-b1dd02458f81 | mysite_venb-3   | ACTIVE | -          | Running     | s1u_network=111.0.0.2; sgi_network=115.0.0.2; management=172.27.0.4; s11_network=112.0.0.3  |
-| 797ec8e8-d456-405f-a656-194f5748902a | mysite_vspgwc-2 | ACTIVE | -          | Running     | management=172.27.0.2; spgw_network=117.0.0.2; s11_network=112.0.0.2                        |
-| 050393a3-ec25-4548-b02a-2d7b02b16943 | mysite_vspgwu-1 | ACTIVE | -          | Running     | s1u_network=111.0.0.3; sgi_network=115.0.0.3; management=172.27.0.3; spgw_network=117.0.0.3 |
-+--------------------------------------+-----------------+--------+------------+-------------+---------------------------------------------------------------------------------------------+
++--------------------------------------+---------------------------+---------+------------+-------------+-------------------------------------------------------------------------------------------------------------------------------------+
+| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                                            |
++--------------------------------------+---------------------------+---------+------------+-------------+-------------------------------------------------------------------------------------------------------------------------------------+
+| c9dc354f-e1b4-4900-9ccb-3d77dd4bdf45 | mysite_hssdb-12           | ACTIVE  | -          | Running     | management=172.27.0.9; db_network=121.0.0.2                                                                                         |
+| 82200b77-37d6-4fea-b98e-89f74646a90d | mysite_internetemulator-7 | ACTIVE  | -          | Running     | sgi_network=115.0.0.8; management=172.27.0.8                                                                                        |
+| 6b92f216-89b2-4e7e-8b49-277f1e92e448 | mysite_vhss-13            | ACTIVE  | -          | Running     | s6a_network=120.0.0.4; management=172.27.0.16; db_network=121.0.0.5                                                                 |
+| 1710892c-d5c5-4d65-9d7e-5b1aae435831 | mysite_vmme-15            | ACTIVE  | -          | Running     | s6a_network=120.0.0.5; flat_network_s1mme=118.0.0.3; management=172.27.0.17; s11_network=112.0.0.5; flat_network_s1mme_p4=122.0.0.2 |
+| 2e2c21d9-1e66-4425-b0ef-da90a204b7d5 | mysite_vspgwc-8           | ACTIVE  | -          | Running     | management=172.27.0.10; spgw_network=117.0.0.2; s11_network=112.0.0.2                                                               |
+| 70ebeb85-13c9-474d-97d0-ec40ad621281 | mysite_vspgwu-10          | ACTIVE  | -          | Running     | management=172.27.0.12; sgi_network=115.0.0.9; spgw_network=117.0.0.3; flat_network_s1u=119.0.0.2                                   |
++--------------------------------------+---------------------------+---------+------------+-------------+-------------------------------------------------------------------------------------------------------------------------------------+
+
 ```
 
 > Note: It may take a few minutes to provision the instances. If you don’t see
@@ -114,160 +97,12 @@
 * Log into the XOS GUI on the head node
 * In left panel, click on each item listed below and verify that there is a
   check mark sign under “backend status”
-    * Vspgwc, then Virtual Serving PDN Gateway -- Control Plane Service
-      Instances
-    * Vspgwu, then Virtual Serving Gateway User Plane Service Instances
-    * Venb, then Virtual eNodeB Service Instances
+    * Vspgwc, the Virtual Serving PDN Gateway -- Control Plane Service Instances
+    * Vspgwu, the Virtual Serving Gateway User Plane Service Instances
+    * Hssdb, the HSS Database ServiceInstances
+    * Vhss, the Virtual Home Subscriber Server Tenants
+    * Vmme, the Virtual Mobility Management Entity Service Instances
+    * Internetemulator, the Internet Emulator Service Instances
 
 > NOTE: It may take a few minutes to run the synchronizers.  If you don’t see a
 > check mark immediately, try again after some time.
-
-## Using the NG40 vTester Software
-
-You’re now ready to generate some traffic and test M-CORD. To proceed, do the
-following.
-
-* SSH into the NG40 VNF VM with username and password ng40/ng40. To understand
-  how to access your VNFs look
-  [here](troubleshooting.md#how-to-log-into-a-vnf-vm).
-* Run `~/verify_quick.sh`
-
-You should see the following output:
-
-```shell
-**** Load Profile Settings ****
-$pps = 1000
-$bps = 500000000
-……
-Signaling Table
-           AttUE     ActCTXT   BrReq     BrAct     RelRq     RelAc     ActS1
-ng40_ran_1 1         1         1         1         0         0         1
-User Plane Downlink Table
-           AS_PktTx      AS_EthTx      S1uEthRx      S1uPktRx
-ng40_ran_1 132           132           144           133
-User Plane Uplink Table
-           S1uPktTx      S1uEthTx      AS_EthRx      AS_PktRx
-ng40_ran_1 49            50            48            48
-Watchtime: 9 Timeout: 1800
-```
-
-Both the downlink and uplink should show packets counters increasing. The
-downlink shows packets flowing from the AS (Application Server) to the UE. The
-uplink shows packets going from the UE to the AS.
-
-The result for all commands should look like:
-
-```shell
-Verdict(tc_attach_www) = VERDICT_PASS
-**** Packet Loss ****
-DL Loss= AS_PktTx-S1uPktRx=     0(pkts); 0.00(%)
-UL Loss= S1uPktTx-AS_PktRx=     0(pkts); 0.00(%)
-```
-
-The verdict is configured to check the control plane only.
-
-For the user plane verification you see the absolute number and percentage of
-lost packets.
-
-There are multiple test commands available (You can get the parameter
-description with the flags -h or -?):
-
-* **verify_attach.sh**
-
-```shell
-Usage: ./verify_attach.sh [<UEs> [<rate>]]
-       UEs: Number of UEs 1..10, default 1
-       rate: Attach rate 1..10, default 1
-```
-
-Send only attach and detach.
-
-Used to verify basic control plane functionality.
-
-* **verify_attach_data.sh**
-
-```shell
-Usage: ./verify_attach_data.sh [<UEs> [<rate>]]
-       UEs: Number of UEs 1..10, default 1
-       rate: Attach rate 1..10, default 1
-```
-
-Send attach, detach and a few user plane packets.
-
-Used to verify basic user plane functionality.
-
-Downlink traffic will be sent without waiting for uplink traffic to arrive at
-the Application Server.
-
-* **verify_quick.sh**
-
-```shell
-Usage: ./verify_quick.sh [<UEs> [<rate> [<pps>]]]
-       UEs: Number of UEs 1..10, default 2
-       rate: Attach rate 1..10, default 1
-       pps: Packets per Second 1000..60000, default 1000
-```
-
-Send attach, detach and 1000 pps user plane. Userplane ramp up and down ~20
-seconds and total userplane transfer time ~70 seconds.
-
-500.000.000 bps (maximum bit rate to calculate packet size from pps setting,
-MTU 1450).
-
-Used for control plane and userplane verification with low load for a short
-time.
-
-Downlink traffic will only be send when uplink traffic arrives at the
-Application Server.
-
-* **verify_short.sh**
-
-```shell
-Usage: ./verify_short.sh [<UEs> [<rate> [<pps>]]]
-       UEs: Number of UEs 1..10, default 10
-       rate: Attach rate 1..10, default 5
-       pps: Packets per Second 1000..60000, default 60000
-```
-
-Send attach, detach and 60000 pps user plane. Userplane ramp up and down ~20
-seconds and total userplane transfer time ~70 seconds.
-
-500.000.000 bps (maximum bit rate to calculate packet size from pps setting,
-MTU 1450). Used for control plane and userplane verification with medium load
-for a short time. Downlink traffic will only be send when uplink traffic
-  arrives at the Application Server.
-
-* **verify_long.sh**
-
-```shell
-Usage: ./verify_long.sh [<UEs> [<rate> [<pps>]]]
-       UEs: Number of UEs 1..10, default 10
-       rate: Attach rate 1..10, default 5
-       pps: Packets per Second 1000..60000, default 60000
-```
-
-Send attach, detach and 60000 pps user plane. Userplane ramp up and down ~200
-seconds and total userplane transfer time ~700 seconds.
-
-500.000.000 bps (maximum bit rate to calculate packet size from pps setting,
-MTU 1450).
-
-Used for control plane and userplane verification with medium load for a longer
-time.
-
-Downlink traffic will only be send when uplink traffic arrives at the
-Application Server.
-
-### Request / Update the NG40 vTester Software License
-
-If you forgot to request an NG40 license at the beginning of the installation,
-or if you would like to extend it, you can input your updated license once the
-NG40 VM is up, following the steps below:
-
-SSH into the NG40 VNF VM with username and password ng40/ng40. To understand
-how to access your VNFs, look
-[here](/troubleshooting.md#how-to-log-into-a-vnf-vm).
-
-Add the license file with named `ng40-license` to the folder: `~/install/`
-Run the command `~/install/ng40init`.
-
diff --git a/docs/overview.md b/docs/overview.md
index 134dbd2..3b7ca07 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -1,6 +1,6 @@
 # Overview
 
-## What is M-CORD?
+## What is M-CORD
 
 M-CORD is a CORD use-case for mobile edge cloud. The architecture allows
 Service Providers to disaggregate both the RAN and the core, as well as to
@@ -168,32 +168,12 @@
 developed using data plane development kit (DPDK) version optimized for Intel
 Architecture.
 
+In this release 5.0, we also added MME, HSS, and HSS_DB as open source
+reference implementations.
+
 If you’re interested to know more and explore the EPC code, [see
 here](https://gerrit.opencord.org/#/admin/projects/ngic).
 
-## NG40 vTester software
-
-Within M-CORD, ng4T provides for free a limited version of its NG40 software.
-
-The free version:
-
-* Expires on the April 1st 2018
-* Emulates up to 1 eNB
-* Emulates up to 10 UE
-* Has 1 MME with an integrated HSS
-* Can connect up to 1 SPGW-C/U
-* Allows users to attach, detach and send user plane traffic
-* Support only standard Linux interfaces, no DPDK
-
-In order to use the NG40, the Operator will need to apply for a free NG40
-M-CORD license with ng4T at the beginning of the setup. Detailed steps can be
-found in the Installation section below in this guide.
-
-Full versions of the NG40 vTester can do much more than this. This requires
-users to apply for additional licenses. In order to apply for licenses, users
-will need to contact directly ng4T, using the email address `support@ng4t.com`.
-More details about the NG40 can be found at [their website](http://www.ng4t.com).
-
 ## XOS Service Graph
 
 XOS is CORD’s default orchestrator. It is described in detail in the XOS guide.
@@ -206,9 +186,9 @@
 
 XOS comes with a UI for instantiating and onboarding services, and creating
 service graphs. In the current implementation of M-CORD, the service graph
-shown in earlier sections has the following representation in XOS:
+has the following representation in XOS:
 
-![M-CORD XOS services wiring diagram](static/images/services_diagram.png)
+![M-CORD XOS services wiring diagram](static/images/service_graph-5.0.png)
 
 Instances of services are connected to each other in the data plane via private
 networks. On the orchestration side, they are connected via XOS-defined
@@ -237,9 +217,8 @@
 help configure instances of the service graph described in this document. The
 implementation of vEPC-as-a-Service contains a declarative description of the
 service graph in its config file,
-<https://github.com/opencord/epc-service/blob/cord-4.1/xos/synchronizer/vepc_config.yaml>.
-It is contained in an option called “blueprints.” While there is currently only
-one such blueprint graph, more may be added in the future.
+<https://github.com/opencord/epc-service/blob/cord-5.0/xos/synchronizer/vepc_config.yaml>.
+It is contained in an option called “blueprints”.
 
 In the blueprint graph, the network section configures the networks, and the
 graph section defines ServiceInstances and links them together via those
@@ -264,9 +243,9 @@
 synchronizers to translate them and make the service operational. Synchronizers
 are controllers that run in their own containers and react to changes in the
 data model to communicate those changes to the VNF in question. In the M-CORD
-setup, there are synchronizers for each of the services: vENB, vSPGWU, vSPGWC
-as well as vEPC-as-a-service. In addition, there are also synchronizers for the
-back-end components: OpenStack and ONOS.
+setup, there are synchronizers for each of the services: vENB, vMME, vHSS,
+vHSS_DB, vSPGWU, vSPGWC, as well as vEPC-as-a-service. In addition, there are
+also synchronizers for the back-end components: OpenStack and ONOS.
 
 There are two parts of a synchronizer: `model policies` and `sync steps`. Model
 Policies operate on the data model. vEPC-as-a-service is a good example of a
diff --git a/docs/static/images/service_graph-5.0.png b/docs/static/images/service_graph-5.0.png
new file mode 100644
index 0000000..23d13c0
--- /dev/null
+++ b/docs/static/images/service_graph-5.0.png
Binary files differ
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index 9a0c583..48ba576 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -10,11 +10,6 @@
 CORD troubleshooting guide, at in the main [troubleshooting
 section](/troubleshooting.md).
 
-The troubleshooting guide often mentions interfaces, IPs and networks. For
-reference, you can use the diagram below.
-
-[M-CORD VMs wiring diagram](static/images/vms_diagram.png)
-
 ## See the status and the IP addresses of your VNFs
 
 You may often need to check the status of your M-CORD VNFs, or access them to
@@ -42,34 +37,6 @@
 nova interface-list ID_YOU_FOUND_ABOVE
 ```
 
-## How to log into a VNF VM
-
-Sometimes, you may need to access a VNF (VM) running on one of the compute
-nodes. To access a VNF, do the following.
-
-* SSH into the head node
-* From the head node, SSH into the compute node running the VNF. Use the
-  following commands:
-
-```shell
-ssh-agent bash
-ssh-add
-ssh -A ubuntu@COMPUTE_NODE_NAME
-```
-
-> NOTE: You can get your compute node name typing cord prov list on the head
-> node
-
-* SSH into the VM from compute node
-
-```shell
-ssh ubuntu@IP_OF_YOUR_VNF_VM
-```
-
-> NOTE: To know the IP of your VNF, refer to [this
-> paragraph](troubleshooting.md#see-the-status-and-the-ip-addresses-of-your-vnfs).
-> The IP you need is the one reported under the `management network`.
-
 ## View an interface name, inside a VNF
 
 In the troubleshooting steps below you’ll be often asked to provide a specific
@@ -85,7 +52,7 @@
 
 ## Understand the M-CORD Synchronizers logs
 
-As the word says, synchronizers are XOS components responsible to synchronize
+Synchronizers are XOS components responsible to synchronize
 the VNFs status with the configuration input by the Operator. More informations
 about what synchronizers are and how they work, can be found
 [here](/xos/dev/synchronizers.md).
@@ -135,409 +102,3 @@
 
 * **Any other issue?** Please report it to us at <cord-dev@opencord.org>. We
   will try to fix it as soon as possible.
-
-## Check the SPGW-C and the SPGW-U Status
-
-Sometimes, you may want to double check if your SPGW-C and SPGW-U components
-status. To do that, follow the steps below.
-
-### SPGW-C
-
-* SSH into `SPGW-C` VNF with credentials `ngic/ngic` (to access the VNF follow
-  [this guidelines](troubleshooting.md#how-to-log-into-a-vnf-vm))
-* Become the root user (the system will pause for a few seconds)
-
-  ```shell
-  sudo bash
-  ```
-
-* Go to `/root/ngic/cp`
-
-    * If the file `finish_flag_interface_config` exists, the `SPGW-C` has been
-      successfully configured
-    * It the file `finish_flag_build_and_run` exists, the `SPGW-C` build
-      process has successfully completed
-
-* Open the `results` file. It’s the `SPGW-C` build log file. If the file has
-  similar contents to the one shown below, it means the SPGW-C has been
-  successfully started.
-
-  ```shell
-              rx       tx  rx pkts  tx pkts   create   modify  b resrc   create   delete   delete           rel acc               ddn
-   time     pkts     pkts     /sec     /sec  session   bearer      cmd   bearer   bearer  session     echo   bearer      ddn      ack
-      0        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-      1        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-  ```
-
-### SPGW-U
-
-* SSH into `SPGW-U` VNF with credentials `ngic/ngic` (to access the VNF follow
-  [these guidelines](troubleshooting.md#how-to-log-into-a-vnf-vm))
-* Go to `/root/ngic/dp`
-    * If the file `finish_flag_interface_config` exists, the `SPGW-U` has been
-      successfully configured
-    * It the file `finish_flag_build_and_run` exists, the `SPGW-U` build
-      process completed successfully
-* Open the `results` file. It’s the `SPGW-U` build log file. If the file has
-  similar contents to the one shown below, it means the `SPGW-U` has been
-  successfully started.
-
-  ```shell
-  DP: RTE NOTICE enabled on lcore 1
-  DP: RTE INFO enabled on lcore 1
-  DP: RTE NOTICE enabled on lcore 0
-  DP: RTE INFO enabled on lcore 0
-  DP: RTE NOTICE enabled on lcore 3
-  DP: RTE INFO enabled on lcore 3
-  DP: RTE NOTICE enabled on lcore 5
-  DP: RTE INFO enabled on lcore 5
-  DP: RTE NOTICE enabled on lcore 4
-  DP: RTE INFO enabled on lcore 4
-  API: RTE NOTICE enabled on lcore 4
-  API: RTE INFO enabled on lcore 4
-  DP: RTE NOTICE enabled on lcore 6
-  DP: RTE INFO enabled on lcore 6
-  DP: RTE NOTICE enabled on lcore 2
-  DP: RTE INFO enabled on lcore 2
-  DP: MTR_PROFILE ADD: index 1 cir:64000, cbd:3072, ebs:3072
-  Logging CDR Records to ./cdr/20171122165107.cur
-  DP: ACL DEL:SDF rule_id:99999
-  DP: MTR_PROFILE ADD: index 2 cir:125000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 3 cir:250000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 4 cir:500000, cbd:3072, ebs:3072
-  ```
-
-> NOTE: if the last three lines don’t show up, you should re-build the `SPGW-C`
-> and the `SPGW-U`. See
-> [this](troubleshooting.md#configure-build-and-run-the-spgw-c-and-the-spgw-u)
-> for more specific instructions.
-
-## Configure, build and run the SPGW-C and the SPGW-U
-
-In most cases, the `SPGW-C` and the `SPGW-U` are automatically configured,
-built, and started, during the installation process. However, unexpected errors
-may occur, or you may simply want to re-configure these components. To do that,
-follow the steps below.
-
-> WARNING: Make sure you follow the steps in the order described. The SPGW-U
-> should be built and configured before the SPGW-C
-
-### Configuring the SPGW-U
-
-* SSH into `SPGW-U` VNF with credentials `ngic/ngic` (to access the VNF follow
-  [these guidelines](troubleshooting.md#how-to-log-into-a-vnf-vm))
-
-* Become sudo
-
-  ```shell
-  sudo su
-  ```
-
-* Go to the configuration directory
-
-  ```shell
-  /root/ngic/config
-  ```
-
-* Edit the `interface.cfg` file:
-    * **dp_comm_ip**: the IP address of the `SPGW-U` interface, attached to the spgw_network
-    * **cp_comm_ip**: the IP address of the SPGW-C interface, attached to the spgw_network
-* Edit the `dp_config.cfg` file:
-    * **S1U_IFACE**: the name of the SPGW-U interface, attached to the s1u_network
-    * **SGI_IFACE**: the name of the SPGW-U interface, attached to the sgi_network
-    * **S1U_IP**: the IP address of the SPGW-U interface, attached to the s1u_network
-    * **S1U_MAC**: the MAC address of the SPGW-U interface, attached to the s1u_network
-    * **SGI_IP**: the IP address of the SPGW-U interface attached to the sgi_network
-    * **SGI_MAC**: the MAC address of the SPGW-U interface attached to the sgi_network
-* Edit the static_arp.cfg file:
-    * Below the line `[sgi]`, you should find another line with a similar
-      pattern: `IP_addr1 IP_addr2 = MAC_addr`
-        * `IP_addr1` and `IP_addr2` are both the IP address of the vENB
-          interface attached to the sgi_network
-        * `MAC_addr` is the MAC address of the vENB interface, attached to the
-          sgi_network
-    * Below the line `[s1u]`, you should find another line with a similar
-      pattern `IP_addr1 IP_addr2 = MAC_addr`
-        * `IP_addr1` and `IP_addr2` are the IP addresses of the vENB interfaces
-          attached to the s1u_network
-        * `MAC_addr` is the MAC address of the vENB attached to the s1u_network
-
-> Note: To know the IP addresses and MAC addresses mentioned above, follow the
-> instructions
-> [here](troubleshooting.md#view-interface-details-for-a-specific-vnf).
->
-> To know the interface names mentioned above, follow the instructions
-> [here](troubleshooting.md#view-an-interface-name-inside-a-vnf).
-
-### Configuring the SPGW-C
-
-* SSH into `SPGW-C` VNF with credentials `ngic/ngic` (to access the VNF follow
-  [these instructions](troubleshooting.md#how-to-log-into-a-vnf-vm))
-* Become sudo
-
-  ```shell
-  sudo su
-  ```
-
-* Go to the configuration directory
-
-  ```shell
-  cd /root/ngic/config
-  ```
-
-* Edit the `interface.cfg` file
-    * **dp_comm_ip**: the IP address of the `SPGW-U` interface, attached to the spgw_network
-    * **cp_comm_ip**: the IP address of the `SPGW-C` interface, attached to the spgw_network
-* Edit the cp_config.cfg file
-    * **S11_SGW_IP**: the IP address of the SPGW-C interface, attached to the s11_network
-    * **S11_MME_IP**: the IP address of the vENB interface, attached to the s11_network
-    * **S1U_SGW_IP**: the IP addresses of the SPGW-U interface, attached to the s1u_network
-
-> Note: To know the IP addresses and MAC addresses mentioned above, follow the
-> instructions
-> [here](troubleshooting.md#view-interface-details-for-a-specific-vnf).
->
-> To know the interface names mentioned above, follow the instructions
-> [here](troubleshooting.md#view-an-interface-name-inside-a-vnf).
-
-### Building and running the SPGW-U
-
-* SSH into `SPGW-U` VNF with credentials ngic/ngic (to access the VNF follow
-  [these instructions](troubleshooting.md#how-to-log-into-a-vnf-vm))
-
-* Become sudo
-
-  ```shell
-  sudo su
-  ```
-
-* Go to the configuration directory
-
-  ```shell
-  cd /root/ngic/dp
-  ```
-
-* Run the following commands:
-
-  ```shell
-  ../setenv.sh
-  make build
-  make
-  ./udev.sh > results &
-  ```
-
-* Open `results` file. If the process succeeds, you should see an output
-  similar to the one below
-
-  ```shell
-  DP: RTE NOTICE enabled on lcore 1
-  DP: RTE INFO enabled on lcore 1
-  DP: RTE NOTICE enabled on lcore 0
-  DP: RTE INFO enabled on lcore 0
-  DP: RTE NOTICE enabled on lcore 3
-  DP: RTE INFO enabled on lcore 3
-  DP: RTE NOTICE enabled on lcore 5
-  DP: RTE INFO enabled on lcore 5
-  DP: RTE NOTICE enabled on lcore 4
-  DP: RTE INFO enabled on lcore 4
-  API: RTE NOTICE enabled on lcore 4
-  API: RTE INFO enabled on lcore 4
-  DP: RTE NOTICE enabled on lcore 6
-  DP: RTE INFO enabled on lcore 6
-  DP: RTE NOTICE enabled on lcore 2
-  DP: RTE INFO enabled on lcore 2
-  Building and running the SPGW-C
-  SSH into the head node
-  SSH into SPGW-C VNF with credentials ngic/ngic account (to access the VNF follow the guide, here)
-  Become sudo (sudo su)
-  Go to the configuration dir
-  ectory: cd /root/ngic/cp
-  Run the following commands
-  ../setenv.sh
-  make build
-  make
-  ./run.sh > results &
-  Open the “results” file. If the process succeeds, you should see an output similar to the one below
-
-              rx       tx  rx pkts  tx pkts   create   modify  b resrc   create   delete   delete           rel acc               ddn
-   time     pkts     pkts     /sec     /sec  session   bearer      cmd   bearer   bearer  session     echo   bearer      ddn      ack
-      0        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-      1        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-  ```
-
-* Go back to `SPGW-U` VNF and open `results` file in `/root/ngic/dp`. If the
-  process succeeds, you should see a new output similar to one below
-
-  ```shell
-  DP: MTR_PROFILE ADD: index 2 cir:125000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 3 cir:250000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 4 cir:500000, cbd:3072, ebs:3072
-  ```
-
-### Building and running the SPGW-C
-
-* SSH into the head node
-* SSH into `SPGW-C` VNF with credentials `ngic/ngic` (to access the VNF follow
-  [these instructions](troubleshooting.md#how-to-log-into-a-vnf-vm))
-* Become sudo
-
-  ```shell
-  sudo su
-  ```
-
-* Go to the configuration directory:
-
-  ```shell
-  cd /root/ngic/cp
-  ```
-
-* Run the following commands
-
-  ```shell
-  ../setenv.sh
-  make build
-  make
-  ./run.sh > results &
-  ```
-
-* Open the `results` file. If the process succeeds, you should see an output
-  similar to the one below
-
-  ```shell
-              rx       tx  rx pkts  tx pkts   create   modify  b resrc   create   delete   delete           rel acc               ddn
-   time     pkts     pkts     /sec     /sec  session   bearer      cmd   bearer   bearer  session     echo   bearer      ddn      ack
-      0        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-      1        0        0        0        0        0        0        0        0        0        0        0        0        0        0
-  ```
-
-* Go back to `SPGW-U` VNF and open `results` file in `/root/ngic/dp`. If the
-  process succeeds, you should see a new output similar to one below
-
-  ```shell
-  DP: MTR_PROFILE ADD: index 2 cir:125000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 3 cir:250000, cbd:3072, ebs:3072
-  DP: MTR_PROFILE ADD: index 4 cir:500000, cbd:3072, ebs:3072
-  ```
-
-## Troubleshooting with the NG40 vTester
-
-The guide describes how the NG40 results should be interpreted for
-troubleshooting.
-
-### Failure on S11 or SPGW-C not running
-
-```shell
-Signaling Table
-           AttUE     ActCTXT   BrReq     BrAct     RelRq     RelAc     ActS1
-ng40_ran_1 0         0         0         0         0         0         1
-
-User Plane Downlink Table
-           AS_PktTx      AS_EthTx      S1uEthRx      S1uPktRx
-ng40_ran_1 0             0             0             0
-
-User Plane Uplink Table
-           S1uPktTx      S1uEthTx      AS_EthRx      AS_PktRx
-ng40_ran_1 0             0             0             0
-
-Watchtime: 57 Timeout: 1800
-All Tests are finished
-Verdict(tc_attach) = VERDICT_FAIL
-**** Packet Loss ****
-No pkt DL tx
-No pkt UL tx
-Wait for RAN shutdown
-done
-Testlist verdict = VERDICT_FAIL
-```
-
-When you see a `VERDICT_FAIL` and there are 0 values for `BrReq` and `BrAct` in
-the Signaling table, check if the `SPGW-C` is running. If it is, check the
-`S11` connection between the `NG40` VM and the `SPGW-C` VM. The
-`verify_attach.sh` test can help you to verify the status of the control plane
-connectivity on the `S11` network.
-
-If the `ActS1` counter is 0, there’s an internal error on the `S1mme`
-interface, or the NG40 components did not start  correctly.
-
-Run the command `ng40forcecleanup all` to restart all the `NG40` components.
-The `NG40` system components may take some time to start.
-
-Wait 10 seconds before you start a new test.
-
-### Failure on S1u and Sgi or SPGW-U
-
-```shell
-Signaling Table
-           AttUE     ActCTXT   BrReq     BrAct     RelRq     RelAc     ActS1
-ng40_ran_1 0         0         1         1         0         0         1
-
-User Plane Downlink Table
-           AS_PktTx      AS_EthTx      S1uEthRx      S1uPktRx
-ng40_ran_1 185           0             0             0
-
-User Plane Uplink Table
-           S1uPktTx      S1uEthTx      AS_EthRx      AS_PktRx
-ng40_ran_1 64            0             0             0
-
-Watchtime: 18 Timeout: 1800
-All Tests are finished
-Verdict(tc_attach_www) = VERDICT_PASS
-**** Packet Loss ****
-DL Loss= AS_PktTx-S1uPktRx=     185(pkts); 100.00(%)
-UL Loss= S1uPktTx-AS_PktRx=     64(pkts); 100.00(%)
-```
-
-If you running `attach_verify_data.sh` and you see `VERDICT_PASS` but 100% `DL`
-and `UL` Loss values, check if the `SGPW-U` is running. If it is, check the
-`S1u` and the `SGi` connections.
-
-When packets are generated (see values `AS_PktTx` and `S1uPktTx`), but are not
-sent to Ethernet (see values `AS_EthTx` and `S1uEthTx`) it may be that no
-`NG40` ARP requests get answered.
-
-### Routing problem on S1u
-
-```shell
-Signaling Table
-           AttUE     ActCTXT   BrReq     BrAct     RelRq     RelAc     ActS1
-ng40_ran_1 0         0         1         1         0         0         1
-
-User Plane Downlink Table
-           AS_PktTx      AS_EthTx      S1uEthRx      S1uPktRx
-ng40_ran_1 185           185           185           185
-
-User Plane Uplink Table
-           S1uPktTx      S1uEthTx      AS_EthRx      AS_PktRx
-ng40_ran_1 64            66            0             0
-
-Watchtime: 18 Timeout: 1800
-All Tests are finished
-Verdict(tc_attach_www) = VERDICT_PASS
-**** Packet Loss ****
-DL Loss= AS_PktTx-S1uPktRx=     185(pkts); 0.00(%)
-UL Loss= S1uPktTx-AS_PktRx=     64(pkts); 100.00(%)
-```
-
-When you run `attach_verify_data.sh` and you see `Data sent` on `S1u` and `SGi`
-(see values `AS_EthTx` and `S1uEthTx`), but no data received at the Application
-Server (see values `AS_EthRx` and `AS_PktRx`), check the `SPGW-U CDRs`. If the
-packets going `uplink` are processed in the `CDRs`, either your routing or the
-allowed IP settings on the `SGi` interface are not correct.
-
-If packets are processed, but 0 bytes are sent through the `uplink`, there’s a
-mismatch in the `GTPU header size` configuration. For example the `SPGW-U` is
-compiled together with a `SessionID`,  but the `NG40` VM is configured without
-`SessionID`.
-
-### Other problems
-
-If you see timeouts, exceptions, strange behaviors or the `ActS1` counter is 0,
-try one of the solutions below:
-
-* Cleanup and restart the NG40 process, running `ng40forcecleanup all`. Wait
-  about 10 seconds to allow the system to restart. Then, run a new test.
-* Check the NG40 license is still active, and in case install a new one, as
-  described
-  [here](installation_guide.md#request--update-the-ng40-vtester-software-license).
-
-Re-initialize the NG40 processes, running `~/install/ng40init`.