CI: Update RTD configuration file

[sim/o1-interface.git] / docs / overview.rst

diff --git a/docs/overview.rst b/docs/overview.rst
index 1db9f92..1914d00 100644 (file)
--- a/docs/overview.rst
+++ b/docs/overview.rst
@@ -19,7 +19,7 @@ The NETCONF/YANG management interface is simulated, and any YANG models can be l
 The NTS framework is based on several open-source projects
 
 - `cJSON <https://github.com/DaveGamble/cJSON>`_
-- `libcurl <https://curl.haxx.se>`_
+- `libcurl <https://curl.se>`_
 - `libyang <https://github.com/CESNET/libyang>`_
 - `sysrepo <https://github.com/sysrepo/sysrepo>`_
 - `libnetconf2 <https://github.com/CESNET/libnetconf2>`_
@@ -635,3 +635,19 @@ Starting standalone NFs
 -----------------------
 
 One could start 1 instance of a simulated O-RU-FH and 1 instance of a simulated O-DU by running the `nts-start.sh` script. Pre-configured values can be set in the `.env` file.
+
+Building O-DU O1 Simulator image with 3GPP YANG models
+------------------------------------------------------
+
+Because of the license of the 3GPP YANG models, we cannot use the same approach as for the other simulated NFs (hosting docker images in LF Nexus repositories) for the simulated O-DU containing 3GPP YANG models. In order to provide such a simulator nevertheless, we provide here the recipe to build such an image locally, thus not breaking any license.
+
+Building such an image is pretty straightforward:
+
+1. run the `nts_build_o_du_rel_18.sh` bash script from `ntsimulator` folder. It will download the necessary 3GPP YANG models and then produce a docker image with the name `nts-ng-o-ran-du-rel-18` and the version tag defined in the `.env` file, under the `NTS_BUILD_VERSION` environment variable.
+
+O-RU feature: monitoring NETCONF connectivity
+---------------------------------------------
+
+O-RAN.WG4.MP.0-R003-v11.00 defines, in chapter 6.7, a mechanism for monitoring the NETCONF connectivity to the O-RU.
+
+The simulated O-RU implements such a functionality: it listens for supervision-watchdog-reset RPC defined in the o-ran-supervision YANG model and reacts to it, replying with the time when the next supervision-notification will be sent. After the supervision-notification-interval has passed (default 60 seconds), the supervision-notification defined in the o-ran-supervision YANG model will be sent. The O-RU simulator waits then for another guard-time-overhead seconds (default 10 seconds) for receiving a new supervision-watchdog-reset RPC. If it is received, the mechanism starts again (either with the default values, or with the values that come inside the RPC). If not, a message is logged (`Failed to receive watchdog reset, terminating supervision timer for o-ran-supervision..`) and the mechanism stops sending any notifications.