diff --git a/docs/README.md b/docs/README.md
index fc32baf..fcff27c 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,20 +1,25 @@
 # M-CORD Profile
 
-The M-CORD (Mobile CORD) profile is `Official` as of 4.1.
+M-CORD 5.0 documentation is not ready yet, we are working on it now !
+
+The M-CORD (Mobile CORD) profile is `Official` as of 4.1. This document
+describes 5.0.
 
 ## Service Manifest
 
-M-CORD includes service manifests:
-
-### [mcord-ng40](https://github.com/opencord/platform-install/blob/cord-4.1/profile_manifests/mcord-ng40.yml)
+M-CORD includes service manifests: mcord-cavium
 
 | Service      | Source Code         |
 |--------------|---------------|
 | epc-service  | https://github.com/opencord/epc-service |
 | Fabric       | https://github.com/opencord/fabric |
+| HSS_DB       | based on Cassandra, will be provided in hss_db image |
+| InternetEmulator | based on VLC, will be provided in internetEmulator image |
 | ONOS         | https://github.com/opencord/onos-service |
 | OpenStack    | https://github.com/opencord/openstack |
 | vENB         | https://github.com/opencord/venb |
+| vHSS         | https://github.com/opencord/vHSS |
+| vMME         | https://github.com/opencord/vMME |
 | vSPGWC       | https://github.com/opencord/vspgwc |
 | vSPGWU       | https://github.com/opencord/vspgwu |
 | VTN          | https://github.com/opencord/vtn |
@@ -22,17 +27,19 @@
 ## Model Extensions
 
 M-CORD extends CORD's core models with the following model specification
-[mcord.xproto](https://github.com/opencord/mcord/blob/master/xos/models/mcord.xproto),
+[mcord.xproto](https://github.com/opencord/mcord/blob/cord-5.0/xos/models/mcord.xproto),
 which represents the subscriber that anchors a chain of ServiceInstances:
 
 ```proto
 message MCordSubscriberInstance (ServiceInstance) {
     option verbose_name = "MCORD Subscriber";
-    option description = "This model holds the informations of a Mobile Subscriber in CORD";
+    option description = "This model holds the informations of a Mobile
+    Subscriber in CORD";
 
     required string imsi_number = 1 [max_length = 30, content_type = "stripped", blank = False, null = False, db_index = False];
     optional string apn_number = 2 [max_length = 30, content_type = "stripped", blank = True, null = True, db_index = False];
-    optional int32 ue_status = 3 [max_length = 30, choices = "(('0', 'Detached'), ('1', 'Attached'))", blank = True, null = True, db_index = False];
+    optional int32 ue_status = 3 [default = "0", choices = "(('0', 'Detached'), ('1', 'Attached'))", blank = True, null = True, db_index = False];
+    optional string created_by = 4 [null = True, blank = True, gui_hidden = True];
 }
 ```
 
diff --git a/docs/overview.md b/docs/overview.md
index 134dbd2..440e8c4 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
@@ -18,17 +18,16 @@
 programmable network slicing (ProgRAN), and MME-disaggregation. These features
 have already been demonstrated.
 
-The first release (4.1) of M-CORD ships with the basic CORD building blocks
-(ONOS, XOS, Docker, and Open Stack), as well as with a number of VNFs to
-support 3GPP LTE connectivity. These VNFs include a CUPS compliant open source
-SPGW (in the form of two VNFs: SPGW-u and SPGW-c), as well as a VNF emulating
-an MME with an integrated HSS, eNBs and UEs. The emulator is not open source.
-It comes as a binary, courtesy of ng4T (<http://www.ng4t.com>), who provides
-free trial licenses for limited use.
+The M-CORD 5.0 ships with the basic CORD building blocks (ONOS, XOS, Docker,
+and Open Stack), as well as with a number of VNFs to support 3GPP LTE
+connectivity. These VNFs include a CUPS compliant open source SPGW (in the
+form of two VNFs: SPGW-u and SPGW-c), as well as an MME, a HSS, a HSS_DB and
+an Internet emulator. This EPC network should use standalone eNodeB hardware
+and real UE (User Equipment).
 
 Following releases of M-CORD will complete the open source EPC suite, by
-offering an MME, an HSS, as well as a PCRF VNF. The inclusion of these
-additional VNFs is targeted for the 6.0 release.
+offering a PCRF VNF. The inclusion of this additional VNF is targeted for
+the 6.0 release.
 
 The picture below shows a diagram representing a generic M-CORD POD.
 
@@ -103,57 +102,32 @@
 
 The current release of M-CORD includes:
 
-* An open source EPC, providing an SPGW control plane and an SPGW user plane
-  (respectively represented in the system by two VMs deployed on the compute
-  nodes). The current release of the EPC doesn’t yet provide MME, HSS and PCRF
-  services.
-* A closed source test suite, emulating UEs, eNodeBs, a minimal version of an
-  MME with an integrated HSS, and an application server (used to emulate the
-  upstream connectivity).
+* An open source EPC, providing an SPGW control plane, an SPGW user plane, an
+  MME, an HSS, an HSS_DB and an Internet emulator (respectively represented in
+  the system by VMs deployed on the compute nodes). The current release 5.0 of
+  the EPC does not yet provide PCRF service.
 
-With customizations the system is able to use real hardware base stations, but
-the released version supports just simple tests with emulated traffic.
+* Real hardware base station or Standalone eNodeB, UEs (connected to eNodeB
+  through radio channel). The eNodeB is physically connected to CORD POD.
 
-At high level, a UE emulator generates some traffic, that passes through the
-EPC, goes to an emulated application server, and then goes back to the traffic
-generator again.
+Looking at the system from another perspective, six VMs are provided:
 
-Looking at the system from another perspective, three VMs are provided (some of
-which implement multiple services:
-
-* **mysite_venb-X**: a test suite that emulates the RAN components (UEs,
-  eNodeBs), an application server, and some of the EPC components (MME and HSS)
+* **mysite_vmme-X**: a component of the EPC implementing the MME functionalities
+* **mysite_vhss-X**: a component of the EPC implementing the HSS functionalities
+  except database
+* **mysite_hss_db-X**: a component of the HSS implementing database which
+  contains all information of subscribers (i.e., UEs)
 * **mysite_vspgwc-X**: a component of the EPC implementing the S-GW and the
   P-GW control plane functionalities
 * **mysite_vspgwu-X**: a component of the EPC implementing the S-GW and the
   P-GW user plane functionalities
+* **mysite_internetemulator-X**: Internet emulator, works as a video streaming
+  server
 
 > NOTE: in the list above, X is a number that varies, and that is automatically
 > generated by the system. More information on how to get the list of VMs can
 > be found in the installation and troubleshooting guides, below.
 
-The picture below describes how the VMs are connected.
-
-![M-CORD VMs Wiring Diagram](static/images/vms_diagram.png)
-
-Following, is a list of the networks between the VMs:
-
-* **S11_net**: used to exchange control plane traffic between MME and SPGW
-  (i.e. tunnel and IP address allocation)
-* **S1U_net**: used to exchange user traffic. This specific network is used to
-  exchange data between the RAN components (UEs, eNodeBs) and the EPC
-* **SGI_net**: used to exchange user traffic. This specific network is used to
-  exchange data between the EPC and the Application Server, running on the
-  mysite_venb-X VM
-* **spgw_net**: network dedicated to the communication of the vSPGW components
-  (control plane and user plane)
-
-User traffic is generated on the mysite_venb-X VM. It goes uplink via S1U_net,
-reaches the EPC, flows through the SGI_net to the application server, emulating
-Internet. The application server replies, and the answer flows back in
-downlink, via SGI_net, through the EPC, via S1U_net, back to the emulated RAN
-(eNB and UEs).
-
 ## Evolved Packet Core (EPC)
 
 The EPC shipped with M-CORD is called “Next Generation Infrastructure Core”
@@ -168,32 +142,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 +160,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 +191,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 +217,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