doc: openthread: Describe nRF radio implementation

Updated the architectures and configuration pages in nrf
documentation to describe the new OpenThread radio platform
implementation which does not use Zephyr L2 networking layer.

Updated OpenThread samples README files to mention both
configuration and new snippets.

Signed-off-by: Arkadiusz Balys <[email protected]>

Author: ArekBalysNordic

doc/nrf/protocols/thread/configuring.rst

@@ -36,10 +36,21 @@ Thread requires the following Zephyr modules to properly operate in the |NCS|:
 Enable OpenThread in the |NCS|
 ==============================
 
-To use the Thread protocol in the |NCS|, set the following Kconfig options:
+You can use the Thread protocol in the |NCS| in two ways: by utilizing the Zephyr networking layer, or by passing Thread frames directly to the nRF 802.15.4 radio driver.
+
+* To use the Thread protocol with Zephyr networking layer, enable the following Kconfig options:
+
+  * :kconfig:option:`CONFIG_NETWORKING` - This option enables a generic link layer and the IP networking support.
+  * :kconfig:option:`CONFIG_NET_L2_OPENTHREAD` - This option enables the OpenThread stack required for operating the Thread protocol effectively.
+
+* To use the Thread protocol and nRF 802.15.4 radio directly, disable the previous Kconfig options, and enable the following:
+
+  * :kconfig:option:`CONFIG_OPENTHREAD` - This option enables the OpenThread stack, allowing the direct use of the nRF 802.15.4 radio.
+
+To learn more about available architectures, see the :ref:`openthread_stack_architecture` user guide.
+
+Additionally, you can set the following Kconfig options:
 
-* :kconfig:option:`CONFIG_NETWORKING` - This option enables the generic link layer and the IP networking support.
-* :kconfig:option:`CONFIG_NET_L2_OPENTHREAD` - This option enables the OpenThread stack required for the correct operation of the Thread protocol and allows you to use it.
 * :kconfig:option:`CONFIG_MPSL` - This option enables the :ref:`nrfxlib:mpsl` (MPSL) implementation, which provides services for both :ref:`single-protocol and multi-protocol implementations <ug_thread_architectures>`.
   This is automatically set for all samples in the |NCS| that use the :ref:`zephyr:ieee802154_interface` radio driver.
 
@@ -81,6 +92,7 @@ Depending on your configuration needs, you can also set the following options:
 
 * :kconfig:option:`CONFIG_NET_SOCKETS` - This option enables API similar to BSD Sockets on top of the native Zephyr networking API.
   This configuration is needed for managing networking protocols.
+  This configuration is available only if Zephyr networking layer is enabled.
 * :kconfig:option:`CONFIG_OPENTHREAD_SHELL` - This option enables OpenThread CLI (see `OpenThread CLI Reference`_).
 * :kconfig:option:`CONFIG_COAP` - This option enables Zephyr's :ref:`zephyr:coap_sock_interface` support.
 * :kconfig:option:`CONFIG_COAP_UTILS` - This option enables the :ref:`CoAP utils library <coap_utils_readme>`.
@@ -94,6 +106,7 @@ See the following files for more options that you might want to change:
 
 * :file:`zephyr/subsys/net/l2/openthread/Kconfig.features` - OpenThread stack features.
 * :file:`zephyr/subsys/net/l2/openthread/Kconfig.thread` - Thread network configuration options.
+* :file:`nrf/modules/openthread/Kconfig.features.nrf` - Thread network configuration dedicated to nRF Connect purposes.
 
 .. note::
    You can find the default configuration for all :ref:`openthread_samples` in the :file:`nrf/subsys/net/openthread/Kconfig.defconfig` file.
@@ -158,56 +171,116 @@ An IEEE EUI-64 address consists of two parts:
 * Company ID - a 24-bit MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
 * Extension identifier - a 40-bit device unique identifier
 
-You can configure the EUI-64 for a device in the following ways:
+You can configure the EUI-64 for a device in the following ways depending on chosen architecture:
+
+  .. tabs::
+
+     .. tab:: Zephyr networking layer enabled
+
+        Use the default
+          By default, the company ID is set to Nordic Semiconductor's MA-L (``f4-ce-36``).
+          The extension identifier is set to the DEVICEID from the factory information configuration registers (FICR).
+
+        Replace the company ID
+          You can enable the :kconfig:option:`CONFIG_IEEE802154_VENDOR_OUI_ENABLE` Kconfig option to replace Nordic Semiconductor's company ID with your own company ID.
+          Specify your company ID in :kconfig:option:`CONFIG_IEEE802154_VENDOR_OUI`.
+
+          The extension identifier is set to the default, namely the DEVICEID from FICR.
+
+        Replace the full EUI-64
+          You can provide the full EUI-64 value by programming certain user information configuration registers (UICR).
+          nRF52 Series devices use the CUSTOMER registers block, while nRF53 Series devices use the OTP registers block
+
+          To use the EUI-64 value from the UICR, enable the :kconfig:option:`CONFIG_NRF5_UICR_EUI64_ENABLE` Kconfig option and set :kconfig:option:`CONFIG_NRF5_UICR_EUI64_REG` to the base of the two consecutive registers that contain your EUI-64 value.
+
+          The following example shows how to replace the full EUI-64 on the nRF52840 device:
+
+          1. Enable the :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE` Kconfig option.
+
+          #. Specify the offset for the UICR registers in :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_REG`.
+             This example uses UICR->CUSTOMER[0] and UICR->CUSTOMER[1], which means that you can keep the default value ``0``.
+
+          #. Build and program your application erasing the whole memory.
+             Make sure to replace *serial_number* with the serial number of your debugger:
+
+              .. parsed-literal::
+               :class: highlight
+
+                west build -b nrf52840dk/nrf52840 -p always
+                west flash --snr *serial_number* --erase
+
+          #. Program the registers UICR->CUSTOMER[0] and UICR->CUSTOMER[1] with your EUI-64 value (replace *serial_number* with the serial number of your debugger):
+
+              .. parsed-literal::
+               :class: highlight
+
+                nrfutil device x-write --serial-number *serial_number* --address 0x10001080 --value 0x11223344
+                nrfutil device x-write --serial-number *serial_number* --address 0x10001084 --value 0x55667788
+                nrfutil device reset --reset-kind=RESET_PIN
+
+             If you used a different value for :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_REG`, you must use different register addresses.
+
+             At the end of the configuration process, you can check the EUI-64 value using OpenThread CLI:
+
+              .. code-block:: console
+
+               uart:~$ ot eui64
+               8877665544332211
+               Done
+
+     .. tab:: Zephyr networking layer disabled
+
+        Use the default
+          By default, the company ID is set to Nordic Semiconductor's MA-L (``f4-ce-36``).
+          The extension identifier is set to the DEVICEID from the factory information configuration registers (FICR).
+
+        Replace the company ID
+          You can enable the :kconfig:option:`CONFIG_IEEE802154_VENDOR_OUI_ENABLE` Kconfig option to replace Nordic Semiconductor's company ID with your own company ID.
+          Specify your company ID in :kconfig:option:`CONFIG_NRF5_VENDOR_OUI`.
+
+          The extension identifier is set to the default, namely the DEVICEID from FICR.
 
-Use the default
-  By default, the company ID is set to Nordic Semiconductor's MA-L (``f4-ce-36``).
-  The extension identifier is set to the DEVICEID from the factory information configuration registers (FICR).
+        Replace the full EUI-64
+          You can provide the full EUI-64 value by programming certain user information configuration registers (UICR).
+          nRF52 Series devices use the CUSTOMER registers block, while nRF53 Series devices use the OTP registers block.
 
-Replace the company ID
-  You can enable :kconfig:option:`CONFIG_IEEE802154_VENDOR_OUI_ENABLE` to replace Nordic Semiconductor's company ID with your own company ID.
-  Specify your company ID in :kconfig:option:`CONFIG_IEEE802154_VENDOR_OUI`.
+          To use the EUI-64 value from the UICR, enable the :kconfig:option:`CONFIG_NRF5_UICR_EUI64_ENABLE` Kconfig option and set :kconfig:option:`CONFIG_NRF5_UICR_EUI64_REG` to the base of the two consecutive registers that contain your EUI-64 value.
 
-  The extension identifier is set to the default, namely the DEVICEID from FICR.
+          The following example shows how to replace the full EUI-64 on the nRF52840 device:
 
-Replace the full EUI-64
-  You can provide the full EUI-64 value by programming certain user information configuration registers (UICR).
-  For nRF52 Series devices, the CUSTOMER registers block is used.
-  For nRF53 Series devices, the OTP registers block is used.
+          1. Enable the :kconfig:option:`CONFIG_NRF5_UICR_EUI64_ENABLE` Kconfig option.
 
-  To use the EUI-64 value from the UICR, enable :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE` and set :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_REG` to the base of the two consecutive registers that contain your EUI-64 value.
+          #. Specify the offset for the UICR registers in :kconfig:option:`CONFIG_NRF5_UICR_EUI64_REG`.
+             This example uses UICR->CUSTOMER[0] and UICR->CUSTOMER[1], which means that you can keep the default value ``0``.
 
-  The following example shows how to replace the full EUI-64 on an nRF52840 device:
+          #. Build and program your application erasing the whole memory.
+             Make sure to replace *serial_number* with the serial number of your debugger:
 
-  1. Enable :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE`.
-  #. Specify the offset for the UICR registers in :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_REG`.
-     This example uses UICR->CUSTOMER[0] and UICR->CUSTOMER[1], which means that you can keep the default value ``0``.
-  #. Build and program your application erasing the whole memory (replace *serial_number* with the serial number of your debugger):
+              .. parsed-literal::
+               :class: highlight
 
-     .. parsed-literal::
-      :class: highlight
+               west build -b nrf52840dk/nrf52840 -p always
+               west flash --snr *serial_number* --erase
 
-       west build -b nrf52840dk/nrf52840 -p always
-       west flash --snr *serial_number* --erase
+          #. Program the registers UICR->CUSTOMER[0] and UICR->CUSTOMER[1] with your EUI-64 value (replace *serial_number* with the serial number of your debugger):
 
-  #. Program the registers UICR->CUSTOMER[0] and UICR->CUSTOMER[1] with your EUI-64 value (replace *serial_number* with the serial number of your debugger):
+              .. parsed-literal::
+                :class: highlight
 
-     .. parsed-literal::
-      :class: highlight
+                nrfutil device x-write --serial-number *serial_number* --address 0x10001080 --value 0x11223344
+                nrfutil device x-write --serial-number *serial_number* --address 0x10001084 --value 0x55667788
+                nrfutil device reset --reset-kind=RESET_PIN
 
-       nrfutil device x-write --serial-number *serial_number* --address 0x10001080 --value 0x11223344
-       nrfutil device x-write --serial-number *serial_number* --address 0x10001084 --value 0x55667788
-       nrfutil device reset --reset-kind=RESET_PIN
+             If you used a different value for :kconfig:option:`CONFIG_NRF5_UICR_EUI64_REG`, you must use different register addresses.
 
-     If you used a different value for :kconfig:option:`CONFIG_IEEE802154_NRF5_UICR_EUI64_REG`, you must use different register addresses.
+             At the end of the configuration process, you can check the EUI-64 value using OpenThread CLI:
 
-At the end of the configuration process, you can check the EUI-64 value using OpenThread CLI:
+              .. code-block:: console
 
-.. code-block:: console
+                uart:~$ ot eui64
+                8877665544332211
+                Done
 
-   uart:~$ ot eui64
-   8877665544332211
-   Done
 
 .. _ug_thread_configuring_crypto:
 
@@ -232,6 +305,7 @@ The `Mbed TLS`_ protocol features can be handled using the :kconfig:option:`OPEN
    The :kconfig:option:`OPENTHREAD_MBEDTLS_CHOICE` Kconfig option has not been tested and is not recommended for use with the |NCS|.
 
 For more information about the open source Mbed TLS implementation in the |NCS|, see the `sdk-mbedtls`_ repository.
+For more information about the OpenThread security in |NCS|, see the :ref:`ug_ot_thread_security` page.
 
 .. _ug_thread_configure_commission:
 

doc/nrf/protocols/thread/overview/architectures.rst

@@ -28,6 +28,35 @@ This can be done per platform, while retaining the ability to default to a stand
 
    OpenThread architecture adapted from `openthread.io <OpenThread system architecture_>`_
 
+|NCS| provides two different architecture options for OpenThread.
+The first one uses Zephyr networking layer to communicate OpenThread stack with the IEEE 802.15.4 radio driver.
+The second one uses the OpenThread stack directly to communicate with the IEEE 802.15.4 radio driver.
+
+To learn more about the differences between the two architectures, see the following table:
+
+.. list-table:: Thread architecture options
+   :widths: auto
+   :header-rows: 1
+
+   * - Integration with Zephyr networking layer
+     - Direct IEEE 802.15.4 radio integration with OpenThread stack
+   * - Uses Zephyr networking layer to communicate OpenThread stack with the IEEE 802.15.4 radio driver.
+     - Uses the OpenThread stack directly to communicate with the IEEE 802.15.4 radio driver.
+   * - Integrates Zephyr networking features, such as Sockets, IPv6, DNS, DHCPv6, zperf, and more.
+     - Uses the Openthread networking features.
+   * - Implements the Zephyr IEEE 802.15.4 radio driver and PHY layer in Zephyr.
+     - Uses the nRF5 radio driver directly.
+   * - Uses the Zephyr BSD Socket API to communicate with the application layer.
+     - Uses the OpenThread BSD API to communicate with the application layer.
+   * - CoAP and MQTT application layer Zephyr implementations available.
+     - CoAP application layer OpenThread implementation available.
+   * - More complex to implement and debug.
+     - More lightweight and easier to implement and debug.
+   * - More memory and flash usage.
+     - Less memory and flash usage.
+
+To learn how to choose the architecture option that best fits your needs, see the :ref:`ug_thread_configuring_basic` user guide.
+
 .. _ug_thread_architectures_designs_soc_designs:
 
 System-on-Chip designs
@@ -60,15 +89,33 @@ It has the following disadvantages:
 * The application and the network share flash and RAM space, which can limit the application functionality.
 * Might require external flash for DFU if the secondary application slot does not fit in the primary memory because of increased application size.
 
-.. figure:: images/thread_platform_design_soc.svg
-   :alt: Thread-only architecture (nRF52, nRF54L)
+Depending on integration with the Zephyr networking layer, there are two different designs:
+
+.. tabs::
+
+   .. group-tab:: Integration with Zephyr networking layer
+
+      .. figure:: images/thread_platform_design_soc.svg
+         :alt: Thread-only architecture (nRF52, nRF54L)
+
+         Thread-only architecture on nRF52 Series and nRF54L Series devices
+
+      .. figure:: images/thread_platform_design_nRF53.svg
+         :alt: Thread-only architecture (nRF53)
+
+         Thread-only architecture on nRF53 Series devices
+
+   .. group-tab:: Direct IEEE 802.15.4 radio integration with OpenThread stack
 
-   Thread-only architecture on nRF52 Series and nRF54L Series devices
+      .. figure:: images/thread_platform_design_soc_direct.svg
+         :alt: Thread-only architecture (nRF52, nRF54L)
 
-.. figure:: images/thread_platform_design_nRF53.svg
-   :alt: Thread-only architecture (nRF53)
+         Thread-only architecture on nRF52 Series and nRF54L Series devices
 
-   Thread-only architecture on nRF53 Series devices
+      .. figure:: images/thread_platform_design_nRF53_direct.svg
+         :alt: Thread-only architecture (nRF53)
+
+         Thread-only architecture on nRF53 Series devices
 
 This platform design is suitable for the following development kits:
 
@@ -94,15 +141,34 @@ It has the following disadvantages:
 
 * Bluetooth LE activity can degrade the connectivity on Thread if not implemented with efficiency in mind.
 
-.. figure:: images/thread_platform_design_multi.svg
-   :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF52, nRF54L)
+Depending on integration with the Zephyr networking layer, there are two different designs:
+
+.. tabs::
+
+   .. group-tab:: Integration with Zephyr networking layer
+
+      .. figure:: images/thread_platform_design_multi.svg
+         :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF52, nRF54L)
+
+         Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series and nRF54L Series devices
+
+      .. figure:: images/thread_platform_design_nRF53_multi.svg
+         :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF53)
+
+         Multiprotocol Thread and Bluetooth LE architecture on nRF53 Series devices
 
-   Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series and nRF54L Series devices
+   .. group-tab:: Direct IEEE 802.15.4 radio integration with OpenThread stack
 
-.. figure:: images/thread_platform_design_nRF53_multi.svg
-   :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF53)
+      .. figure:: images/thread_platform_design_multi_direct.svg
+         :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF52, nRF54L)
+
+         Multiprotocol Thread and Bluetooth LE architecture on nRF52 Series and nRF54L Series devices
+
+      .. figure:: images/thread_platform_design_nRF53_multi_direct.svg
+         :alt: Multiprotocol Thread and Bluetooth LE architecture (nRF53)
+
+         Multiprotocol Thread and Bluetooth LE architecture on nRF53 Series devices
 
-   Multiprotocol Thread and Bluetooth LE architecture on nRF53 Series devices
 
 For more information about the multiprotocol feature, see :ref:`ug_multiprotocol_support`.
 
@@ -149,10 +215,23 @@ It has the following disadvantages:
 
 * This is a more expensive option, because it requires a host processor for the application.
 
-.. figure:: images/thread_platform_design_ncp.svg
-   :alt: Network co-processor architecture
+Depending on integration with the Zephyr networking layer, there are two different designs:
+
+.. tabs::
+
+   .. group-tab:: Integration with Zephyr networking layer
+
+      .. figure:: images/thread_platform_design_ncp.svg
+         :alt: Network co-processor architecture
+
+         Network co-processor architecture
+
+   .. group-tab:: Direct IEEE 802.15.4 radio integration with OpenThread stack
 
-   Network co-processor architecture
+      .. figure:: images/thread_platform_design_ncp_direct.svg
+         :alt: Network co-processor architecture
+
+         Network co-processor architecture
 
 .. note::
     |connection_options_limited|
@@ -178,10 +257,23 @@ It has the following disadvantages:
 * The host processor must be woken up on each received frame, even if a frame must be forwarded to the neighboring device.
 * The RCP solution can be less responsive than the NCP solution, due to the fact that each frame or command must be communicated to the host processor over the serial link.
 
-.. figure:: images/thread_platform_design_rcp.svg
-   :alt: Radio co-processor architecture
+Depending on integration with the Zephyr networking layer, there are two different designs:
+
+.. tabs::
+
+   .. group-tab:: Integration with Zephyr networking layer
+
+      .. figure:: images/thread_platform_design_rcp.svg
+         :alt: Radio co-processor architecture
+
+         Radio co-processor architecture
+
+   .. group-tab:: Direct IEEE 802.15.4 radio integration with OpenThread stack
+
+      .. figure:: images/thread_platform_design_rcp_direct.svg
+         :alt: Radio co-processor architecture
 
-   Radio co-processor architecture
+         Radio co-processor architecture
 
 .. note::
     |connection_options_limited|