diff --git a/docs/sections/services/ves-hv/configuration.rst b/docs/sections/services/ves-hv/configuration.rst
new file mode 100644
index 0000000..f2b726f
--- /dev/null
+++ b/docs/sections/services/ves-hv/configuration.rst
@@ -0,0 +1,31 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Configuration
+=============
+
+HV-VES expects to be able to fetch configuration directly from consul service in following JSON format:
+
+.. code-block:: json
+
+    {
+        "dmaap.kafkaBootstrapServers": "kafka-host:9093",
+        "collector.routing": [
+                {
+                    "fromDomain": "PERF3GPP",
+                    "toTopic": "topic-1"
+                },
+                {
+                    "fromDomain": "HEARTBEAT",
+                    "toTopic": "topic-2"
+                },
+                ...
+        ]
+    }
+
+
+During ONAP OOM/Kubernetes deployment this configuration is created from HV-VES cloudify blueprint.
+
+Endpoint on which HV-VES seeks configuration can be configured during deployment as described in installation_.
+
+.. _installation: ./installation.html
\ No newline at end of file
diff --git a/docs/sections/services/ves-hv/delivery.rst b/docs/sections/services/ves-hv/delivery.rst
new file mode 100644
index 0000000..74db3c0
--- /dev/null
+++ b/docs/sections/services/ves-hv/delivery.rst
@@ -0,0 +1,9 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Delivery
+========
+
+**HV-VES** is delivered as a docker container and published in ONAP Nexus repository following image naming convention.
+
+Full image name is `onap/org.onap.dcaegen2.collectors.hv-ves.hv-collector-main`.
\ No newline at end of file
diff --git a/docs/sections/services/ves-hv/design.rst b/docs/sections/services/ves-hv/design.rst
new file mode 100644
index 0000000..8e7ce7a
--- /dev/null
+++ b/docs/sections/services/ves-hv/design.rst
@@ -0,0 +1,51 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Design
+======
+
+
+Compatibility aspects (VES-JSON)
+--------------------------------
+
+HV-VES Collector has been designed as a high-volume variant of the existing VES(JSON) collector, and not a completely new collector.
+HV-VES follows the VES-JSON schema - as much as possible
+
+- It uses a Google Protocol Buffers ( GPB/PROTO ) representation of the VES Common Header
+- The PROTO files tend to use most encoding effective types defined by GPB to cover Common Header fields.
+- It makes routing decisions based mostly on the content of the "Domain" parameter
+- It allows to embed Payload of different types (by default PERF3GPP domain is included)
+
+Analytics applications impacts
+
+- An analytics application operating on high-volume data needs to be prepared to read directly from Kafka
+- An analytics application need to operate on GPB encoded data in order to benefit from GPB encoding efficiencies
+- It is assumed, that due to the nature of high volume data, there would have to be dedicated applications provided,
+able to operate on such volumes of data.
+
+Extendability
+-------------
+
+HV-VES was designed to allow for extendability - by adding new domain-specific PROTO files.
+
+The PROTO file, which contains the VES CommonHeader, comes with a binary-type Payload parameter, where domain-specific data shall be placed.
+Domain-specific data are encoded as well with GPB, and they do require a domain-specific PROTO file to decode the data.
+This domain-specific PROTO needs to be shared with analytics applications - HV-VES is not analyzing domain-specific data.
+
+In order to support the RT-PM use-case, HV-VES includes a "PERF3GPP" domain PROTO file, as within this domain,
+the high volume data is expected to be reported to HV-VES collector.
+Still, there are no limitations to define additional domains, based on existing VES domains (like Fault, Heartbeat)
+or completely new domains. New domains can be added "when needed".
+
+GPB PROTO files are backwards compatible, and such a new domain could be added without affecting existing systems.
+
+Analytics applications will have to be as well equipped with this new domain-specific PROTO file.
+Currently, these additional, domain specific proto files could be simply added to respective repos of HV-VES collector.
+
+Implementation details
+----------------------
+
+- Project Reactor is used as a backbone of the internal architecture.
+- Netty is used by means of reactor-netty library.
+- We are using Kotlin so we can write very concise code with great interoperability with existing Java libraries.
+- Types defined in Λrrow library are also used when it improves readability or general cleanness of the code.
\ No newline at end of file
diff --git a/docs/sections/services/ves-hv/index.rst b/docs/sections/services/ves-hv/index.rst
index 0662660..483ddbd 100644
--- a/docs/sections/services/ves-hv/index.rst
+++ b/docs/sections/services/ves-hv/index.rst
@@ -7,5 +7,29 @@
 
 .. Add or remove sections below as appropriate for the platform component.
 
-High Volume VES Collector overview and functions
 
+**HV-VES collector** has been proposed, based on a need to process high-volumes of data generated frequently by a large
+number of NFs. The driving use-case is described and published within presentation during Casablanca Release Developer Forum:
+`Google Protocol Buffers versus JSON - 5G RAN use-case - comparison`_.
+
+.. _`Google Protocol Buffers versus JSON - 5G RAN use-case - comparison`: https://wiki.onap.org/download/attachments/25434845/Casablanca_Dev_Forum_GPB_comparison_20180621.pptx?version=1&modificationDate=1530275050000&api=v2
+
+The goal of the collector is to support high volume data. It uses plain TCP connections.
+Connections are stream-based (as opposed to request-based) and long running.
+Payload is binary-encoded (currently using Google Protocol Buffers).
+HV-VES uses direct connection to DMaaP's Kafka.
+All these decisions were made in order to support high-volume data with minimal latency.
+
+
+High Volume VES Collector overview and functions
+------------------------------------------------
+
+.. toctree::
+    :maxdepth: 1
+   ./design.rst
+   ./configuration.rst
+   ./delivery.rst
+   ./installation.rst
+   `Offered APIs`_
+
+.. _`Offered APIs`: ../../apis/ves-hv.rst
\ No newline at end of file
diff --git a/docs/sections/services/ves-hv/installation.rst b/docs/sections/services/ves-hv/installation.rst
new file mode 100644
index 0000000..7dafeae
--- /dev/null
+++ b/docs/sections/services/ves-hv/installation.rst
@@ -0,0 +1,27 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Installation
+============
+
+To run HV-VES Collector container you need to specify required parameters:
+
+- listen-port - the port on which HV-VES will listen internally
+- config-url - URL of HV-VES configuration on consul
+
+There are also optional configuration parameters:
+
+- health-check-api-port - Health check rest api listen port
+- first-request-delay - Delay of first request to consul in seconds
+- request-interval - Interval of consul configuration requests in seconds
+- ssl-disable - Disable SSL encryption
+- key-store - Key store in PKCS12 format path
+- key-store-password - Key store password
+- trust-store - File with trusted certificate bundle in PKCS12 format path
+- trust-store-password - Trust store password
+- idle-timeout-sec - Idle timeout for remote hosts. After given time without any data exchange the connection might be closed
+
+
+These parameters can be configured either by passing command line option during `docker run` call or
+by specifying environment variables named after command line option name
+rewritten using `UPPER_SNAKE_CASE` and prepended with `VESHV_` prefix e.g. `VESHV_LISTEN_PORT`.
\ No newline at end of file