diff --git a/boards/arm/nrf52840_mdk/doc/index.rst b/boards/arm/nrf52840_mdk/doc/index.rst index fce05bee59..6e0b24b65f 100644 --- a/boards/arm/nrf52840_mdk/doc/index.rst +++ b/boards/arm/nrf52840_mdk/doc/index.rst @@ -7,7 +7,7 @@ Overview ******** The nRF52840-MDK is a versatile, easy-to-use IoT hardware platform for -Bluetooth 5, Bluetooth mesh, Thread, IEEE 802.15.4, ANT and 2.4GHz proprietary +Bluetooth 5, Bluetooth Mesh, Thread, IEEE 802.15.4, ANT and 2.4GHz proprietary applications using the nRF52840 SoC. The development kit comes with a fully integrated debugger (also known as diff --git a/boards/riscv/esp32c3_devkitm/doc/index.rst b/boards/riscv/esp32c3_devkitm/doc/index.rst index 6d21b2918c..26f1521e08 100644 --- a/boards/riscv/esp32c3_devkitm/doc/index.rst +++ b/boards/riscv/esp32c3_devkitm/doc/index.rst @@ -18,7 +18,7 @@ The features include the following: - 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz - 400 KB of internal RAM - 802.11b/g/n/e/i -- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth mesh +- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth Mesh - Various peripherals: - 12-bit ADC with up to 6 channels diff --git a/boards/riscv/esp32c3_luatos_core/doc/index.rst b/boards/riscv/esp32c3_luatos_core/doc/index.rst index c943931a9e..fae8e2eb17 100644 --- a/boards/riscv/esp32c3_luatos_core/doc/index.rst +++ b/boards/riscv/esp32c3_luatos_core/doc/index.rst @@ -18,7 +18,7 @@ The features include the following: - 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz - 400 KB of internal RAM - 802.11b/g/n/e/i -- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth mesh +- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth Mesh - Various peripherals: - 12-bit ADC with up to 6 channels diff --git a/doc/connectivity/bluetooth/api/mesh.rst b/doc/connectivity/bluetooth/api/mesh.rst index 457aa5b689..f234ff7ced 100644 --- a/doc/connectivity/bluetooth/api/mesh.rst +++ b/doc/connectivity/bluetooth/api/mesh.rst @@ -3,14 +3,14 @@ Bluetooth Mesh Profile ###################### -The Bluetooth mesh profile adds secure wireless multi-hop communication for +The Bluetooth Mesh profile adds secure wireless multi-hop communication for Bluetooth Low Energy. This module implements the `Bluetooth Mesh Profile Specification v1.0.1 `_. Implementation of the `Bluetooth Mesh Protocol Specification v1.1 `_ is in experimental state. -Read more about Bluetooth mesh on the +Read more about Bluetooth Mesh on the `Bluetooth SIG Website `_. .. toctree:: diff --git a/doc/connectivity/bluetooth/api/mesh/access.rst b/doc/connectivity/bluetooth/api/mesh/access.rst index 2af8e6a03b..e4a9444055 100644 --- a/doc/connectivity/bluetooth/api/mesh/access.rst +++ b/doc/connectivity/bluetooth/api/mesh/access.rst @@ -3,7 +3,7 @@ Access layer ############ -The access layer is the application's interface to the Bluetooth mesh network. +The access layer is the application's interface to the Bluetooth Mesh network. The access layer provides mechanisms for compartmentalizing the node behavior into elements and models, which are implemented by the application. @@ -113,7 +113,7 @@ number within one publication interval. Extended models =============== -The Bluetooth mesh specification allows the mesh models to extend each other. +The Bluetooth Mesh specification allows the mesh models to extend each other. When a model extends another, it inherits that model's functionality, and extension can be used to construct complex models out of simple ones, leveraging the existing model functionality to avoid defining new opcodes. diff --git a/doc/connectivity/bluetooth/api/mesh/blob.rst b/doc/connectivity/bluetooth/api/mesh/blob.rst index 31f4528956..8395026afe 100644 --- a/doc/connectivity/bluetooth/api/mesh/blob.rst +++ b/doc/connectivity/bluetooth/api/mesh/blob.rst @@ -5,7 +5,7 @@ BLOB Transfer models The Binary Large Object (BLOB) Transfer models implement the Bluetooth Mesh Binary Large Object Transfer Model specification version 1.0 and provide functionality for sending large binary objects -from a single source to many Target nodes over the Bluetooth mesh network. It is the underlying +from a single source to many Target nodes over the Bluetooth Mesh network. It is the underlying transport method for the :ref:`bluetooth_mesh_dfu`, but may be used for other object transfer purposes. The implementation is in experimental state. @@ -50,7 +50,7 @@ structure of the BLOB, and applications are free to define any encoding or compr on the data itself. The BLOB transfer protocol does not provide any built-in integrity checks, encryption or -authentication of the BLOB data. However, the underlying encryption of the Bluetooth mesh protocol +authentication of the BLOB data. However, the underlying encryption of the Bluetooth Mesh protocol provides data integrity checks and protects the contents of the BLOB from third parties using network and application level encryption. @@ -68,7 +68,7 @@ Chunks ------ Each block is divided into chunks. A chunk is the smallest data unit in the BLOB transfer, and must -fit inside a single Bluetooth mesh access message excluding the opcode (379 bytes or less). The +fit inside a single Bluetooth Mesh access message excluding the opcode (379 bytes or less). The mechanism for transferring chunks depends on the transfer mode. When operating in Push BLOB Transfer Mode, the chunks are sent as unacknowledged packets from the diff --git a/doc/connectivity/bluetooth/api/mesh/blob_cli.rst b/doc/connectivity/bluetooth/api/mesh/blob_cli.rst index 25b90c281c..b4193d5033 100644 --- a/doc/connectivity/bluetooth/api/mesh/blob_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/blob_cli.rst @@ -67,7 +67,7 @@ Target nodes having the BLOB Transfer Server model subscribe to this group addre Using group addresses for transferring the BLOBs can generally increase the transfer speed, as the BLOB Transfer Client sends each message to all Target nodes at the same time. However, sending -large, segmented messages to group addresses in Bluetooth mesh is generally less reliable than +large, segmented messages to group addresses in Bluetooth Mesh is generally less reliable than sending them to unicast addresses, as there is no transport layer acknowledgment mechanism for groups. This can lead to longer recovery periods at the end of each block, and increases the risk of losing Target nodes. Using group addresses for BLOB transfers will generally only pay off if the diff --git a/doc/connectivity/bluetooth/api/mesh/blob_srv.rst b/doc/connectivity/bluetooth/api/mesh/blob_srv.rst index 918b9493ff..0d13e92148 100644 --- a/doc/connectivity/bluetooth/api/mesh/blob_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/blob_srv.rst @@ -77,7 +77,7 @@ Transfer recovery ***************** The state of the BLOB transfer is stored persistently. If a reboot occurs, the BLOB Transfer Server -will attempt to recover the transfer. When the Bluetooth mesh subsystem is started (for instance by +will attempt to recover the transfer. When the Bluetooth Mesh subsystem is started (for instance by calling :c:func:`bt_mesh_init`), the BLOB Transfer Server will check for aborted transfers, and call the :c:member:`recover ` callback if there is any. In the recover callback, the user must provide a BLOB stream to use for the rest of the transfer. If the recover diff --git a/doc/connectivity/bluetooth/api/mesh/cfg.rst b/doc/connectivity/bluetooth/api/mesh/cfg.rst index 01d3c9ca2e..e178984210 100644 --- a/doc/connectivity/bluetooth/api/mesh/cfg.rst +++ b/doc/connectivity/bluetooth/api/mesh/cfg.rst @@ -6,7 +6,7 @@ Runtime Configuration The runtime configuration API allows applications to change their runtime configuration directly, without going through the Configuration models. -Bluetooth mesh nodes should generally be configured by a central network +Bluetooth Mesh nodes should generally be configured by a central network configurator device with a :ref:`bluetooth_mesh_models_cfg_cli` model. Each mesh node instantiates a :ref:`bluetooth_mesh_models_cfg_srv` model that the Configuration Client can communicate with to change the node configuration. In some diff --git a/doc/connectivity/bluetooth/api/mesh/cfg_cli.rst b/doc/connectivity/bluetooth/api/mesh/cfg_cli.rst index bf84edc6b8..300c8ee3bc 100644 --- a/doc/connectivity/bluetooth/api/mesh/cfg_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/cfg_cli.rst @@ -3,7 +3,7 @@ Configuration Client #################### -The Configuration Client model is a foundation model defined by the Bluetooth mesh +The Configuration Client model is a foundation model defined by the Bluetooth Mesh specification. It provides functionality for configuring most parameters of a mesh node, including encryption keys, model configuration and feature enabling. diff --git a/doc/connectivity/bluetooth/api/mesh/cfg_srv.rst b/doc/connectivity/bluetooth/api/mesh/cfg_srv.rst index 84f174df88..8f595bf9b1 100644 --- a/doc/connectivity/bluetooth/api/mesh/cfg_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/cfg_srv.rst @@ -3,7 +3,7 @@ Configuration Server #################### -The Configuration Server model is a foundation model defined by the Bluetooth mesh +The Configuration Server model is a foundation model defined by the Bluetooth Mesh specification. The Configuration Server model controls most parameters of the mesh node. It does not have an API of its own, but relies on a :ref:`bluetooth_mesh_models_cfg_cli` to control it. @@ -14,7 +14,7 @@ mesh node. It does not have an API of its own, but relies on a should be set through Kconfig, and the Heartbeat feature should be controlled through the :ref:`bluetooth_mesh_heartbeat` API. -The Configuration Server model is mandatory on all Bluetooth mesh nodes, and +The Configuration Server model is mandatory on all Bluetooth Mesh nodes, and must only be instantiated on the primary element. API reference diff --git a/doc/connectivity/bluetooth/api/mesh/core.rst b/doc/connectivity/bluetooth/api/mesh/core.rst index b9fdd16425..94e2b8a6e5 100644 --- a/doc/connectivity/bluetooth/api/mesh/core.rst +++ b/doc/connectivity/bluetooth/api/mesh/core.rst @@ -3,7 +3,7 @@ Core #### -The core provides functionality for managing the general Bluetooth mesh +The core provides functionality for managing the general Bluetooth Mesh state. .. _bluetooth_mesh_lpn: @@ -117,7 +117,7 @@ Advertisement identity All mesh stack bearers advertise data with the :c:macro:`BT_ID_DEFAULT` local identity. The value is preset in the mesh stack implementation. When Bluetooth® Low Energy (LE) -and Bluetooth mesh coexist on the same device, the application should allocate and +and Bluetooth Mesh coexist on the same device, the application should allocate and configure another local identity for Bluetooth LE purposes before starting the communication. API reference diff --git a/doc/connectivity/bluetooth/api/mesh/dfu.rst b/doc/connectivity/bluetooth/api/mesh/dfu.rst index 9cf55e244d..6718b3ea0c 100644 --- a/doc/connectivity/bluetooth/api/mesh/dfu.rst +++ b/doc/connectivity/bluetooth/api/mesh/dfu.rst @@ -3,16 +3,16 @@ Device Firmware Update (DFU) ############################ -Bluetooth mesh supports the distribution of firmware images across a mesh network. The Bluetooth +Bluetooth Mesh supports the distribution of firmware images across a mesh network. The Bluetooth mesh DFU subsystem implements the Bluetooth Mesh Device Firmware Update Model specification version 1.0. The implementation is in experimental state. -Bluetooth mesh DFU implements a distribution mechanism for firmware images, and does not put any +Bluetooth Mesh DFU implements a distribution mechanism for firmware images, and does not put any restrictions on the size, format or usage of the images. The primary design goal of the subsystem is -to provide the qualifiable parts of the Bluetooth mesh DFU specification, and leave the usage, +to provide the qualifiable parts of the Bluetooth Mesh DFU specification, and leave the usage, firmware validation and deployment to the application. -The DFU specification is implemented in the Zephyr Bluetooth mesh DFU subsystem as three separate +The DFU specification is implemented in the Zephyr Bluetooth Mesh DFU subsystem as three separate models: .. toctree:: @@ -28,7 +28,7 @@ Overview DFU roles ========= -The Bluetooth mesh DFU subsystem defines three different roles the mesh nodes have to assume in the +The Bluetooth Mesh DFU subsystem defines three different roles the mesh nodes have to assume in the distribution of firmware images: Target node @@ -47,20 +47,20 @@ Distributor image to the Target nodes. Initiator - The Initiator role is typically implemented by the same device that implements the Bluetooth mesh + The Initiator role is typically implemented by the same device that implements the Bluetooth Mesh :ref:`Provisioner ` and :ref:`Configurator ` roles. The Initiator needs a full overview of the potential Target nodes and their firmware, and will control (and initiate) all firmware updates. The - Initiator role is not implemented in the Zephyr Bluetooth mesh DFU subsystem. + Initiator role is not implemented in the Zephyr Bluetooth Mesh DFU subsystem. .. figure:: images/dfu_roles_mesh.svg :align: center :alt: Graphic overview of the DFU roles mesh nodes can have during the process of image distribution - DFU roles and the associated Bluetooth mesh models + DFU roles and the associated Bluetooth Mesh models -Bluetooth mesh applications may combine the DFU roles in any way they'd like, and even take on +Bluetooth Mesh applications may combine the DFU roles in any way they'd like, and even take on multiple instances of the same role by instantiating the models on separate elements. For instance, the Distributor and Initiator role can be combined by instantiating the :ref:`bluetooth_mesh_dfu_cli` on the Initiator node and calling its API directly. @@ -76,7 +76,7 @@ Firmware Update Client model directly, e.g. over a serial protocol. Stages ====== -The Bluetooth mesh DFU process is designed to act in three stages: +The Bluetooth Mesh DFU process is designed to act in three stages: Upload stage First, the image is uploaded to a Distributor in a mesh network by an external entity, such as a @@ -131,7 +131,7 @@ Firmware metadata Target node. The firmware metadata is optional, and its maximum length is determined by :kconfig:option:`CONFIG_BT_MESH_DFU_METADATA_MAXLEN`. - The Bluetooth mesh DFU subsystem in Zephyr provides its own metadata format + The Bluetooth Mesh DFU subsystem in Zephyr provides its own metadata format (:c:struct:`bt_mesh_dfu_metadata`) together with a set of related functions that can be used by an end product. The support for it is enabled using the :kconfig:option:`CONFIG_BT_MESH_DFU_METADATA` option. The format of the metadata is presented in @@ -299,7 +299,7 @@ following steps: node firmware image index and the firmware image metadata. Each Target node performs a metadata check and prepares their BLOB Transfer Server model for the transfer, before sending a status response to the Firmware Update Client, indicating if the firmware update will have any effect on - the Bluetooth mesh state of the node. + the Bluetooth Mesh state of the node. #. The Distributor's BLOB Transfer Client model transfers the firmware image to all Target nodes. #. Once the BLOB transfer has been received, the Target nodes' applications verify that the firmware is valid by performing checks such as signature verification or image checksums against the image diff --git a/doc/connectivity/bluetooth/api/mesh/dfu_srv.rst b/doc/connectivity/bluetooth/api/mesh/dfu_srv.rst index 2642dec8cc..105bdecb86 100644 --- a/doc/connectivity/bluetooth/api/mesh/dfu_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/dfu_srv.rst @@ -16,7 +16,7 @@ Firmware images The Firmware Update Server holds a list of all the updatable firmware images on the device. The full list shall be passed to the server through the ``_imgs`` parameter in -:c:macro:`BT_MESH_DFU_SRV_INIT`, and must be populated before the Bluetooth mesh subsystem is +:c:macro:`BT_MESH_DFU_SRV_INIT`, and must be populated before the Bluetooth Mesh subsystem is started. Each firmware image in the image list must be independently updatable, and should have its own firmware ID. @@ -33,9 +33,9 @@ application is described below: .. figure:: images/dfu_srv.svg :align: center - :alt: Bluetooth mesh Firmware Update Server transfer + :alt: Bluetooth Mesh Firmware Update Server transfer - Bluetooth mesh Firmware Update Server transfer + Bluetooth Mesh Firmware Update Server transfer Transfer check ============== @@ -118,7 +118,7 @@ updated image. When the transfer applies to the mesh application itself, the device might have to reboot as part of the swap. This restart can be performed from inside the apply callback, or done asynchronously. After booting up with the new firmware, the firmware image table should be updated before the -Bluetooth mesh subsystem is started. +Bluetooth Mesh subsystem is started. The Distributor will read out the firmware image table to confirm that the transfer was successfully applied. If the metadata check indicated that the device would become unprovisioned, the Target node diff --git a/doc/connectivity/bluetooth/api/mesh/health_srv.rst b/doc/connectivity/bluetooth/api/mesh/health_srv.rst index 84c543b476..6f7b1fc3f3 100644 --- a/doc/connectivity/bluetooth/api/mesh/health_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/health_srv.rst @@ -21,7 +21,7 @@ necessarily damaging to the device. Errors indicate conditions that are outside of the node's design limits, and may have caused invalid behavior or permanent damage to the device. -Fault values ``0x01`` to ``0x7f`` are reserved for the Bluetooth mesh +Fault values ``0x01`` to ``0x7f`` are reserved for the Bluetooth Mesh specification, and the full list of specification defined faults are available in :ref:`bluetooth_mesh_health_faults`. Fault values ``0x80`` to ``0xff`` are vendor specific. The list of faults are always reported with a company ID to @@ -57,6 +57,6 @@ API reference Health faults ============= -Fault values defined by the Bluetooth mesh specification. +Fault values defined by the Bluetooth Mesh specification. .. doxygengroup:: bt_mesh_health_faults diff --git a/doc/connectivity/bluetooth/api/mesh/heartbeat.rst b/doc/connectivity/bluetooth/api/mesh/heartbeat.rst index 16c2bfa784..706625849c 100644 --- a/doc/connectivity/bluetooth/api/mesh/heartbeat.rst +++ b/doc/connectivity/bluetooth/api/mesh/heartbeat.rst @@ -3,7 +3,7 @@ Heartbeat ######### -The Heartbeat feature provides functionality for monitoring Bluetooth mesh nodes +The Heartbeat feature provides functionality for monitoring Bluetooth Mesh nodes and determining the distance between nodes. The Heartbeat feature is configured through the :ref:`bluetooth_mesh_models_cfg_srv` model. diff --git a/doc/connectivity/bluetooth/api/mesh/lcd_cli.rst b/doc/connectivity/bluetooth/api/mesh/lcd_cli.rst index 0eca28f1b2..96189e21dd 100644 --- a/doc/connectivity/bluetooth/api/mesh/lcd_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/lcd_cli.rst @@ -3,7 +3,7 @@ Large Composition Data Client ############################# -The Large Composition Data Client model is a foundation model defined by the Bluetooth mesh +The Large Composition Data Client model is a foundation model defined by the Bluetooth Mesh specification. The model is optional, and is enabled through the :kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_CLI` option. diff --git a/doc/connectivity/bluetooth/api/mesh/lcd_srv.rst b/doc/connectivity/bluetooth/api/mesh/lcd_srv.rst index f96436138b..f67b31c27f 100644 --- a/doc/connectivity/bluetooth/api/mesh/lcd_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/lcd_srv.rst @@ -3,7 +3,7 @@ Large Composition Data Server ############################# -The Large Composition Data Server model is a foundation model defined by the Bluetooth mesh +The Large Composition Data Server model is a foundation model defined by the Bluetooth Mesh specification. The model is optional, and is enabled through the :kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_SRV` option. diff --git a/doc/connectivity/bluetooth/api/mesh/models.rst b/doc/connectivity/bluetooth/api/mesh/models.rst index 3f5f94152c..94c3914ca5 100644 --- a/doc/connectivity/bluetooth/api/mesh/models.rst +++ b/doc/connectivity/bluetooth/api/mesh/models.rst @@ -6,7 +6,7 @@ Mesh models Foundation models ***************** -The Bluetooth mesh specification defines foundation models that can be +The Bluetooth Mesh specification defines foundation models that can be used by network administrators to configure and diagnose mesh nodes. .. toctree:: @@ -34,7 +34,7 @@ used by network administrators to configure and diagnose mesh nodes. Model specification models ************************** -In addition to the foundation models defined in the Bluetooth mesh specification, the Bluetooth Mesh +In addition to the foundation models defined in the Bluetooth Mesh specification, the Bluetooth Mesh Model Specification defines several models, some of which are implemented in Zephyr: .. toctree:: diff --git a/doc/connectivity/bluetooth/api/mesh/msg.rst b/doc/connectivity/bluetooth/api/mesh/msg.rst index ae8b968198..614d2604d9 100644 --- a/doc/connectivity/bluetooth/api/mesh/msg.rst +++ b/doc/connectivity/bluetooth/api/mesh/msg.rst @@ -3,7 +3,7 @@ Message ####### -The Bluetooth mesh message provides set of structures, macros and functions used +The Bluetooth Mesh message provides set of structures, macros and functions used for preparing message buffers, managing message and acknowledged message contexts. diff --git a/doc/connectivity/bluetooth/api/mesh/od_cli.rst b/doc/connectivity/bluetooth/api/mesh/od_cli.rst index 5fc841716c..e419acb757 100644 --- a/doc/connectivity/bluetooth/api/mesh/od_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/od_cli.rst @@ -3,7 +3,7 @@ On-Demand Private Proxy Client ############################## -The On-Demand Private Proxy Client model is a foundation model defined by the Bluetooth mesh +The On-Demand Private Proxy Client model is a foundation model defined by the Bluetooth Mesh specification. The model is optional, and is enabled with the :kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_CLI` option. diff --git a/doc/connectivity/bluetooth/api/mesh/od_srv.rst b/doc/connectivity/bluetooth/api/mesh/od_srv.rst index 700517e428..3c2f993bb3 100644 --- a/doc/connectivity/bluetooth/api/mesh/od_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/od_srv.rst @@ -3,7 +3,7 @@ On-Demand Private Proxy Server ############################## -The On-Demand Private Proxy Server model is a foundation model defined by the Bluetooth mesh +The On-Demand Private Proxy Server model is a foundation model defined by the Bluetooth Mesh specification. It is enabled with the :kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_SRV` option. The On-Demand Private Proxy Server model was introduced in the Bluetooth Mesh Protocol Specification diff --git a/doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst b/doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst index 148557a4e8..4648b4495c 100644 --- a/doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst @@ -3,7 +3,7 @@ Opcodes Aggregator Client ######################### -The Opcodes Aggregator Client model is a foundation model defined by the Bluetooth mesh +The Opcodes Aggregator Client model is a foundation model defined by the Bluetooth Mesh specification. It is an optional model, enabled with the :kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI` option. diff --git a/doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst b/doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst index cb531a4c3c..c9bcc8e5eb 100644 --- a/doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst @@ -11,7 +11,7 @@ The Private Beacon Client model is introduced in the Bluetooth Mesh Protocol Specification version 1.1, and provides functionality for configuring the :ref:`bluetooth_mesh_models_priv_beacon_srv` models. -The Private Beacons feature adds privacy to the different Bluetooth mesh +The Private Beacons feature adds privacy to the different Bluetooth Mesh beacons by periodically randomizing the beacon input data. This protects the mesh node from being tracked by devices outside the mesh network, and hides the network's IV index, IV update and the Key Refresh state. diff --git a/doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst b/doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst index 3c17cc4467..62450634a3 100644 --- a/doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst @@ -11,7 +11,7 @@ The Private Beacon Server model is introduced in the Bluetooth Mesh Protocol Specification version 1.1, and controls the mesh node's Private Beacon state, Private GATT Proxy state and Private Node Identity state. -The Private Beacons feature adds privacy to the different Bluetooth mesh +The Private Beacons feature adds privacy to the different Bluetooth Mesh beacons by periodically randomizing the beacon input data. This protects the mesh node from being tracked by devices outside the mesh network, and hides the network's IV index, IV update and the Key Refresh state. The Private Beacon Server diff --git a/doc/connectivity/bluetooth/api/mesh/provisioning.rst b/doc/connectivity/bluetooth/api/mesh/provisioning.rst index 36fa38927a..685c9dda45 100644 --- a/doc/connectivity/bluetooth/api/mesh/provisioning.rst +++ b/doc/connectivity/bluetooth/api/mesh/provisioning.rst @@ -12,15 +12,15 @@ two devices operating in the following roles: Provisioning process. Before the provisioning process starts, the provisionee is an *unprovisioned device*. -The Provisioning module in the Zephyr Bluetooth mesh stack supports both the +The Provisioning module in the Zephyr Bluetooth Mesh stack supports both the Advertising and GATT Provisioning bearers for the provisionee role, as well as the Advertising Provisioning bearer for the provisioner role. The Provisioning process ************************ -All Bluetooth mesh nodes must be provisioned before they can participate in a -Bluetooth mesh network. The Provisioning API provides all the functionality +All Bluetooth Mesh nodes must be provisioned before they can participate in a +Bluetooth Mesh network. The Provisioning API provides all the functionality necessary for a device to become a provisioned mesh node. Provisioning is a five-step process, involving the following steps: @@ -176,7 +176,7 @@ Depending on the choice of public key exchange mechanism and authentication meth the provisioning process can be secure or insecure. On May 24th 2021, ANSSI `disclosed `_ -a set of vulnerabilities in the Bluetooth mesh provisioning protocol that showcased +a set of vulnerabilities in the Bluetooth Mesh provisioning protocol that showcased how the low entropy provided by the Blink, Vibrate, Push, Twist and Input/Output numeric OOB methods could be exploited in impersonation and MITM attacks. In response, the Bluetooth SIG has reclassified these OOB methods as diff --git a/doc/connectivity/bluetooth/api/mesh/proxy.rst b/doc/connectivity/bluetooth/api/mesh/proxy.rst index 823401c957..5e905f2c9e 100644 --- a/doc/connectivity/bluetooth/api/mesh/proxy.rst +++ b/doc/connectivity/bluetooth/api/mesh/proxy.rst @@ -3,7 +3,7 @@ Proxy ##### -The Proxy feature allows legacy devices like phones to access the Bluetooth mesh network through +The Proxy feature allows legacy devices like phones to access the Bluetooth Mesh network through GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY` option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`, and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`. diff --git a/doc/connectivity/bluetooth/api/mesh/sar_cfg.rst b/doc/connectivity/bluetooth/api/mesh/sar_cfg.rst index a0aa2b46a3..4f3354945c 100644 --- a/doc/connectivity/bluetooth/api/mesh/sar_cfg.rst +++ b/doc/connectivity/bluetooth/api/mesh/sar_cfg.rst @@ -4,7 +4,7 @@ Segmentation and reassembly (SAR) ################################# Segmentation and reassembly (SAR) provides a way of handling larger upper transport layer messages -in a mesh network, with a purpose of enhancing the Bluetooth mesh throughput. The segmentation and +in a mesh network, with a purpose of enhancing the Bluetooth Mesh throughput. The segmentation and reassembly mechanism is used by the lower transport layer. The lower transport layer defines how the upper transport layer PDUs are segmented and reassembled @@ -23,7 +23,7 @@ required. Set the ``send rel`` flag (see :c:struct:`bt_mesh_msg_ctx`) to use the transmission and acknowledge single-segment segmented messages. The transport layer is able to transport up to 32 segments with its SAR mechanism, with a maximum -message (PDU) size of 384 octets. To configure message size for the Bluetooth mesh stack, use the +message (PDU) size of 384 octets. To configure message size for the Bluetooth Mesh stack, use the following Kconfig options: * :kconfig:option:`CONFIG_BT_MESH_RX_SEG_MAX` to set the maximum number of segments in an incoming message. diff --git a/doc/connectivity/bluetooth/api/mesh/sar_cfg_cli.rst b/doc/connectivity/bluetooth/api/mesh/sar_cfg_cli.rst index b017b53a01..1e2ab6c47a 100644 --- a/doc/connectivity/bluetooth/api/mesh/sar_cfg_cli.rst +++ b/doc/connectivity/bluetooth/api/mesh/sar_cfg_cli.rst @@ -3,7 +3,7 @@ SAR Configuration Client ######################## -The SAR Configuration Client model is a foundation model defined by the Bluetooth mesh +The SAR Configuration Client model is a foundation model defined by the Bluetooth Mesh specification. It is an optional model, enabled with the :kconfig:option:`CONFIG_BT_MESH_SAR_CFG_CLI` configuration option. diff --git a/doc/connectivity/bluetooth/api/mesh/sar_cfg_srv.rst b/doc/connectivity/bluetooth/api/mesh/sar_cfg_srv.rst index 2ea1446c9e..4280fae135 100644 --- a/doc/connectivity/bluetooth/api/mesh/sar_cfg_srv.rst +++ b/doc/connectivity/bluetooth/api/mesh/sar_cfg_srv.rst @@ -3,13 +3,13 @@ SAR Configuration Server ######################## -The SAR Configuration Server model is a foundation model defined by the Bluetooth mesh +The SAR Configuration Server model is a foundation model defined by the Bluetooth Mesh specification. It is an optional model, enabled with the :kconfig:option:`CONFIG_BT_MESH_SAR_CFG_SRV` configuration option. The SAR Configuration Server model is introduced in the Bluetooth Mesh Protocol Specification version 1.1, and it supports the configuration of the -:ref:`segmentation and reassembly (SAR) ` behavior of a Bluetooth mesh node. +:ref:`segmentation and reassembly (SAR) ` behavior of a Bluetooth Mesh node. The model defines a set of states and messages for the SAR configuration. The SAR Configuration Server model defines two states, SAR Transmitter state and SAR Receiver state. diff --git a/doc/connectivity/bluetooth/api/mesh/shell.rst b/doc/connectivity/bluetooth/api/mesh/shell.rst index 66bfcdf616..9d5829fe38 100644 --- a/doc/connectivity/bluetooth/api/mesh/shell.rst +++ b/doc/connectivity/bluetooth/api/mesh/shell.rst @@ -3,32 +3,32 @@ Bluetooth Mesh Shell #################### -The Bluetooth mesh shell subsystem provides a set of Bluetooth mesh shell commands for the -:ref:`shell_api` module. It allows for testing and exploring the Bluetooth mesh API through an +The Bluetooth Mesh shell subsystem provides a set of Bluetooth Mesh shell commands for the +:ref:`shell_api` module. It allows for testing and exploring the Bluetooth Mesh API through an interactive interface, without having to write an application. -The Bluetooth mesh shell interface provides access to most Bluetooth mesh features, including +The Bluetooth Mesh shell interface provides access to most Bluetooth Mesh features, including provisioning, configuration, and message sending. Prerequisites ************* -The Bluetooth mesh shell subsystem depends on the application to create the composition data and do +The Bluetooth Mesh shell subsystem depends on the application to create the composition data and do the mesh initialization. Application *********** -The Bluetooth mesh shell subsystem is most easily used through the Bluetooth mesh shell application +The Bluetooth Mesh shell subsystem is most easily used through the Bluetooth Mesh shell application under ``tests/bluetooth/mesh_shell``. See :ref:`shell_api` for information on how to connect and -interact with the Bluetooth mesh shell application. +interact with the Bluetooth Mesh shell application. Basic usage *********** -The Bluetooth mesh shell subsystem adds a single ``mesh`` command, which holds a set of +The Bluetooth Mesh shell subsystem adds a single ``mesh`` command, which holds a set of sub-commands. Every time the device boots up, make sure to call ``mesh init`` before any of the -other Bluetooth mesh shell commands can be called:: +other Bluetooth Mesh shell commands can be called:: uart:~$ mesh init @@ -82,7 +82,7 @@ Message sending =============== With an application key added (see above), the mesh node's transition parameters are all valid, and -the Bluetooth mesh shell can send raw mesh messages through the network. +the Bluetooth Mesh shell can send raw mesh messages through the network. For example, to send a Generic OnOff Set message, call:: @@ -107,7 +107,7 @@ configured network and application keys will receive and process the messages we Sending raw mesh packets is a good way to test model message handler implementations during development, as it can be done without having to implement the sending model. By default, only the -reception of the model messages can be tested this way, as the Bluetooth mesh shell only includes +reception of the model messages can be tested this way, as the Bluetooth Mesh shell only includes the foundation models. To receive a packet in the mesh node, you have to add a model with a valid opcode handler list to the composition data in ``subsys/bluetooth/mesh/shell.c``, and print the incoming message to the shell in the handler callback. @@ -115,7 +115,7 @@ incoming message to the shell in the handler callback. Parameter formats ***************** -The Bluetooth mesh shell commands are parsed with a variety of formats: +The Bluetooth Mesh shell commands are parsed with a variety of formats: .. list-table:: Parameter formats :widths: 1 4 2 @@ -139,12 +139,12 @@ The Bluetooth mesh shell commands are parsed with a variety of formats: Commands ******** -The Bluetooth mesh shell implements a large set of commands. Some of the commands accept parameters, +The Bluetooth Mesh shell implements a large set of commands. Some of the commands accept parameters, which are mentioned in brackets after the command name. For example, ``mesh lpn set ``. Mandatory parameters are marked with angle brackets (e.g. ````), and optional parameters are marked with square brackets (e.g. ``[DstAddr]``). -The Bluetooth mesh shell commands are divided into the following groups: +The Bluetooth Mesh shell commands are divided into the following groups: .. contents:: :depth: 1 @@ -500,10 +500,10 @@ application. This shell module can be used for configuring itself and other node network. The Configuration Client uses general message parameters set by ``mesh target dst`` and ``mesh -target net`` to target specific nodes. When the Bluetooth mesh shell node is provisioned, given that +target net`` to target specific nodes. When the Bluetooth Mesh shell node is provisioned, given that the :kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option is enabled with the shell provisioning context initialized, the Configuration Client model targets itself by default. -Similarly, when another node has been provisioned by the Bluetooth mesh shell, the Configuration +Similarly, when another node has been provisioned by the Bluetooth Mesh shell, the Configuration Client model targets the new node. In most common use-cases, the Configuration Client is depending on the provisioning features and the Configuration database to be fully functional. The Configuration Client always sends messages using the Device key bound to the destination address, so @@ -1645,7 +1645,7 @@ The Private Beacon Client model is an optional mesh subsystem that can be enable Opcodes Aggregator Client ------------------------- -The Opcodes Aggregator client is an optional Bluetooth mesh model that can be enabled through the +The Opcodes Aggregator client is an optional Bluetooth Mesh model that can be enabled through the :kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI` configuration option. The Opcodes Aggregator Client model is used to support the functionality of dispatching a sequence of access layer messages to nodes supporting the Opcodes Aggregator Server model. @@ -1675,7 +1675,7 @@ nodes supporting the Opcodes Aggregator Server model. Remote Provisioning Client -------------------------- -The Remote Provisioning Client is an optional Bluetooth mesh model enabled through the +The Remote Provisioning Client is an optional Bluetooth Mesh model enabled through the :kconfig:option:`CONFIG_BT_MESH_RPR_CLI` configuration option. The Remote Provisioning Client model provides support for remote provisioning of devices into a mesh network by using the Remote Provisioning Server model. diff --git a/doc/connectivity/bluetooth/bluetooth-arch.rst b/doc/connectivity/bluetooth/bluetooth-arch.rst index 9b455e680d..ed0cf1ea9f 100644 --- a/doc/connectivity/bluetooth/bluetooth-arch.rst +++ b/doc/connectivity/bluetooth/bluetooth-arch.rst @@ -248,7 +248,7 @@ Each role comes with its own build-time configuration option: connection-oriented roles central implicitly enables observer role, and peripheral implicitly enables broadcaster role. Usually the first step when creating an application is to decide which roles are needed and go -from there. Bluetooth mesh is a slightly special case, requiring at +from there. Bluetooth Mesh is a slightly special case, requiring at least the observer and broadcaster roles, and possibly also the Peripheral role. This will be described in more detail in a later section. diff --git a/doc/connectivity/bluetooth/overview.rst b/doc/connectivity/bluetooth/overview.rst index fece4ade49..1f727736b2 100644 --- a/doc/connectivity/bluetooth/overview.rst +++ b/doc/connectivity/bluetooth/overview.rst @@ -76,7 +76,7 @@ Bluetooth stack. * Non-volatile storage support for permanent storage of Bluetooth-specific settings and data - * Bluetooth mesh support + * Bluetooth Mesh support * Relay, Friend Node, Low-Power Node (LPN) and GATT Proxy features * Both Provisioning roles and bearers supported (PB-ADV & PB-GATT) diff --git a/doc/introduction/index.rst b/doc/introduction/index.rst index 985ffe8e00..f8b841ae30 100644 --- a/doc/introduction/index.rst +++ b/doc/introduction/index.rst @@ -125,7 +125,7 @@ Zephyr offers a large and ever growing number of features including: **Bluetooth Low Energy 5.0 support** Bluetooth 5.0 compliant (ESR10) and Bluetooth Low Energy Controller support - (LE Link Layer). Includes Bluetooth mesh and a Bluetooth qualification-ready + (LE Link Layer). Includes Bluetooth Mesh and a Bluetooth qualification-ready Bluetooth controller. * Generic Access Profile (GAP) with all possible LE roles diff --git a/doc/kernel/timeutil.rst b/doc/kernel/timeutil.rst index d41c5b48b8..203d52ea9a 100644 --- a/doc/kernel/timeutil.rst +++ b/doc/kernel/timeutil.rst @@ -223,7 +223,7 @@ include: - GPS time: epoch of 1980-01-06T00:00:00Z, continuous following TAI with an offset of TAI-GPS=19 s. -- Bluetooth mesh time: epoch of 2000-01-01T00:00:00Z, continuous following TAI +- Bluetooth Mesh time: epoch of 2000-01-01T00:00:00Z, continuous following TAI with an offset of -32. - UNIX Leap Time: epoch of 1970-01-01T00:00:00Z, continuous following TAI with an offset of -8. diff --git a/doc/security/vulnerabilities.rst b/doc/security/vulnerabilities.rst index eb2e4e4722..d8e4a2a56c 100644 --- a/doc/security/vulnerabilities.rst +++ b/doc/security/vulnerabilities.rst @@ -1176,7 +1176,7 @@ This has been fixed in main for v3.0.0 CVE-2022-1041 -------------- -Out-of-bound write vulnerability in the Bluetooth mesh core stack can be triggered during provisioning +Out-of-bound write vulnerability in the Bluetooth Mesh core stack can be triggered during provisioning This has been fixed in main for v3.1.0 @@ -1195,7 +1195,7 @@ This has been fixed in main for v3.1.0 CVE-2022-1042 -------------- -Out-of-bound write vulnerability in the Bluetooth mesh core stack can be triggered during provisioning +Out-of-bound write vulnerability in the Bluetooth Mesh core stack can be triggered during provisioning This has been fixed in main for v3.1.0 diff --git a/include/zephyr/bluetooth/mesh.h b/include/zephyr/bluetooth/mesh.h index a4ef70dc6d..fc84814fa4 100644 --- a/include/zephyr/bluetooth/mesh.h +++ b/include/zephyr/bluetooth/mesh.h @@ -1,5 +1,5 @@ /** @file - * @brief Bluetooth mesh Profile APIs. + * @brief Bluetooth Mesh Profile APIs. */ /* diff --git a/include/zephyr/bluetooth/mesh/blob_srv.h b/include/zephyr/bluetooth/mesh/blob_srv.h index bf807bad92..92c809bd6b 100644 --- a/include/zephyr/bluetooth/mesh/blob_srv.h +++ b/include/zephyr/bluetooth/mesh/blob_srv.h @@ -108,7 +108,7 @@ struct bt_mesh_blob_srv_cb { /** @brief Transfer recovery callback. * - * Called when the Bluetooth mesh subsystem is started if the device is rebooted + * Called when the Bluetooth Mesh subsystem is started if the device is rebooted * in the middle of a transfer. * * Transfers will not be resumed after a reboot if this callback is not diff --git a/include/zephyr/bluetooth/mesh/cfg.h b/include/zephyr/bluetooth/mesh/cfg.h index 7d1ca4e868..9bfd067da9 100644 --- a/include/zephyr/bluetooth/mesh/cfg.h +++ b/include/zephyr/bluetooth/mesh/cfg.h @@ -26,7 +26,7 @@ extern "C" { #endif -/** Bluetooth mesh feature states */ +/** Bluetooth Mesh feature states */ enum bt_mesh_feat_state { /** Feature is supported, but disabled. */ BT_MESH_FEATURE_DISABLED, diff --git a/include/zephyr/bluetooth/mesh/dfu_cli.h b/include/zephyr/bluetooth/mesh/dfu_cli.h index 3cbc220d82..ad8881ebc2 100644 --- a/include/zephyr/bluetooth/mesh/dfu_cli.h +++ b/include/zephyr/bluetooth/mesh/dfu_cli.h @@ -9,7 +9,7 @@ * @defgroup bt_mesh_dfu_cli Firmware Uppdate Client model * @ingroup bt_mesh_dfu * @{ - * @brief API for the Bluetooth mesh Firmware Update Client model + * @brief API for the Bluetooth Mesh Firmware Update Client model */ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_CLI_H__ diff --git a/include/zephyr/bluetooth/mesh/dfu_metadata.h b/include/zephyr/bluetooth/mesh/dfu_metadata.h index bec65897ac..21d032236a 100644 --- a/include/zephyr/bluetooth/mesh/dfu_metadata.h +++ b/include/zephyr/bluetooth/mesh/dfu_metadata.h @@ -6,10 +6,10 @@ /** * @file - * @defgroup bt_mesh_dfu_metadata Bluetooth mesh Device Firmware Update (DFU) metadata + * @defgroup bt_mesh_dfu_metadata Bluetooth Mesh Device Firmware Update (DFU) metadata * @ingroup bt_mesh_dfu * @{ - * @brief Common types and functions for the Bluetooth mesh DFU metadata. + * @brief Common types and functions for the Bluetooth Mesh DFU metadata. */ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_METADATA_H__ diff --git a/include/zephyr/bluetooth/mesh/dfu_srv.h b/include/zephyr/bluetooth/mesh/dfu_srv.h index e136701e66..2beaf2d977 100644 --- a/include/zephyr/bluetooth/mesh/dfu_srv.h +++ b/include/zephyr/bluetooth/mesh/dfu_srv.h @@ -9,7 +9,7 @@ * @defgroup bt_mesh_dfu_srv Firmware Update Server model * @ingroup bt_mesh_dfu * @{ - * @brief API for the Bluetooth mesh Firmware Update Server model + * @brief API for the Bluetooth Mesh Firmware Update Server model */ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_SRV_H__ @@ -136,7 +136,7 @@ struct bt_mesh_dfu_srv_cb { /** @brief Transfer recovery callback. * * If the device reboots in the middle of a transfer, the Firmware Update Server - * calls this function when the Bluetooth mesh subsystem is started. + * calls this function when the Bluetooth Mesh subsystem is started. * * This callback is optional, but transfers will not be recovered after * a reboot without it. diff --git a/include/zephyr/bluetooth/mesh/main.h b/include/zephyr/bluetooth/mesh/main.h index a4e98b97f8..8e7445fae6 100644 --- a/include/zephyr/bluetooth/mesh/main.h +++ b/include/zephyr/bluetooth/mesh/main.h @@ -1,5 +1,5 @@ /** @file - * @brief Bluetooth mesh Protocol APIs. + * @brief Bluetooth Mesh Protocol APIs. */ /* @@ -550,8 +550,8 @@ bool bt_mesh_is_provisioned(void); */ /** - * @brief Bluetooth mesh - * @defgroup bt_mesh Bluetooth mesh + * @brief Bluetooth Mesh + * @defgroup bt_mesh Bluetooth Mesh * @ingroup bluetooth * @{ */ diff --git a/samples/bluetooth/mesh/README.rst b/samples/bluetooth/mesh/README.rst index e6ee78ba3a..58532a0600 100644 --- a/samples/bluetooth/mesh/README.rst +++ b/samples/bluetooth/mesh/README.rst @@ -6,7 +6,7 @@ Bluetooth: Mesh Overview ******** -This sample demonstrates Bluetooth mesh functionality. It has several +This sample demonstrates Bluetooth Mesh functionality. It has several standard mesh models, and supports provisioning over both the Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). The application also needs a functioning serial console, since that's diff --git a/samples/bluetooth/mesh_demo/README.rst b/samples/bluetooth/mesh_demo/README.rst index 7fe7f0908c..2edb690ab1 100644 --- a/samples/bluetooth/mesh_demo/README.rst +++ b/samples/bluetooth/mesh_demo/README.rst @@ -6,7 +6,7 @@ Bluetooth: Mesh Demo Overview ******** -This sample is a Bluetooth mesh application intended for demonstration +This sample is a Bluetooth Mesh application intended for demonstration purposes only. The application provisions and configures itself (i.e. no external provisioner needed) with hard-coded network and application key values. The local unicast address can be set using a NODE_ADDR build diff --git a/samples/bluetooth/mesh_provisioner/README.rst b/samples/bluetooth/mesh_provisioner/README.rst index 6da113afc1..1b37a04a4a 100644 --- a/samples/bluetooth/mesh_provisioner/README.rst +++ b/samples/bluetooth/mesh_provisioner/README.rst @@ -6,7 +6,7 @@ Bluetooth: Mesh Provisioner Overview ******** -This sample demonstrates how to use the Bluetooth mesh APIs related to +This sample demonstrates how to use the Bluetooth Mesh APIs related to provisioning and using the Configuration Database (CDB). It is intended to be tested together with a device capable of being provisioned. For example, one could use the sample in diff --git a/samples/boards/nrf/mesh/onoff-app/README.rst b/samples/boards/nrf/mesh/onoff-app/README.rst index e8cadccd53..35e37d6a59 100644 --- a/samples/boards/nrf/mesh/onoff-app/README.rst +++ b/samples/boards/nrf/mesh/onoff-app/README.rst @@ -6,7 +6,7 @@ Bluetooth: Mesh OnOff Model Overview ******** -This is a simple application demonstrating a Bluetooth mesh multi-element node. +This is a simple application demonstrating a Bluetooth Mesh multi-element node. Each element has a mesh onoff client and server model which controls one of the 4 sets of buttons and LEDs . diff --git a/samples/boards/nrf/mesh/onoff_level_lighting_vnd_app/README.rst b/samples/boards/nrf/mesh/onoff_level_lighting_vnd_app/README.rst index 05b8d896e7..f33bf1e776 100644 --- a/samples/boards/nrf/mesh/onoff_level_lighting_vnd_app/README.rst +++ b/samples/boards/nrf/mesh/onoff_level_lighting_vnd_app/README.rst @@ -4,7 +4,7 @@ Bluetooth: Mesh Generic OnOff, Generic Level, Lighting & Vendor Models ###################################################################### Overview ******** -This is a application demonstrating a Bluetooth mesh node in +This is a application demonstrating a Bluetooth Mesh node in which Root element has following models - Generic OnOff Server diff --git a/samples/boards/reel_board/mesh_badge/README.rst b/samples/boards/reel_board/mesh_badge/README.rst index d5973ab8e9..ccfc7e771a 100644 --- a/samples/boards/reel_board/mesh_badge/README.rst +++ b/samples/boards/reel_board/mesh_badge/README.rst @@ -6,7 +6,7 @@ Mesh Badge Overview ******** -This sample app for the reel board showcases Bluetooth mesh +This sample app for the reel board showcases Bluetooth Mesh The app starts off as a regular Bluetooth GATT peripheral application. Install the "nRF Connect" app on your phone (available both for @@ -34,7 +34,7 @@ Steps to set up you're not happy with it you can try writing something else. #. When you're happy with the text, disconnect from the board (exit the app or go back to the device scan page) -#. Once disconnected the board switches over to Bluetooth mesh mode, and you +#. Once disconnected the board switches over to Bluetooth Mesh mode, and you can't connect to it anymore over GATT. If you configure multiple boards like this they can communicate with diff --git a/subsys/bluetooth/Kconfig.logging b/subsys/bluetooth/Kconfig.logging index ec95ddad10..6d8b999e03 100644 --- a/subsys/bluetooth/Kconfig.logging +++ b/subsys/bluetooth/Kconfig.logging @@ -469,56 +469,56 @@ config BT_MESH_DEBUG_NET select DEPRECATED help Use this option to enable Network layer debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_RPL bool "[DEPRECATED] Replay protection list debug" select DEPRECATED help Use this option to enable Replay protection list debug logs - for the Bluetooth mesh functionality. + for the Bluetooth Mesh functionality. config BT_MESH_DEBUG_TRANS bool "[DEPRECATED] Transport layer debug" select DEPRECATED help Use this option to enable Transport layer debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_BEACON bool "[DEPRECATED] Beacon debug" select DEPRECATED help Use this option to enable Beacon-related debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_CRYPTO bool "[DEPRECATED] Crypto debug" select DEPRECATED help Use this option to enable cryptographic debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_KEYS bool "[DEPRECATED] Key management debug" select DEPRECATED help Use this option to enable key management debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_PROV bool "[DEPRECATED] Provisioning debug" select DEPRECATED help Use this option to enable Provisioning debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_PROVISIONER bool "[DEPRECATED] Provisioner debug" select DEPRECATED help Use this option to enable Provisioner debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_PROV_DEVICE bool "[DEPRECATED] Provisioning device debug" @@ -532,7 +532,7 @@ config BT_MESH_DEBUG_ACCESS select DEPRECATED help Use this option to enable Access layer and device composition - related debug logs for Bluetooth mesh. + related debug logs for Bluetooth Mesh. config BT_MESH_DEBUG_MODEL bool "[DEPRECATED] Foundation model debug" @@ -546,21 +546,21 @@ config BT_MESH_DEBUG_ADV select DEPRECATED help Use this option to enable advertising debug logs for - the Bluetooth mesh functionality. + the Bluetooth Mesh functionality. config BT_MESH_DEBUG_LOW_POWER bool "[DEPRECATED] Low Power debug" select DEPRECATED help Use this option to enable Low Power debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_FRIEND bool "[DEPRECATED] Friend debug" select DEPRECATED help Use this option to enable Friend debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. config BT_MESH_DEBUG_PROXY bool "[DEPRECATED] Proxy debug" @@ -588,7 +588,7 @@ config BT_MESH_DEBUG_CFG select DEPRECATED help Use this option to enable node configuration debug logs for the - Bluetooth mesh functionality. + Bluetooth Mesh functionality. endmenu # [DEPRECATED] Mesh diff --git a/subsys/bluetooth/common/Kconfig b/subsys/bluetooth/common/Kconfig index 7b6bc839b8..2fdc98694b 100644 --- a/subsys/bluetooth/common/Kconfig +++ b/subsys/bluetooth/common/Kconfig @@ -243,7 +243,7 @@ config BT_HCI_MESH_EXT bool "Mesh HCI Command support" depends on BT_BROADCASTER && BT_OBSERVER && !BT_LL_SW_SPLIT help - Enable support for the Bluetooth mesh HCI Commands. + Enable support for the Bluetooth Mesh HCI Commands. config BT_WAIT_NOP bool "Wait for \"NOP\" Command Complete event during init" diff --git a/subsys/bluetooth/mesh/Kconfig b/subsys/bluetooth/mesh/Kconfig index de409e9c53..ae7b25a6dd 100644 --- a/subsys/bluetooth/mesh/Kconfig +++ b/subsys/bluetooth/mesh/Kconfig @@ -1,13 +1,13 @@ -# Bluetooth mesh configuration options +# Bluetooth Mesh configuration options # Copyright (c) 2017 Intel Corporation # SPDX-License-Identifier: Apache-2.0 menuconfig BT_MESH - bool "Bluetooth mesh support" + bool "Bluetooth Mesh support" depends on BT_OBSERVER && BT_BROADCASTER help - This option enables Bluetooth mesh support. The specific + This option enables Bluetooth Mesh support. The specific features that are available may depend on other features that have been enabled in the stack, such as GATT support. @@ -598,7 +598,7 @@ config BT_MESH_ACCESS_LAYER_MSG help This option allows the application to directly access Bluetooth access layer messages without the need to - instantiate Bluetooth mesh models. + instantiate Bluetooth Mesh models. config BT_MESH_MODEL_VND_MSG_CID_FORCE bool "Force vendor model to use the corresponding CID field message" @@ -1049,9 +1049,9 @@ config BT_MESH_FRIEND_ADV_LATENCY endif # BT_MESH_FRIEND menuconfig BT_MESH_V1d1 - bool "Bluetooth mesh v1.1 support" + bool "Bluetooth Mesh v1.1 support" help - This option enables Bluetooth mesh v1.1 support. Bluetooth mesh v1.1 + This option enables Bluetooth Mesh v1.1 support. Bluetooth Mesh v1.1 is backward compatible with v1.0.1. config BT_MESH_ECDH_P256_CMAC_AES128_AES_CCM @@ -1201,7 +1201,7 @@ config BT_MESH_DFU_METADATA bool "Support for the default metadata format" help This option adds a set of functions that can be used to encode and decode a firmware - metadata using the format defined in the Bluetooth mesh DFU subsystem. + metadata using the format defined in the Bluetooth Mesh DFU subsystem. config BT_MESH_DFU_URI_MAXLEN int "DFU URI max length" @@ -1734,16 +1734,16 @@ config BT_MESH_RPL_STORE_TIMEOUT endif # BT_MESH_RPL_STORAGE_MODE_SETTINGS && BT_SETTINGS config BT_MESH_SETTINGS_WORKQ - bool "Store the Bluetooth mesh settings in a separate work queue" + bool "Store the Bluetooth Mesh settings in a separate work queue" default y help This option enables a separate cooperative thread which is used to - store Bluetooth mesh configuration. When this option is disabled, + store Bluetooth Mesh configuration. When this option is disabled, the stack's configuration is stored in the system workqueue. This means that the system workqueue will be blocked for the time needed to store the pending data. This time may significantly increase if the flash driver does the erase operation. Enabling this option - allows Bluetooth mesh not to block the system workqueue, and thus + allows Bluetooth Mesh not to block the system workqueue, and thus process the incoming and outgoing messages while the flash driver waits for the controller to allocate the time needed to write the data and/or erase the required flash pages. diff --git a/subsys/bluetooth/mesh/access.h b/subsys/bluetooth/mesh/access.h index b7ce1abd0e..48e0eadec1 100644 --- a/subsys/bluetooth/mesh/access.h +++ b/subsys/bluetooth/mesh/access.h @@ -94,7 +94,7 @@ void bt_mesh_msg_cb_set(void (*cb)(uint32_t opcode, struct bt_mesh_msg_ctx *ctx, * Send a mesh model layer message out into the mesh network without having instantiated * the relevant mesh models. * - * @param ctx The Bluetooth mesh message context. + * @param ctx The Bluetooth Mesh message context. * @param buf The message payload. * * @return 0 on success or negative error code on failure. diff --git a/subsys/bluetooth/mesh/settings.c b/subsys/bluetooth/mesh/settings.c index 771aad9b94..9cfcb3f5c2 100644 --- a/subsys/bluetooth/mesh/settings.c +++ b/subsys/bluetooth/mesh/settings.c @@ -88,7 +88,7 @@ static int mesh_commit(void) } if (!atomic_test_bit(bt_dev.flags, BT_DEV_ENABLE)) { - /* The Bluetooth mesh settings loader calls bt_mesh_start() immediately + /* The Bluetooth Mesh settings loader calls bt_mesh_start() immediately * after loading the settings. This is not intended to work before * bt_enable(). The doc on @ref bt_enable requires the "bt/" settings * tree to be loaded after @ref bt_enable is completed, so this handler diff --git a/subsys/bluetooth/mesh/shell/Kconfig b/subsys/bluetooth/mesh/shell/Kconfig index 5e1e43f005..46671c3bfa 100644 --- a/subsys/bluetooth/mesh/shell/Kconfig +++ b/subsys/bluetooth/mesh/shell/Kconfig @@ -1,13 +1,13 @@ -# Bluetooth mesh shell configuration options +# Bluetooth Mesh shell configuration options # Copyright (c) 2022 Nordic Semiconductor # SPDX-License-Identifier: Apache-2.0 menuconfig BT_MESH_SHELL - bool "Bluetooth mesh shell" + bool "Bluetooth Mesh shell" select SHELL help - Activate shell module that provides Bluetooth mesh commands to + Activate shell module that provides Bluetooth Mesh commands to the console. if BT_MESH_SHELL @@ -24,7 +24,7 @@ config BT_MESH_SHELL_PROV_CTX_INSTANCE depends on BT_MESH_SHELL_PROV help This option enables the provisioning context instance in the - Bluetooth mesh shell module together with several provisioning + Bluetooth Mesh shell module together with several provisioning commands and target utility features. To use the provisioning context instance, use bt_mesh_shell_prov in the initialization of mesh. @@ -54,7 +54,7 @@ config BT_MESH_SHELL_HEALTH_SRV_INSTANCE depends on BT_MESH_SHELL_TEST help This option enables Health Server model instance in the - Bluetooth mesh shell module together with fault controlling + Bluetooth Mesh shell module together with fault controlling shell commands. To use the model instance, add bt_mesh_shell_health_srv to the device composition data. Use BT_MESH_SHELL_HEALTH_PUB_DEFINE to instantiate publication context. diff --git a/subsys/bluetooth/mesh/shell/shell.c b/subsys/bluetooth/mesh/shell/shell.c index a169bb1642..bb9892eb35 100644 --- a/subsys/bluetooth/mesh/shell/shell.c +++ b/subsys/bluetooth/mesh/shell/shell.c @@ -1814,5 +1814,5 @@ SHELL_STATIC_SUBCMD_SET_CREATE(mesh_cmds, SHELL_SUBCMD_SET_END ); -SHELL_CMD_ARG_REGISTER(mesh, &mesh_cmds, "Bluetooth mesh shell commands", +SHELL_CMD_ARG_REGISTER(mesh, &mesh_cmds, "Bluetooth Mesh shell commands", bt_mesh_shell_mdl_cmds_help, 1, 1); diff --git a/tests/bsim/bluetooth/mesh/README.rst b/tests/bsim/bluetooth/mesh/README.rst index 787b0084f0..1ae78887b7 100644 --- a/tests/bsim/bluetooth/mesh/README.rst +++ b/tests/bsim/bluetooth/mesh/README.rst @@ -1,7 +1,7 @@ -Bluetooth mesh BabbleSim tests +Bluetooth Mesh BabbleSim tests ############################## -This directory contains a set of high level system tests for the Bluetooth mesh +This directory contains a set of high level system tests for the Bluetooth Mesh subsystem. The tests run on the BabbleSim simulator, using the BabbleSim test framework. @@ -10,7 +10,7 @@ subfolder of test_scripts contains tests for a specific module in the Bluetooth mesh subsystem, and each folder has a corresponding test_.c under the src/ directory containing the necessary test harnesses to execute the tests. -There's only a single test application for all the Bluetooth mesh BabbleSim +There's only a single test application for all the Bluetooth Mesh BabbleSim tests. The test application is built from this directory, and includes all test harnesses in every build. The overlying bsim test framework selects the harness to use at runtime, using the test identifiers passed in the test scripts. @@ -18,7 +18,7 @@ to use at runtime, using the test identifiers passed in the test scripts. Running the tests ***************** -The Bluetooth mesh tests have no extra requirements, and can be run using the +The Bluetooth Mesh tests have no extra requirements, and can be run using the procedure described in the parent folder. To only run the mesh tests, set ``SEARCH_PATH`` to point to this folder before @@ -57,13 +57,13 @@ Then separately, call Framework ********* -The Bluetooth mesh BabbleSim tests mainly operate on the test framework for the +The Bluetooth Mesh BabbleSim tests mainly operate on the test framework for the BabbleSim platform, but with some mesh specific additions: mesh_test.sh ============= -All test scripts in the Bluetooth mesh BabbleSim test suite follow a common +All test scripts in the Bluetooth Mesh BabbleSim test suite follow a common pattern for running a single test across N devices with different test harnesses. ``mesh_test.sh`` is sourced in each test script, and its ``RunTest`` function is called once in each script with the following parameters: @@ -113,6 +113,6 @@ has been called - otherwise, it will fail. The Bluetooth stack must be initialized in the ``test_main_f`` function of the harness, as the previous callbacks are all executed in hardware threads. -The Bluetooth mesh tests include the entire Bluetooth host and controller +The Bluetooth Mesh tests include the entire Bluetooth host and controller subsystems, so timing requirements should generally be kept fairly liberal to avoid regressions on changes in the underlying layers. diff --git a/tests/bsim/bluetooth/mesh/prj.conf b/tests/bsim/bluetooth/mesh/prj.conf index b0738c4fa0..a45bef8977 100644 --- a/tests/bsim/bluetooth/mesh/prj.conf +++ b/tests/bsim/bluetooth/mesh/prj.conf @@ -15,7 +15,7 @@ CONFIG_BT_BROADCASTER=y CONFIG_BT_CTLR_DUP_FILTER_LEN=0 CONFIG_BT_CTLR_PRIVACY=n -# Bluetooth mesh configuration +# Bluetooth Mesh configuration CONFIG_BT_MESH=y CONFIG_BT_MESH_LOG_LEVEL_DBG=y CONFIG_BT_MESH_RELAY=y diff --git a/tests/bsim/bluetooth/mesh/prj_mesh1d1.conf b/tests/bsim/bluetooth/mesh/prj_mesh1d1.conf index ab6066e01b..11059c03da 100644 --- a/tests/bsim/bluetooth/mesh/prj_mesh1d1.conf +++ b/tests/bsim/bluetooth/mesh/prj_mesh1d1.conf @@ -15,7 +15,7 @@ CONFIG_BT_BROADCASTER=y CONFIG_BT_CTLR_DUP_FILTER_LEN=0 CONFIG_BT_CTLR_PRIVACY=n -# Bluetooth mesh configuration +# Bluetooth Mesh configuration CONFIG_BT_MESH=y CONFIG_BT_MESH_V1d1=y CONFIG_BT_MESH_LOG_LEVEL_DBG=y diff --git a/tests/bsim/bluetooth/mesh/src/mesh_test.h b/tests/bsim/bluetooth/mesh/src/mesh_test.h index a5c8694947..3dcaa5f784 100644 --- a/tests/bsim/bluetooth/mesh/src/mesh_test.h +++ b/tests/bsim/bluetooth/mesh/src/mesh_test.h @@ -1,5 +1,5 @@ /** @file - * @brief Common functionality for Bluetooth mesh BabbleSim tests. + * @brief Common functionality for Bluetooth Mesh BabbleSim tests. */ /*