diff --git a/components/esp32/include/esp_mesh.h b/components/esp32/include/esp_mesh.h index 0adb59124..6322dc602 100644 --- a/components/esp32/include/esp_mesh.h +++ b/components/esp32/include/esp_mesh.h @@ -26,7 +26,7 @@ * | | ...) | (LwIP) | | | | * | |-----------------------------------| |---------------| | * | | | | - * | | WiFi Driver | | + * | | Wi-Fi Driver | | * | |--------------------------------------------------| | * | | | * | | Platform HAL | @@ -36,7 +36,7 @@ * * |---------------| * | | default handler - * | WiFi stack | events |---------------------| + * | Wi-Fi stack | events |---------------------| * | | -------------> | | * |---------------| | | * | event task | @@ -58,27 +58,27 @@ * Mesh Stack * * Mesh event defines almost all system events applications tasks need. - * Mesh event contains WiFi connection states on station interface, children connection states on softAP interface and etc.. + * Mesh event contains Wi-Fi connection states on station interface, children connection states on softAP interface and etc.. * Applications need to register a mesh event callback handler by API esp_mesh_set_config() firstly. * This handler is to receive events posted from mesh stack and LwIP stack. * Applications could add relative handler for each event. * Examples: - * (1)Applications could use WiFi station connect states to decide when to send data to its parent, to root or to external IP network; - * (2)Applications could use WiFi softAP states to decide when to send data to its children. + * (1) Applications could use Wi-Fi station connect states to decide when to send data to its parent, to the root or to external IP network; + * (2) Applications could use Wi-Fi softAP states to decide when to send data to its children. * * In present implementation, applications are able to access mesh stack directly without having to go through LwIP stack. * Applications use esp_mesh_send() and esp_mesh_recv() to send and receive messages over the mesh network. * In mesh stack design, normal devices don't require LwIP stack. But since IDF hasn't supported system without initializing LwIP stack yet, * applications still need to do LwIP initialization and two more things are required to be done - * (1)stop DHCP server on softAP interface by default - * (2)stop DHCP client on station interface by default. + * (1) stop DHCP server on softAP interface by default + * (2) stop DHCP client on station interface by default. * Examples: * tcpip_adapter_init(); * tcpip_adapter_dhcps_stop(TCPIP_ADAPTER_IF_AP)； * tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA)； * - * Over the mesh network, only root is able to access external IP network. - * In application mesh event handler, once a device becomes a root, start DHCP client immediately if DHCP is chosen. + * Over the mesh network, only the root is able to access external IP network. + * In application mesh event handler, once a device becomes a root, start DHCP client immediately whether DHCP is chosen. */ #ifndef __ESP_MESH_H__ @@ -100,9 +100,9 @@ extern "C" { #define MESH_MTU (1500) /**< max transmit unit(in bytes) */ #define MESH_MPS (1472) /**< max payload size(in bytes) */ /** - * @brief mesh error code definition + * @brief Mesh error code definition */ -#define ESP_ERR_MESH_WIFI_NOT_START (ESP_ERR_MESH_BASE + 1) /**< WiFi isn't started */ +#define ESP_ERR_MESH_WIFI_NOT_START (ESP_ERR_MESH_BASE + 1) /**< Wi-Fi isn't started */ #define ESP_ERR_MESH_NOT_INIT (ESP_ERR_MESH_BASE + 2) /**< mesh isn't initialized */ #define ESP_ERR_MESH_NOT_CONFIG (ESP_ERR_MESH_BASE + 3) /**< mesh isn't configured */ #define ESP_ERR_MESH_NOT_START (ESP_ERR_MESH_BASE + 4) /**< mesh isn't started */ @@ -120,41 +120,41 @@ extern "C" { #define ESP_ERR_MESH_OPTION_NULL (ESP_ERR_MESH_BASE + 16) /**< no option found */ #define ESP_ERR_MESH_OPTION_UNKNOWN (ESP_ERR_MESH_BASE + 17) /**< unknown option */ #define ESP_ERR_MESH_XON_NO_WINDOW (ESP_ERR_MESH_BASE + 18) /**< no window for software flow control on upstream */ -#define ESP_ERR_MESH_INTERFACE (ESP_ERR_MESH_BASE + 19) /**< low-level WiFi interface error */ +#define ESP_ERR_MESH_INTERFACE (ESP_ERR_MESH_BASE + 19) /**< low-level Wi-Fi interface error */ #define ESP_ERR_MESH_DISCARD_DUPLICATE (ESP_ERR_MESH_BASE + 20) /**< discard the packet due to the duplicate sequence number */ #define ESP_ERR_MESH_DISCARD (ESP_ERR_MESH_BASE + 21) /**< discard the packet */ #define ESP_ERR_MESH_VOTING (ESP_ERR_MESH_BASE + 22) /**< vote in progress */ /** - * @brief flags used with esp_mesh_send() and esp_mesh_recv() + * @brief Flags bitmap for esp_mesh_send() and esp_mesh_recv() */ -#define MESH_DATA_ENC (0x01) /**< data encrypted(Unimplemented) */ +#define MESH_DATA_ENC (0x01) /**< data encrypted (Unimplemented) */ #define MESH_DATA_P2P (0x02) /**< point-to-point delivery over the mesh network */ #define MESH_DATA_FROMDS (0x04) /**< receive from external IP network */ #define MESH_DATA_TODS (0x08) /**< identify this packet is target to external IP network */ #define MESH_DATA_NONBLOCK (0x10) /**< esp_mesh_send() non-block */ -#define MESH_DATA_DROP (0x20) /**< in the situation of root having been changed, identify this packet can be dropped by new root */ +#define MESH_DATA_DROP (0x20) /**< in the situation of the root having been changed, identify this packet can be dropped by new root */ #define MESH_DATA_GROUP (0x40) /**< identify this packet is target to a group address */ /** - * @brief option definitions for esp_mesh_send() and esp_mesh_recv() + * @brief Option definitions for esp_mesh_send() and esp_mesh_recv() */ #define MESH_OPT_SEND_GROUP (7) /**< data transmission by group; used with esp_mesh_send() and shall have payload */ #define MESH_OPT_RECV_DS_ADDR (8) /**< return a remote IP address; used with esp_mesh_send() and esp_mesh_recv() */ /** - * @brief flag of mesh networking IE + * @brief Flag of mesh networking IE */ #define MESH_ASSOC_FLAG_VOTE_IN_PROGRESS (0x02) /**< vote in progress */ #define MESH_ASSOC_FLAG_NETWORK_FREE (0x08) /**< no root in current network */ #define MESH_ASSOC_FLAG_ROOTS_FOUND (0x20) /**< root conflict is found */ -#define MESH_ASSOC_FLAG_ROOT_FIXED (0x40) /**< root is fixed */ +#define MESH_ASSOC_FLAG_ROOT_FIXED (0x40) /**< fixed root */ /******************************************************* * Enumerations *******************************************************/ /** - * @brief enumerated list of mesh event id + * @brief Enumerated list of mesh event id */ typedef enum { MESH_EVENT_STARTED, /**< mesh is started */ @@ -168,28 +168,28 @@ typedef enum { MESH_EVENT_PARENT_DISCONNECTED, /**< parent is disconnected on station interface */ MESH_EVENT_NO_PARENT_FOUND, /**< no parent found */ MESH_EVENT_LAYER_CHANGE, /**< layer changes over the mesh network */ - MESH_EVENT_TODS_STATE, /**< state represents if root is able to access external IP network */ - MESH_EVENT_VOTE_STARTED, /**< the process of voting a new root is started either by children or by root */ + MESH_EVENT_TODS_STATE, /**< state represents whether the root is able to access external IP network */ + MESH_EVENT_VOTE_STARTED, /**< the process of voting a new root is started either by children or by the root */ MESH_EVENT_VOTE_STOPPED, /**< the process of voting a new root is stopped */ MESH_EVENT_ROOT_ADDRESS, /**< the root address is obtained. It is posted by mesh stack automatically. */ MESH_EVENT_ROOT_SWITCH_REQ, /**< root switch request sent from a new voted root candidate */ MESH_EVENT_ROOT_SWITCH_ACK, /**< root switch acknowledgment responds the above request sent from current root */ - MESH_EVENT_ROOT_GOT_IP, /**< root obtains the IP address. It is posted by LwIP stack automatically */ - MESH_EVENT_ROOT_LOST_IP, /**< root loses the IP address. It is posted by LwIP stack automatically */ - MESH_EVENT_ROOT_ASKED_YIELD, /**< root is asked yield by a more powerful existing root. If self organized is disabled + MESH_EVENT_ROOT_GOT_IP, /**< the root obtains the IP address. It is posted by LwIP stack automatically */ + MESH_EVENT_ROOT_LOST_IP, /**< the root loses the IP address. It is posted by LwIP stack automatically */ + MESH_EVENT_ROOT_ASKED_YIELD, /**< the root is asked yield by a more powerful existing root. If self organized is disabled and this device is specified to be a root by users, users should set a new parent for this device. if self organized is enabled, this device will find a new parent by itself, users could ignore this event. */ MESH_EVENT_ROOT_FIXED, /**< when devices join a network, if the setting of Fixed Root for one device is different from that of its parent, the device will update the setting the same as its parent's. - Fixed Root setting of each device is variable as that setting changes of root. */ + Fixed Root Setting of each device is variable as that setting changes of the root. */ MESH_EVENT_SCAN_DONE, /**< if self-organized networking is disabled, user can call esp_wifi_scan_start() to trigger this event, and add the corresponding scan done handler in this event. */ MESH_EVENT_MAX, } mesh_event_id_t; /** - * @brief device type + * @brief Device type */ typedef enum { MESH_IDLE, /**< hasn't joined the mesh network yet */ @@ -199,7 +199,7 @@ typedef enum { } mesh_type_t; /** - * @brief protocol of transmitted application data + * @brief Protocol of transmitted application data */ typedef enum { MESH_PROTO_BIN, /**< binary */ @@ -209,24 +209,24 @@ typedef enum { } mesh_proto_t; /** - * @brief for reliable transmission, mesh stack provides three type of services + * @brief For reliable transmission, mesh stack provides three type of services */ typedef enum { - MESH_TOS_P2P, /**< provide P2P(point-to-point) retransmission on mesh stack by default */ - MESH_TOS_E2E, /**< provide E2E(end-to-end) retransmission on mesh stack (Unimplemented) */ + MESH_TOS_P2P, /**< provide P2P (point-to-point) retransmission on mesh stack by default */ + MESH_TOS_E2E, /**< provide E2E (end-to-end) retransmission on mesh stack (Unimplemented) */ MESH_TOS_DEF, /**< no retransmission on mesh stack */ } mesh_tos_t; /** - * @brief vote reason + * @brief Vote reason */ typedef enum { - MESH_VOTE_REASON_ROOT_INITIATED = 1, /**< vote is initiated by root */ + MESH_VOTE_REASON_ROOT_INITIATED = 1, /**< vote is initiated by the root */ MESH_VOTE_REASON_CHILD_INITIATED, /**< vote is initiated by children */ } mesh_vote_reason_t; /** - * @brief mesh disconnect reason code + * @brief Mesh disconnect reason code */ typedef enum { MESH_REASON_CYCLIC = 100, /**< cyclic is detected */ @@ -250,7 +250,7 @@ typedef struct { } __attribute__((packed)) mip_t; /** - * @brief mesh address + * @brief Mesh address */ typedef union { uint8_t addr[6]; /**< mac address */ @@ -258,47 +258,47 @@ typedef union { } mesh_addr_t; /** - * @brief channel switch information + * @brief Channel switch information */ typedef struct { uint8_t channel; /**< new channel */ } mesh_event_channel_switch_t; /** - * @brief parent connected information + * @brief Parent connected information */ typedef struct { - system_event_sta_connected_t connected; /**< parent information, same as WiFi event SYSTEM_EVENT_STA_CONNECTED does */ + system_event_sta_connected_t connected; /**< parent information, same as Wi-Fi event SYSTEM_EVENT_STA_CONNECTED does */ uint8_t self_layer; /**< layer */ } mesh_event_connected_t; /** - * @brief no parent found information + * @brief No parent found information */ typedef struct { int scan_times; /**< scan times being through */ } mesh_event_no_parent_found_t; /** - * @brief layer change information + * @brief Layer change information */ typedef struct { uint8_t new_layer; /**< new layer */ } mesh_event_layer_change_t; /** - * @brief the reachability of root to a DS(distribute system) + * @brief The reachability of the root to a DS (distribute system) */ typedef enum { - MESH_TODS_UNREACHABLE, /**< root isn't able to access external IP network */ - MESH_TODS_REACHABLE, /**< root is able to access external IP network */ + MESH_TODS_UNREACHABLE, /**< the root isn't able to access external IP network */ + MESH_TODS_REACHABLE, /**< the root is able to access external IP network */ } mesh_event_toDS_state_t; /** * @brief vote started information */ typedef struct { - int reason; /**< vote reason, vote could be initiated by children or by root itself */ + int reason; /**< vote reason, vote could be initiated by children or by the root itself */ int attempts; /**< max vote attempts before stopped */ mesh_addr_t rc_addr; /**< root address specified by users via API esp_mesh_waive_root() */ } mesh_event_vote_started_t; @@ -309,27 +309,27 @@ typedef struct { typedef system_event_sta_got_ip_t mesh_event_root_got_ip_t; /** - * @brief root address + * @brief Root address */ typedef mesh_addr_t mesh_event_root_address_t; /** - * @brief parent disconnected information + * @brief Parent disconnected information */ typedef system_event_sta_disconnected_t mesh_event_disconnected_t; /** - * @brief child connected information + * @brief Child connected information */ typedef system_event_ap_staconnected_t mesh_event_child_connected_t; /** - * @brief child disconnected information + * @brief Child disconnected information */ typedef system_event_ap_stadisconnected_t mesh_event_child_disconnected_t; /** - * @brief root switch request information + * @brief Root switch request information */ typedef struct { int reason; /**< root switch reason, generally root switch is initialized by users via API esp_mesh_waive_root() */ @@ -337,7 +337,7 @@ typedef struct { } mesh_event_root_switch_req_t; /** - * @brief other powerful root address + * @brief Other powerful root address */ typedef struct { int8_t rssi; /**< rssi with router */ @@ -346,7 +346,7 @@ typedef struct { } mesh_event_root_conflict_t; /** - * @brief routing table change + * @brief Routing table change */ typedef struct { uint16_t rt_size_new; /**< the new value */ @@ -354,21 +354,21 @@ typedef struct { } mesh_event_routing_table_change_t; /** - * @brief root fixed + * @brief Root fixed */ typedef struct { bool is_fixed; /**< status */ } mesh_event_root_fixed_t; /** - * @brief scan done　event information + * @brief Scan done　event information */ typedef struct { - uint8_t number; /**< the number of scanned APs */ + uint8_t number; /**< the number of APs scanned */ } mesh_event_scan_done_t; /** - * @brief mesh event information + * @brief Mesh event information */ typedef union { mesh_event_channel_switch_t channel_switch; /**< channel switch */ @@ -380,7 +380,7 @@ typedef union { mesh_event_no_parent_found_t no_parent; /**< no parent found */ mesh_event_layer_change_t layer_change; /**< layer change */ mesh_event_toDS_state_t toDS_state; /**< toDS state, devices shall check this state firstly before trying to send packets to - external IP network. This state indicates right now if root is capable of sending + external IP network. This state indicates right now whether the root is capable of sending packets out. If not, devices had better to wait until this state changes to be MESH_TODS_REACHABLE. */ mesh_event_vote_started_t vote_started; /**< vote started */ @@ -388,12 +388,12 @@ typedef union { mesh_event_root_address_t root_addr; /**< root address */ mesh_event_root_switch_req_t switch_req; /**< root switch request */ mesh_event_root_conflict_t root_conflict; /**< other powerful root */ - mesh_event_root_fixed_t root_fixed; /**< root fixed */ + mesh_event_root_fixed_t root_fixed; /**< fixed root */ mesh_event_scan_done_t scan_done; /**< scan done */ } mesh_event_info_t; /** - * @brief mesh event + * @brief Mesh event */ typedef struct { mesh_event_id_t id; /**< mesh event id */ @@ -401,14 +401,14 @@ typedef struct { } mesh_event_t; /** - * @brief mesh event callback handler prototype definition + * @brief Mesh event callback handler prototype definition * * @param event mesh_event_t */ typedef void (*mesh_event_cb_t)(mesh_event_t event); /** - * @brief mesh option + * @brief Mesh option */ typedef struct { uint8_t type; /**< option type */ @@ -417,7 +417,7 @@ typedef struct { } __attribute__((packed)) mesh_opt_t; /** - * @brief mesh data for esp_mesh_send() and esp_mesh_recv() + * @brief Mesh data for esp_mesh_send() and esp_mesh_recv() */ typedef struct { uint8_t *data; /**< data */ @@ -427,7 +427,7 @@ typedef struct { } mesh_data_t; /** - * @brief router configuration + * @brief Router configuration */ typedef struct { uint8_t ssid[32]; /**< SSID */ @@ -437,7 +437,7 @@ typedef struct { } mesh_router_t; /** - * @brief mesh softAP configuration + * @brief Mesh softAP configuration */ typedef struct { uint8_t password[64]; /**< mesh softAP password */ @@ -445,7 +445,7 @@ typedef struct { } mesh_ap_cfg_t; /** - * @brief mesh initialization configuration + * @brief Mesh initialization configuration */ typedef struct { uint8_t channel; /**< channel, the mesh network on */ @@ -457,7 +457,7 @@ typedef struct { } mesh_cfg_t; /** - * @brief vote address configuration + * @brief Vote address configuration */ typedef union { int attempts; /**< max vote attempts before a new root is elected automatically by mesh network. (min:15, 15 by default) */ @@ -465,29 +465,29 @@ typedef union { } mesh_rc_config_t; /** - * @brief vote + * @brief Vote */ typedef struct { float percentage; /**< vote percentage threshold for approval of being a root */ - bool is_rc_specified; /**< if true, rc_addr shall be specified(Unimplemented). + bool is_rc_specified; /**< if true, rc_addr shall be specified (Unimplemented). if false, attempts value shall be specified to make network start root election. */ mesh_rc_config_t config; /**< vote address configuration */ } mesh_vote_t; /** - * @brief the number of packets pending in the queue waiting to be sent by the mesh stack + * @brief The number of packets pending in the queue waiting to be sent by the mesh stack */ typedef struct { int to_parent; /**< to parent queue */ - int to_parent_p2p; /**< to parent(P2P) queue */ + int to_parent_p2p; /**< to parent (P2P) queue */ int to_child; /**< to child queue */ - int to_child_p2p; /**< to child(P2P) queue */ + int to_child_p2p; /**< to child (P2P) queue */ int mgmt; /**< management queue */ int broadcast; /**< broadcast and multicast queue */ } mesh_tx_pending_t; /** - * @brief the number of packets available in the queue waiting to be received by applications + * @brief The number of packets available in the queue waiting to be received by applications */ typedef struct { int toDS; /**< to external DS */ @@ -497,7 +497,7 @@ typedef struct { /******************************************************* * Variable Declaration *******************************************************/ -/* mesh vendor IE crypto callback function */ +/* mesh IE crypto callback function */ extern const mesh_crypto_funcs_t g_wifi_default_mesh_crypto_funcs; /* mesh event callback handler */ @@ -511,11 +511,11 @@ extern mesh_event_cb_t g_mesh_event_cb; * Function Definitions *******************************************************/ /** - * @brief mesh initialization - * Check if WiFi is started. - * Initialize mesh global variables with default values. + * @brief Mesh initialization + * - Check whether Wi-Fi is started. + * - Initialize mesh global variables with default values. * - * @attention This API shall be called after WiFi is started. + * @attention This API shall be called after Wi-Fi is started. * * @return * - ESP_OK @@ -524,8 +524,9 @@ extern mesh_event_cb_t g_mesh_event_cb; esp_err_t esp_mesh_init(void); /** - * @brief mesh de-initialization - * Release resources and stop the mesh + * @brief Mesh de-initialization + * + * - Release resources and stop the mesh * * @return * - ESP_OK @@ -534,13 +535,13 @@ esp_err_t esp_mesh_init(void); esp_err_t esp_mesh_deinit(void); /** - * @brief start mesh - * Initialize mesh vendor IE - * Start mesh network management service - * Create TX and RX queues according to the configuration - * Register mesh packets receive callback + * @brief Start mesh + * - Initialize mesh IE. + * - Start mesh network management service. + * - Create TX and RX queues according to the configuration. + * - Register mesh packets receive callback. * - * @attention This API shall be called after esp_mesh_init() and esp_mesh_set_config(). + * @attention This API shall be called after esp_mesh_init() and esp_mesh_set_config(). * * @return * - ESP_OK @@ -552,15 +553,15 @@ esp_err_t esp_mesh_deinit(void); esp_err_t esp_mesh_start(void); /** - * @brief stop mesh - * Deinitialize mesh vendor IE - * Disconnect with current parent - * Disassociate all currently associated children - * Stop mesh network management service - * Unregister mesh packets receive callback - * Delete TX and RX queues - * Release resources - * Restore WiFi softAP to default settings if WiFi dual mode is enabled + * @brief Stop mesh + * - Deinitialize mesh IE. + * - Disconnect with current parent. + * - Disassociate all currently associated children. + * - Stop mesh network management service. + * - Unregister mesh packets receive callback. + * - Delete TX and RX queues. + * - Release resources. + * - Restore Wi-Fi softAP to default settings if Wi-Fi dual mode is enabled. * * @return * - ESP_OK @@ -569,40 +570,42 @@ esp_err_t esp_mesh_start(void); esp_err_t esp_mesh_stop(void); /** - * @brief send a packet over the mesh network - * Send a packet to any device in the mesh network. - * Send a packet to external IP network. + * @brief Send a packet over the mesh network + * - Send a packet to any device in the mesh network. + * - Send a packet to external IP network. * - * @attention This API is not reentrant. + * @attention This API is not reentrant. * - * @param to the address of the final destination of the packet - * (1)if the packet is to root, just set "to" to NULL and set flag to zero. - * (2)if the packet is outgoing to external IP network such as an IP server address, translate IPv4:PORT known as "to". - * This packet will be delivered to root firstly, then root will forward this packet to the final IP server address. - * @param data pointer to a sending mesh packet - * Should specify the data protocol applications used, binary by default. - * Should specify the transmission tos(type of service), P2P reliable by default. - * @param flag - * (1)used to speed up the route selection - * if the packet is target to an internal device, MESH_DATA_P2P should be set. - * if the packet is outgoing to root or to external IP network, MESH_DATA_TODS should be set. - * if the packet is from root to an internal device, MESH_DATA_FROMDS should be set. - * (2)specify if this API is block or non-block, block by default - * if needs non-block, MESH_DATA_NONBLOCK should be set. - * (3)in the situation of root having been changed, MESH_DATA_DROP identifies this packet can be dropped by new root - * for upstream data to external IP network, we try our best to avoid data loss caused by root having been changed, but - * there is a risk that new root is running out of memory because most of memory is occupied by the pending data which - * isn't read out in time by esp_mesh_recv_toDS(). - * Generally, we suggest esp_mesh_recv_toDS() is called after a connection with IP network is created. Thus data outgoing - * to external IP network via socket is just from reading esp_mesh_recv_toDS() which avoids unnecessary memory copy. + * @param[in] to the address of the final destination of the packet + * - If the packet is to the root, set this parameter to NULL. + * - If the packet is to an external IP network, set this parameter to the IPv4:PORT combination. + * This packet will be delivered to the root firstly, then the root will forward this packet to the final IP server address. + * @param[in] data pointer to a sending mesh packet + * - Field proto should be set to data protocol in use (default is MESH_PROTO_BIN for binary). + * - Field tos should be set to transmission tos (type of service) in use (default is MESH_TOS_P2P for point-to-point reliable). + * @param[in] flag bitmap for data sent + * - Speed up the route search + * - If the packet is to the root and "to" parameter is NULL, set this parameter to 0. + * - If the packet is to an internal device, MESH_DATA_P2P should be set. + * - If the packet is to the root ("to" parameter isn't NULL) or to external IP network, MESH_DATA_TODS should be set. + * - If the packet is from the root to an internal device, MESH_DATA_FROMDS should be set. + * - Specify whether this API is block or non-block, block by default + * - If needs non-block, MESH_DATA_NONBLOCK should be set. + * - In the situation of the root change, MESH_DATA_DROP identifies this packet can be dropped by the new root + * for upstream data to external IP network, we try our best to avoid data loss caused by the root change, but + * there is a risk that the new root is running out of memory because most of memory is occupied by the pending data which + * isn't read out in time by esp_mesh_recv_toDS(). * - * @param opt options - * (1)in case of sending a packet to a specified group, MESH_OPT_SEND_GROUP is a good choice. - * In this option, the value field should specify the target receiver addresses in this group. - * (2)root sends a packet to an internal device, this packet is from external IP network in case the receiver device responds - * this packet, MESH_OPT_RECV_DS_ADDR is required to attach the target DS address. - * @param opt_count option count - * Currently, this API only takes one option, so opt_count is only supported to be 1. + * Generally, we suggest esp_mesh_recv_toDS() is called after a connection with IP network is created. Thus data outgoing + * to external IP network via socket is just from reading esp_mesh_recv_toDS() which avoids unnecessary memory copy. + * + * @param[in] opt options + * - In case of sending a packet to a certain group, MESH_OPT_SEND_GROUP is a good choice. + * In this option, the value field should be set to the target receiver addresses in this group. + * - Root sends a packet to an internal device, this packet is from external IP network in case the receiver device responds + * this packet, MESH_OPT_RECV_DS_ADDR is required to attach the target DS address. + * @param[in] opt_count option count + * - Currently, this API only takes one option, so opt_count is only supported to be 1. * * @return * - ESP_OK @@ -622,21 +625,26 @@ esp_err_t esp_mesh_send(const mesh_addr_t *to, const mesh_data_t *data, int flag, const mesh_opt_t opt[], int opt_count); /** - * @brief receive a packet targeted to self over the mesh network - * Use esp_mesh_get_rx_pending() to check the number of packets available in the queue waiting - * to be received by applications in case of running out of memory. + * @brief Receive a packet targeted to self over the mesh network * - * @param from the address of the original source of the packet - * @param data pointer to the received mesh packet - * Contain the protocol and applications should follow it to parse the data. - * @param timeout_ms wait time if a packet isn't immediately available(0:no wait, portMAX_DELAY:wait forever) - * @param flag - * MESH_DATA_FROMDS represents data from external IP network - * MESH_DATA_TODS represents data directed upward within the mesh network - * @param opt options desired to receive - * MESH_OPT_RECV_DS_ADDR attaches the DS address - * @param opt_count option count desired to receive - * Currently, this API only takes one option, so opt_count is only supported to be 1. + * @attention Mesh RX queue should be checked regularly to avoid running out of memory. + * - Use esp_mesh_get_rx_pending() to check the number of packets available in the queue waiting + * to be received by applications. + * + * @param[out] from the address of the original source of the packet + * @param[out] data pointer to the received mesh packet + * - Field proto is the data protocol in use. Should follow it to parse the received data. + * - Field tos is the transmission tos (type of service) in use. + * @param[in] timeout_ms wait time if a packet isn't immediately available (0:no wait, portMAX_DELAY:wait forever) + * @param[out] flag bitmap for data received + * - MESH_DATA_FROMDS represents data from external IP network + * - MESH_DATA_TODS represents data directed upward within the mesh network + * + * flag could be MESH_DATA_FROMDS or MESH_DATA_TODS. + * @param[out] opt options desired to receive + * - MESH_OPT_RECV_DS_ADDR attaches the DS address + * @param[in] opt_count option count desired to receive + * - Currently, this API only takes one option, so opt_count is only supported to be 1. * * @return * - ESP_OK @@ -649,29 +657,33 @@ esp_err_t esp_mesh_recv(mesh_addr_t *from, mesh_data_t *data, int timeout_ms, int *flag, mesh_opt_t opt[], int opt_count); /** - * @brief receive a packet targeted to external IP network - * root uses this API to receive packets destined to external IP network - * root forwards the received packets to the final destination via socket. - * if no socket connection is ready to send out the received packets and this esp_mesh_recv_toDS() - * hasn't been called by applications, packets from the whole mesh network will be pending in toDS queue. - * Use esp_mesh_get_rx_pending() to check the number of packets available in the queue waiting - * to be received by applications in case of running out of memory in root. - * Use esp_mesh_set_xon_qsize() could configure the RX queue size, default:72. If this size is too large, - * and esp_mesh_recv_toDS() isn't called in time, there is a risk that a great deal of memory is occupied - * by the pending packets. If this size is too small, it will impact the efficiency on upstream. How to - * decide this value depends on the specific application scenarios. + * @brief Receive a packet targeted to external IP network + * - Root uses this API to receive packets destined to external IP network + * - Root forwards the received packets to the final destination via socket. + * - If no socket connection is ready to send out the received packets and this esp_mesh_recv_toDS() + * hasn't been called by applications, packets from the whole mesh network will be pending in toDS queue. * - * @attention This API is only called by root. + * Use esp_mesh_get_rx_pending() to check the number of packets available in the queue waiting + * to be received by applications in case of running out of memory in the root. * - * @param from the address of the original source of the packet - * @param to the address contains remote IP address and port(IPv4:PORT) - * @param data pointer to the received packet - * Contain the protocol and applications should follow it to parse the data. - * @param timeout_ms wait time if a packet isn't immediately available(0:no wait, portMAX_DELAY:wait forever) - * @param flag - * MESH_DATA_TODS represents data to external IP network - * @param opt options desired to receive - * @param opt_count option count desired to receive + * Using esp_mesh_set_xon_qsize() users may configure the RX queue size, default:32. If this size is too large, + * and esp_mesh_recv_toDS() isn't called in time, there is a risk that a great deal of memory is occupied + * by the pending packets. If this size is too small, it will impact the efficiency on upstream. How to + * decide this value depends on the specific application scenarios. + * + * @attention This API is only called by the root. + * + * @param[out] from the address of the original source of the packet + * @param[out] to the address contains remote IP address and port (IPv4:PORT) + * @param[out] data pointer to the received packet + * - Contain the protocol and applications should follow it to parse the data. + * @param[in] timeout_ms wait time if a packet isn't immediately available (0:no wait, portMAX_DELAY:wait forever) + * @param[out] flag bitmap for data received + * - MESH_DATA_TODS represents the received data target to external IP network. Root shall forward this data to external IP network via the association with router. + * + * flag could be MESH_DATA_TODS. + * @param[out] opt options desired to receive + * @param[in] opt_count option count desired to receive * * @return * - ESP_OK @@ -685,24 +697,26 @@ esp_err_t esp_mesh_recv_toDS(mesh_addr_t *from, mesh_addr_t *to, int opt_count); /** - * @brief set mesh stack configuration - * Use MESH_INIT_CONFIG_DEFAULT() to initialize the default values, mesh vendor IE is encrypted by default. - * mesh network is established on a fixed channel(1-14). - * mesh event callback is mandatory. - * mesh ID is an identifier of an MBSS. Nodes with the same mesh ID can communicate with each other. - * Regarding to the router configuration, if the router is hidden, BSSID field is mandatory. - * If BSSID field isn't set and there exists more than one router with same SSID, there is a risk that more - * roots than one connected with different BSSID will appear. It means more than one mesh network is established - * with the same mesh ID. - * Root conflict function could eliminate redundant roots connected with the same BSSID, but couldn't handle roots - * connected with different BSSID. Because users might have such requirements of setting up routers with same SSID - * for the future replacement. But in that case, if the above situations happen, please make sure applications - * implement forward functions on root to guarantee devices in different mesh network can communicate with each other. - * max_connection of mesh softAP is limited by the max number of WiFi softAP supported(max:10). + * @brief Set mesh stack configuration + * - Use MESH_INIT_CONFIG_DEFAULT() to initialize the default values, mesh IE is encrypted by default. + * - Mesh network is established on a fixed channel (1-14). + * - Mesh event callback is mandatory. + * - Mesh ID is an identifier of an MBSS. Nodes with the same mesh ID can communicate with each other. + * - Regarding to the router configuration, if the router is hidden, BSSID field is mandatory. * - * @attention This API shall be called between esp_mesh_init() and esp_mesh_start(). + * If BSSID field isn't set and there exists more than one router with same SSID, there is a risk that more + * roots than one connected with different BSSID will appear. It means more than one mesh network is established + * with the same mesh ID. * - * @param config pointer to mesh stack configuration + * Root conflict function could eliminate redundant roots connected with the same BSSID, but couldn't handle roots + * connected with different BSSID. Because users might have such requirements of setting up routers with same SSID + * for the future replacement. But in that case, if the above situations happen, please make sure applications + * implement forward functions on the root to guarantee devices in different mesh network can communicate with each other. + * max_connection of mesh softAP is limited by the max number of Wi-Fi softAP supported (max:10). + * + * @attention This API shall be called between esp_mesh_init() and esp_mesh_start(). + * + * @param[in] config pointer to mesh stack configuration * * @return * - ESP_OK @@ -712,9 +726,9 @@ esp_err_t esp_mesh_recv_toDS(mesh_addr_t *from, mesh_addr_t *to, esp_err_t esp_mesh_set_config(const mesh_cfg_t *config); /** - * @brief get mesh stack configuration + * @brief Get mesh stack configuration * - * @param config pointer to mesh stack configuration + * @param[out] config pointer to mesh stack configuration * * @return * - ESP_OK @@ -723,11 +737,11 @@ esp_err_t esp_mesh_set_config(const mesh_cfg_t *config); esp_err_t esp_mesh_get_config(mesh_cfg_t *config); /** - * @brief set router configuration + * @brief Get router configuration * - * @attention This API shall be called between esp_mesh_init() and esp_mesh_start(). + * @attention This API shall be called between esp_mesh_init() and esp_mesh_start(). * - * @param router pointer to router configuration + * @param[in] router pointer to router configuration * * @return * - ESP_OK @@ -736,9 +750,9 @@ esp_err_t esp_mesh_get_config(mesh_cfg_t *config); esp_err_t esp_mesh_set_router(const mesh_router_t *router); /** - * @brief get router configuration + * @brief Get router configuration * - * @param router pointer to router configuration + * @param[out] router pointer to router configuration * * @return * - ESP_OK @@ -747,11 +761,11 @@ esp_err_t esp_mesh_set_router(const mesh_router_t *router); esp_err_t esp_mesh_get_router(mesh_router_t *router); /** - * @brief set mesh network ID + * @brief Set mesh network ID * - * @attention This API could be called either before esp_mesh_start() or after esp_mesh_start(). + * @attention This API could be called either before esp_mesh_start() or after esp_mesh_start(). * - * @param id pointer to mesh network ID + * @param[in] id pointer to mesh network ID * * @return * - ESP_OK @@ -760,9 +774,9 @@ esp_err_t esp_mesh_get_router(mesh_router_t *router); esp_err_t esp_mesh_set_id(const mesh_addr_t *id); /** - * @brief get mesh network ID + * @brief Get mesh network ID * - * @param id pointer to mesh network ID + * @param[out] id pointer to mesh network ID * * @return * - ESP_OK @@ -771,13 +785,9 @@ esp_err_t esp_mesh_set_id(const mesh_addr_t *id); esp_err_t esp_mesh_get_id(mesh_addr_t *id); /** - * @brief specify device type over the mesh network - * - MESH_ROOT: designates the root node for a mesh network - * - MESH_LEAF: designates a device as a standalone Wi-Fi station + * @brief Designate device type over the mesh network * - * @attention This API shall be called before esp_mesh_start(). - * - * @param type device type (only support MESH_ROOT, MESH_LEAF) + * @param[in] type device type * * @return * - ESP_OK @@ -786,19 +796,22 @@ esp_err_t esp_mesh_get_id(mesh_addr_t *id); esp_err_t esp_mesh_set_type(mesh_type_t type); /** - * @brief get device type over the mesh network + * @brief Get device type over mesh network * - * @return mesh type + * @attention This API shall be called after having received the event MESH_EVENT_PARENT_CONNECTED. + * + * @return mesh type * */ mesh_type_t esp_mesh_get_type(void); /** - * @brief set max layer configuration(max:25, default:25) + * @brief Set network max layer value (max:25, default:15) + * - Network max layer limits the max hop count. * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param max_layer max layer value + * @param[in] max_layer max layer value * * @return * - ESP_OK @@ -808,19 +821,19 @@ mesh_type_t esp_mesh_get_type(void); esp_err_t esp_mesh_set_max_layer(int max_layer); /** - * @brief get max layer configuration + * @brief Get max layer value * - * @return max layer value + * @return max layer value */ int esp_mesh_get_max_layer(void); /** - * @brief set mesh softAP password + * @brief Set mesh softAP password * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param pwd pointer to the password - * @param len password length + * @param[in] pwd pointer to the password + * @param[in] len password length * * @return * - ESP_OK @@ -830,11 +843,11 @@ int esp_mesh_get_max_layer(void); esp_err_t esp_mesh_set_ap_password(const uint8_t *pwd, int len); /** - * @brief set mesh softAP authentication mode value + * @brief Set mesh softAP authentication mode * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param authmode authentication mode + * @param[in] authmode authentication mode * * @return * - ESP_OK @@ -844,19 +857,18 @@ esp_err_t esp_mesh_set_ap_password(const uint8_t *pwd, int len); esp_err_t esp_mesh_set_ap_authmode(wifi_auth_mode_t authmode); /** - * @brief get mesh softAP authentication mode - * - * @return authentication mode + * @brief Get mesh softAP authentication mode * + * @return authentication mode */ wifi_auth_mode_t esp_mesh_get_ap_authmode(void); /** - * @brief set mesh softAP max connection value + * @brief Set mesh softAP max connection value * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param connections the number of max connections + * @param[in] connections the number of max connections * * @return * - ESP_OK @@ -865,29 +877,28 @@ wifi_auth_mode_t esp_mesh_get_ap_authmode(void); esp_err_t esp_mesh_set_ap_connections(int connections); /** - * @brief get mesh softAP max connection configuration - * - * @return the number of max connections + * @brief Get mesh softAP max connection configuration * + * @return the number of max connections */ int esp_mesh_get_ap_connections(void); /** - * @brief get current layer value over the mesh network + * @brief Get current layer value over the mesh network * - * @attention This API shall be called after having received the event MESH_EVENT_PARENT_CONNECTED. + * @attention This API shall be called after having received the event MESH_EVENT_PARENT_CONNECTED. * - * @return layer value + * @return layer value * */ int esp_mesh_get_layer(void); /** - * @brief get parent BSSID + * @brief Get the parent BSSID * - * @attention This API shall be called after having received the event MESH_EVENT_PARENT_CONNECTED. + * @attention This API shall be called after having received the event MESH_EVENT_PARENT_CONNECTED. * - * @param bssid pointer to parent BSSID + * @param[out] bssid pointer to parent BSSID * * @return * - ESP_OK @@ -896,22 +907,22 @@ int esp_mesh_get_layer(void); esp_err_t esp_mesh_get_parent_bssid(mesh_addr_t *bssid); /** - * @brief return if the device is root - * - * @return true/false + * @brief Return whether the device is the root node of the network * + * @return true/false */ bool esp_mesh_is_root(void); /** - * @brief enable/disable mesh networking self-organized, self-organized by default - * if self-organized is disabled, users should set a parent for this device via - * esp_mesh_set_parent(); + * @brief Enable/disable mesh networking self-organized, self-organized by default + * - If self-organized is disabled, users shall set a parent for the device via + * esp_mesh_set_parent(); * - * @attention This API could be called either before esp_mesh_start() or after esp_mesh_start(). + * @attention This API could be called either before esp_mesh_start() or after esp_mesh_start(). * - * @param enable enable or disable self-organized networking - * @param select_parent if enable self-organized networking, let the device select a new parent or + * @param[in] enable enable or disable self-organized networking + * @param[in] select_parent + * - If self-organized networking is enabled, let the device search for a new parent or * keep connecting to the previous parent. * * @return @@ -921,35 +932,36 @@ bool esp_mesh_is_root(void); esp_err_t esp_mesh_set_self_organized(bool enable, bool select_parent); /** - * @brief return if mesh networking is self-organized or not - * - * @return true/false + * @brief Return whether enable self-organized networking or not * + * @return true/false */ bool esp_mesh_get_self_organized(void); /** - * @brief root waive itself - * A device is elected to be a root during the networking mostly because it has a strong RSSI with router. - * If such superior conditions change, users could call this API to perform a root switch. + * @brief Cause the root device to give up (waive) its mesh root status + * - A device is elected root primarily based on RSSI from the external router. + * - If external router conditions change, users can call this API to perform a root switch. + * - In this API, users could specify a desired root address to replace itself or specify an attempts value + * to ask current root to initiate a new round of voting. During the voting, a better root candidate would + * be expected to find to replace the current one. + * - If no desired root candidate, the vote will try a specified number of attempts (at least 15). If no better + * root candidate is found, keep the current one. If a better candidate is found, the new better one will + * send a root switch request to the current root, current root will respond with a root switch acknowledgment. + * - After that, the new candidate will connect to the router to be a new root, the previous root will disconnect + * with the router and choose another parent instead. * - * In this API, users could specify a desired root address to replace itself or specify an attempts value - * to ask current root to initiate a new round of voting. During the voting, a better root candidate would - * be expected to find to replace the current one. - * If no desired root candidate, the vote will try a specified attempts(at least 10 times), if no better - * root candidate is found, keep the current one. If a better candidate is found, the new better one will - * send a root switch request to the current root, current root will respond with a root switch acknowledgment. - * After that, the new candidate will connect to the router to be a new root, the previous root will disconnect - * with the router and choose another parent instead. - * So far, root switch is completed with minimal disruption to the whole mesh network. + * Root switch is completed with minimal disruption to the whole mesh network. * - * @attention This API is only called by root. + * @attention This API is only called by the root. * - * @param vote vote configuration - * Specify a desired root address(Unimplemented) - * Attempts should be at least 10 times. - * if "vote" is set NULL, the vote will perform the default 10 times. - * @param reason only accept MESH_VOTE_REASON_ROOT_INITIATED for now + * @param[in] vote vote configuration + * - If this parameter is set NULL, the vote will perform the default 15 times. + * + * - Field percentage threshold is 0.9 by default. + * - Field is_rc_specified shall be false. + * - Field attempts shall be at least 15 times. + * @param[in] reason only accept MESH_VOTE_REASON_ROOT_INITIATED for now * * @return * - ESP_OK @@ -960,13 +972,13 @@ bool esp_mesh_get_self_organized(void); esp_err_t esp_mesh_waive_root(const mesh_vote_t *vote, int reason); /** - * @brief set vote percentage threshold for approval of being a root - * During the networking, only obtaining vote percentage reaches this threshold, - * the device could be a root. + * @brief Set vote percentage threshold for approval of being a root + * - During the networking, only obtaining vote percentage reaches this threshold, + * the device could be a root. * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param percentage vote percentage threshold + * @param[in] percentage vote percentage threshold * * @return * - ESP_OK @@ -975,18 +987,18 @@ esp_err_t esp_mesh_waive_root(const mesh_vote_t *vote, int reason); esp_err_t esp_mesh_set_vote_percentage(float percentage); /** - * @brief get vote percentage threshold for approval of being a root + * @brief Get vote percentage threshold for approval of being a root * - * @return percentage threshold + * @return percentage threshold */ float esp_mesh_get_vote_percentage(void); /** - * @brief set mesh softAP associate expired time - * If mesh softAP hasn't received any data from an associated child within this time, - * mesh softAP will take this child inactive and disassociate it. + * @brief Set mesh softAP associate expired time + * - If mesh softAP hasn't received any data from an associated child within this time, + * mesh softAP will take this child inactive and disassociate it. * - * @param seconds + * @param[in] seconds the expired time * * @return * - ESP_OK @@ -995,34 +1007,34 @@ float esp_mesh_get_vote_percentage(void); esp_err_t esp_mesh_set_ap_assoc_expire(int seconds); /** - * @brief get mesh softAP associate expired time + * @brief Get mesh softAP associate expired time * - * @return seconds + * @return seconds */ int esp_mesh_get_ap_assoc_expire(void); /** - * @brief get total number of devices in current network(including root) + * @brief Get total number of devices in current network (including the root) * - * @attention The returned value might be incorrect when the network is changing. + * @attention The returned value might be incorrect when the network is changing. ** - * @return total number of devices(including root) + * @return total number of devices (including the root) */ int esp_mesh_get_total_node_num(void); /** - * @brief get the number of devices in this device's sub-network(including self) + * @brief Get the number of devices in this device's sub-network (including self) * - * @return the number of devices over this device's sub-network(including self) + * @return the number of devices over this device's sub-network (including self) */ int esp_mesh_get_routing_table_size(void); /** - * @brief get routing table of this device's sub-network(including itself) + * @brief Get routing table of this device's sub-network (including itself) * - * @param mac pointer to routing table - * @param len routing table size(in bytes) - * @param size pointer to the number of devices in routing table(including itself) + * @param[out] mac pointer to routing table + * @param[in] len routing table size(in bytes) + * @param[out] size pointer to the number of devices in routing table (including itself) * * @return * - ESP_OK @@ -1031,11 +1043,11 @@ int esp_mesh_get_routing_table_size(void); esp_err_t esp_mesh_get_routing_table(mesh_addr_t *mac, int len, int *size); /** - * @brief post the toDS state to the mesh stack + * @brief Post the toDS state to the mesh stack * - * @attention This API is only for root. + * @attention This API is only for the root. * - * @param reachable this state represents if root is able to access external IP network + * @param[in] reachable this state represents whether the root is able to access external IP network * * @return * - ESP_OK @@ -1044,9 +1056,9 @@ esp_err_t esp_mesh_get_routing_table(mesh_addr_t *mac, int len, int *size); esp_err_t esp_mesh_post_toDS_state(bool reachable); /** - * @brief return the number of packets pending in the queue waiting to be sent by the mesh stack + * @brief Return the number of packets pending in the queue waiting to be sent by the mesh stack * - * @param pending pointer to the TX pending + * @param[out] pending pointer to the TX pending * * @return * - ESP_OK @@ -1055,9 +1067,9 @@ esp_err_t esp_mesh_post_toDS_state(bool reachable); esp_err_t esp_mesh_get_tx_pending(mesh_tx_pending_t *pending); /** - * @brief return the number of packets available in the queue waiting to be received by applications + * @brief Return the number of packets available in the queue waiting to be received by applications * - * @param pending pointer to the RX pending + * @param[out] pending pointer to the RX pending * * @return * - ESP_OK @@ -1066,21 +1078,21 @@ esp_err_t esp_mesh_get_tx_pending(mesh_tx_pending_t *pending); esp_err_t esp_mesh_get_rx_pending(mesh_rx_pending_t *pending); /** - * @brief return the number of packets could be accepted from the specified address + * @brief Return the number of packets could be accepted from the specified address * - * @param addr self address or an associate children address - * @param xseqno_in sequence number of the last received packet from the specified address + * @param[in] addr self address or an associate children address + * @param[out] xseqno_in sequence number of the last received packet from the specified address * - * @return the number of upQ for a specified address + * @return the number of upQ for a certain address */ int esp_mesh_available_txupQ_num(const mesh_addr_t *addr, uint32_t *xseqno_in); /** - * @brief set queue size + * @brief Set the number of queue * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param qsize default:32(min:16) + * @param[in] qsize default:32 (min:16) * * @return * - ESP_OK @@ -1089,16 +1101,16 @@ int esp_mesh_available_txupQ_num(const mesh_addr_t *addr, uint32_t *xseqno_in); esp_err_t esp_mesh_set_xon_qsize(int qsize); /** - * @brief get queue size + * @brief Get queue size * - * @return qsize + * @return the number of queue */ int esp_mesh_get_xon_qsize(void); /** - * @brief set if allow more than one root existing in one network + * @brief Set whether allow more than one root existing in one network * - * @param allowed allow or not + * @param[in] allowed allow or not * * @return * - ESP_OK @@ -1108,17 +1120,17 @@ int esp_mesh_get_xon_qsize(void); esp_err_t esp_mesh_allow_root_conflicts(bool allowed); /** - * @brief check if allow more than one root to exist in one network + * @brief Check whether allow more than one root to exist in one network * - * @return true/false + * @return true/false */ bool esp_mesh_is_root_conflicts_allowed(void); /** - * @brief set group ID addresses + * @brief Set group ID addresses * - * @param addr pointer to new group ID addresses - * @param num the number of group ID addresses + * @param[in] addr pointer to new group ID addresses + * @param[in] num the number of group ID addresses * * @return * - ESP_OK @@ -1127,10 +1139,10 @@ bool esp_mesh_is_root_conflicts_allowed(void); esp_err_t esp_mesh_set_group_id(const mesh_addr_t *addr, int num); /** - * @brief delete group ID addresses + * @brief Delete group ID addresses * - * @param addr pointer to deleted group ID address - * @param num the number of group ID addresses + * @param[in] addr pointer to deleted group ID address + * @param[in] num the number of group ID addresses * * @return * - ESP_OK @@ -1139,17 +1151,17 @@ esp_err_t esp_mesh_set_group_id(const mesh_addr_t *addr, int num); esp_err_t esp_mesh_delete_group_id(const mesh_addr_t *addr, int num); /** - * @brief get the number of group ID addresses + * @brief Get the number of group ID addresses * - * @return the number of group ID addresses + * @return the number of group ID addresses */ int esp_mesh_get_group_num(void); /** - * @brief get group ID addresses + * @brief Get group ID addresses * - * @param addr pointer to group ID addresses - * @param num the number of group ID addresses + * @param[out] addr pointer to group ID addresses + * @param[in] num the number of group ID addresses * * @return * - ESP_OK @@ -1158,18 +1170,18 @@ int esp_mesh_get_group_num(void); esp_err_t esp_mesh_get_group_list(mesh_addr_t *addr, int num); /** - * @brief check if the specified group address is my group + * @brief Check whether the specified group address is my group * - * @return true/false + * @return true/false */ bool esp_mesh_is_my_group(const mesh_addr_t *addr); /** - * @brief set mesh network capacity + * @brief Set mesh network capacity * - * @attention This API shall be called before esp_mesh_start(). + * @attention This API shall be called before esp_mesh_start(). * - * @param num mesh network capacity + * @param[in] num mesh network capacity * * @return * - ESP_OK @@ -1179,16 +1191,16 @@ bool esp_mesh_is_my_group(const mesh_addr_t *addr); esp_err_t esp_mesh_set_capacity_num(int num); /** - * @brief get mesh network capacity + * @brief Get mesh network capacity * - * @return mesh network capacity + * @return mesh network capacity */ int esp_mesh_get_capacity_num(void); /** - * @brief set mesh ie crypto functions + * @brief Set mesh IE crypto functions * - * @param crypto_funcs crypto functions for mesh ie + * @param[in] crypto_funcs crypto functions for mesh IE * * @return * - ESP_OK @@ -1196,12 +1208,12 @@ int esp_mesh_get_capacity_num(void); esp_err_t esp_mesh_set_ie_crypto_funcs(const mesh_crypto_funcs_t *crypto_funcs); /** - * @brief set mesh ie crypto key + * @brief Set mesh IE crypto key * - * @attention This API shall be called after esp_mesh_set_config() and before esp_mesh_start(). + * @attention This API shall be called after esp_mesh_set_config() and before esp_mesh_start(). * - * @param key ASCII crypto key - * @param len length in bytes, range:8~64 + * @param[in] key ASCII crypto key + * @param[in] len length in bytes, range:8~64 * * @return * - ESP_OK @@ -1212,10 +1224,10 @@ esp_err_t esp_mesh_set_ie_crypto_funcs(const mesh_crypto_funcs_t *crypto_funcs); esp_err_t esp_mesh_set_ie_crypto_key(const char *key, int len); /** - * @brief get mesh ie crypto key + * @brief Get mesh IE crypto key * - * @param key ASCII crypto key - * @param len length in bytes, range:8~64 + * @param[out] key ASCII crypto key + * @param[in] len length in bytes, range:8~64 * * @return * - ESP_OK @@ -1224,9 +1236,9 @@ esp_err_t esp_mesh_set_ie_crypto_key(const char *key, int len); esp_err_t esp_mesh_get_ie_crypto_key(char *key, int len); /** - * @brief set delay time before starting root healing + * @brief Set delay time before network starts root healing * - * @param delay_ms delay time in milliseconds + * @param[in] delay_ms delay time in milliseconds * * @return * - ESP_OK @@ -1234,16 +1246,16 @@ esp_err_t esp_mesh_get_ie_crypto_key(char *key, int len); esp_err_t esp_mesh_set_root_healing_delay(int delay_ms); /** - * @brief get delay time before starting root healing + * @brief Get delay time before network starts root healing * - * @return delay time in milliseconds + * @return delay time in milliseconds */ int esp_mesh_get_root_healing_delay(void); /** - * @brief set mesh event callback + * @brief Set mesh event callback * - * @param event_cb mesh event call back + * @param[in] event_cb mesh event call back * * @return * - ESP_OK @@ -1251,11 +1263,12 @@ int esp_mesh_get_root_healing_delay(void); esp_err_t esp_mesh_set_event_cb(const mesh_event_cb_t event_cb); /** - * @brief set Fixed Root setting for the device - * If Fixed Root setting of the device is enabled, it won't compete to be a root. - * If a scenario needs a fixed root, all devices in this network shall enable this setting. + * @brief Enable network Fixed Root Setting + * - Enabling fixed root disables automatic election of the root node via voting. + * - All devices in the network shall use the same Fixed Root Setting (enabled or disabled). + * - If Fixed Root is enabled, users should make sure a root node is designated for the network. * - * @param enable enable or not + * @param[in] enable enable or not * * @return * - ESP_OK @@ -1263,21 +1276,21 @@ esp_err_t esp_mesh_set_event_cb(const mesh_event_cb_t event_cb); esp_err_t esp_mesh_fix_root(bool enable); /** - * @brief check if Fixed Root setting is enabled - * Fixed Root setting can be changed by API esp_mesh_fix_root(). - * Fixed Root setting can also be changed by event MESH_EVENT_ROOT_FIXED. + * @brief Check whether network Fixed Root Setting is enabled + * - Enable/disable network Fixed Root Setting by API esp_mesh_fix_root(). + * - Network Fixed Root Setting also changes with the "flag" value in parent networking IE. * - * @return true/false + * @return true/false */ bool esp_mesh_is_root_fixed(void); /** - * @brief set a specified parent + * @brief Specify a parent for the device * - * @param parent parent configuration, the ssid and the channel of the parent are mandatory. - * @param parent_mesh_id parent mesh ID, if not set, use the device default one. - * @param my_type my mesh type - * @param my_layer my mesh layer + * @param[in] parent parent configuration, the SSID and the channel of the parent are mandatory. + * @param[in] parent_mesh_id parent mesh ID, if not set, use the device default one. + * @param[in] my_type my mesh type + * @param[in] my_layer my mesh layer * * @return * - ESP_OK @@ -1287,9 +1300,9 @@ bool esp_mesh_is_root_fixed(void); esp_err_t esp_mesh_set_parent(const wifi_config_t *parent, const mesh_addr_t *parent_mesh_id, mesh_type_t my_type, int my_layer); /** - * @brief get mesh networking IE length of one AP + * @brief Get mesh networking IE length of one AP * - * @param len mesh networking IE length + * @param[out] len mesh networking IE length * * @return * - ESP_OK @@ -1300,11 +1313,13 @@ esp_err_t esp_mesh_set_parent(const wifi_config_t *parent, const mesh_addr_t *pa esp_err_t esp_mesh_scan_get_ap_ie_len(int *len); /** - * @brief get AP record - * Different from esp_wifi_scan_get_ap_records(), this API only gets one of scanned APs each time. + * @brief Get AP record * - * @param ap_record pointer to the AP record - * @param buffer pointer to the mesh networking IE of this AP + * @attention Different from esp_wifi_scan_get_ap_records(), this API only gets one of APs scanned each time. + * See "manual_networking" example. + * + * @param[out] ap_record pointer to one AP record + * @param[out] buffer pointer to the mesh networking IE of this AP * * @return * - ESP_OK diff --git a/components/esp32/include/esp_mesh_internal.h b/components/esp32/include/esp_mesh_internal.h index 5f73984a1..e1dbf7f72 100644 --- a/components/esp32/include/esp_mesh_internal.h +++ b/components/esp32/include/esp_mesh_internal.h @@ -33,22 +33,20 @@ extern "C" { * Structures *******************************************************/ typedef struct { - int scan; /**< minimum scan times before being a root, default:10. */ - int vote; /**< max vote times in self-healing, default:1000. */ - int fail; /**< parent selection fail times. If the scan times reach this value, - device will disconnect with associated children and join self-healing, default:120. */ - int monitor_ie; /**< acceptable times of parent networking IE change before update self networking IE, default:10. */ + int scan; /**< minimum scan times before being a root, default:10 */ + int vote; /**< max vote times in self-healing, default:1000 */ + int fail; /**< parent selection fail times, if the scan times reach this value, + device will disconnect with associated children and join self-healing. default:60 */ + int monitor_ie; /**< acceptable times of parent networking IE change before update its own networking IE. default:3 */ } mesh_attempts_t; typedef struct { - int duration_ms; /* parent weak RSSI monitor duration. If the RSSI with current parent is less than cnx_rssi continuously - within this duration_ms, device will search for a better parent. */ + int duration_ms; /* parent weak RSSI monitor duration, if the RSSI continues to be weak during this duration_ms, + device will search for a new parent. */ int cnx_rssi; /* RSSI threshold for keeping a good connection with parent. - If set a value greater than -120 dBm, device will arm a timer to monitor current RSSI at a period time of - duration_ms. */ - int select_rssi; /* RSSI threshold for parent selection, should be a value greater than switch_rssi. */ - int switch_rssi; /* RSSI threshold for parent switch. Device will disassociate current parent and switch to a new parent when - the RSSI with the new parent is greater than this set threshold. */ + If set a value greater than -120 dBm, a timer will be armed to monitor parent RSSI at a period time of duration_ms. */ + int select_rssi; /* RSSI threshold for parent selection. It should be a value greater than switch_rssi. */ + int switch_rssi; /* Disassociate with current parent and switch to a new parent when the RSSI is greater than this set threshold. */ int backoff_rssi; /* RSSI threshold for connecting to the root */ } mesh_switch_parent_t; @@ -59,7 +57,7 @@ typedef struct { } mesh_rssi_threshold_t; /** - * @brief mesh networking IE + * @brief Mesh networking IE */ typedef struct { /**< mesh networking IE head */ @@ -82,7 +80,7 @@ typedef struct { uint16_t root_cap; /**< root capacity */ uint16_t self_cap; /**< self capacity */ uint16_t layer2_cap; /**< layer2 capacity */ - uint16_t scan_ap_num; /**< the number of scanned APs */ + uint16_t scan_ap_num; /**< the number of scanning APs */ int8_t rssi; /**< RSSI of the parent */ int8_t router_rssi; /**< RSSI of the router */ uint8_t flag; /**< flag of networking */ @@ -102,9 +100,9 @@ typedef struct { * Function Definitions *******************************************************/ /** - * @brief set mesh softAP beacon interval + * @brief Set mesh softAP beacon interval * - * @param interval beacon interval(ms) (100ms ~ 60000ms) + * @param[in] interval beacon interval (msecs) (100 msecs ~ 60000 msecs) * * @return * - ESP_OK @@ -114,9 +112,9 @@ typedef struct { esp_err_t esp_mesh_set_beacon_interval(int interval_ms); /** - * @brief get mesh softAP beacon interval + * @brief Get mesh softAP beacon interval * - * @param interval beacon interval(ms) + * @param[out] interval beacon interval (msecs) * * @return * - ESP_OK @@ -124,9 +122,9 @@ esp_err_t esp_mesh_set_beacon_interval(int interval_ms); esp_err_t esp_mesh_get_beacon_interval(int *interval_ms); /** - * @brief set attempts for mesh self-organized networking + * @brief Set attempts for mesh self-organized networking * - * @param attempts + * @param[in] attempts * * @return * - ESP_OK @@ -135,9 +133,9 @@ esp_err_t esp_mesh_get_beacon_interval(int *interval_ms); esp_err_t esp_mesh_set_attempts(mesh_attempts_t *attempts); /** - * @brief get attempts for mesh self-organized networking + * @brief Get attempts for mesh self-organized networking * - * @param attempts + * @param[out] attempts * * @return * - ESP_OK @@ -146,9 +144,9 @@ esp_err_t esp_mesh_set_attempts(mesh_attempts_t *attempts); esp_err_t esp_mesh_get_attempts(mesh_attempts_t *attempts); /** - * @brief set parameters for parent switch + * @brief Set parameters for parent switch * - * @param paras parameters for parent switch + * @param[in] paras parameters for parent switch * * @return * - ESP_OK @@ -157,9 +155,9 @@ esp_err_t esp_mesh_get_attempts(mesh_attempts_t *attempts); esp_err_t esp_mesh_set_switch_parent_paras(mesh_switch_parent_t *paras); /** - * @brief get parameters for parent switch + * @brief Get parameters for parent switch * - * @param paras parameters for parent switch + * @param[out] paras parameters for parent switch * * @return * - ESP_OK @@ -168,12 +166,12 @@ esp_err_t esp_mesh_set_switch_parent_paras(mesh_switch_parent_t *paras); esp_err_t esp_mesh_get_switch_parent_paras(mesh_switch_parent_t *paras); /** - * @brief set RSSI threshold - * The default high RSSI threshold value is -78 dBm. - * The default medium RSSI threshold value is -82 dBm. - * The default low RSSI threshold value is -85 dBm. + * @brief Set RSSI threshold + * - The default high RSSI threshold value is -78 dBm. + * - The default medium RSSI threshold value is -82 dBm. + * - The default low RSSI threshold value is -85 dBm. * - * @param threshold RSSI threshold + * @param[in] threshold RSSI threshold * * @return * - ESP_OK @@ -182,8 +180,9 @@ esp_err_t esp_mesh_get_switch_parent_paras(mesh_switch_parent_t *paras); esp_err_t esp_mesh_set_rssi_threshold(const mesh_rssi_threshold_t *threshold); /** - * @brief get RSSI threshold - * @param threshold RSSI threshold + * @brief Get RSSI threshold + * + * @param[out] threshold RSSI threshold * * @return * - ESP_OK @@ -192,11 +191,11 @@ esp_err_t esp_mesh_set_rssi_threshold(const mesh_rssi_threshold_t *threshold); esp_err_t esp_mesh_get_rssi_threshold(mesh_rssi_threshold_t *threshold); /** - * @brief enable the minimum rate to 6Mbps + * @brief Enable the minimum rate to 6 Mbps * - * @attention This API shall be called before WiFi start. + * @attention This API shall be called before Wi-Fi is started. * - * @param is_6m enable or not + * @param[in] is_6m enable or not * * @return * - ESP_OK @@ -204,7 +203,7 @@ esp_err_t esp_mesh_get_rssi_threshold(mesh_rssi_threshold_t *threshold); esp_err_t esp_mesh_set_6m_rate(bool is_6m); /** - * @brief print the number of txQ waiting + * @brief Print the number of txQ waiting * * @return * - ESP_OK @@ -213,7 +212,7 @@ esp_err_t esp_mesh_set_6m_rate(bool is_6m); esp_err_t esp_mesh_print_txQ_waiting(void); /** - * @brief print the number of rxQ waiting + * @brief Print the number of rxQ waiting * * @return * - ESP_OK @@ -222,9 +221,9 @@ esp_err_t esp_mesh_print_txQ_waiting(void); esp_err_t esp_mesh_print_rxQ_waiting(void); /** - * @brief set passive scan time + * @brief Set passive scan time * - * @param interval_ms passive scan time(ms) + * @param[in] interval_ms passive scan time (msecs) * * @return * - ESP_OK @@ -234,19 +233,19 @@ esp_err_t esp_mesh_print_rxQ_waiting(void); esp_err_t esp_mesh_set_passive_scan_time(int time_ms); /** - * @brief get passive scan time + * @brief Get passive scan time * - * @return interval_ms passive scan time(ms) + * @return interval_ms passive scan time (msecs) */ int esp_mesh_get_passive_scan_time(void); /** - * @brief set announce interval - * The default short interval is 500 milliseconds. - * The default long interval is 3000 milliseconds. + * @brief Set announce interval + * - The default short interval is 500 milliseconds. + * - The default long interval is 3000 milliseconds. * - * @param short_ms shall be greater than the default value - * @param long_ms shall be greater than the default value + * @param[in] short_ms shall be greater than the default value + * @param[in] long_ms shall be greater than the default value * * @return * - ESP_OK @@ -254,10 +253,10 @@ int esp_mesh_get_passive_scan_time(void); esp_err_t esp_mesh_set_announce_interval(int short_ms, int long_ms); /** - * @brief get announce interval + * @brief Get announce interval * - * @param short_ms short interval - * @param long_ms long interval + * @param[out] short_ms short interval + * @param[out] long_ms long interval * * @return * - ESP_OK diff --git a/docs/_static/mesh-asynchronous-power-on-example.png b/docs/_static/mesh-asynchronous-power-on-example.png new file mode 100644 index 000000000..7e4833e14 Binary files /dev/null and b/docs/_static/mesh-asynchronous-power-on-example.png differ diff --git a/docs/_static/mesh-beacon-frame-rssi.png b/docs/_static/mesh-beacon-frame-rssi.png new file mode 100644 index 000000000..753189dad Binary files /dev/null and b/docs/_static/mesh-beacon-frame-rssi.png differ diff --git a/docs/_static/mesh-bidirectional-data-stream.png b/docs/_static/mesh-bidirectional-data-stream.png new file mode 100644 index 000000000..056dbd4da Binary files /dev/null and b/docs/_static/mesh-bidirectional-data-stream.png differ diff --git a/docs/_static/mesh-esp-mesh-network-architecture.png b/docs/_static/mesh-esp-mesh-network-architecture.png new file mode 100644 index 000000000..06164b4df Binary files /dev/null and b/docs/_static/mesh-esp-mesh-network-architecture.png differ diff --git a/docs/_static/mesh_events_delivery.png b/docs/_static/mesh-events-delivery.png similarity index 100% rename from docs/_static/mesh_events_delivery.png rename to docs/_static/mesh-events-delivery.png diff --git a/docs/_static/mesh-network-building.png b/docs/_static/mesh-network-building.png new file mode 100644 index 000000000..7d1508111 Binary files /dev/null and b/docs/_static/mesh-network-building.png differ diff --git a/docs/_static/mesh-node-types.png b/docs/_static/mesh-node-types.png new file mode 100644 index 000000000..7d28cb746 Binary files /dev/null and b/docs/_static/mesh-node-types.png differ diff --git a/docs/_static/mesh-packet.png b/docs/_static/mesh-packet.png new file mode 100644 index 000000000..903827af1 Binary files /dev/null and b/docs/_static/mesh-packet.png differ diff --git a/docs/_static/mesh-parent-node-failure.png b/docs/_static/mesh-parent-node-failure.png new file mode 100644 index 000000000..658bbc5f1 Binary files /dev/null and b/docs/_static/mesh-parent-node-failure.png differ diff --git a/docs/_static/mesh-preferred-parent-node.png b/docs/_static/mesh-preferred-parent-node.png new file mode 100644 index 000000000..700038d3b Binary files /dev/null and b/docs/_static/mesh-preferred-parent-node.png differ diff --git a/docs/_static/mesh-root-node-designated-example.png b/docs/_static/mesh-root-node-designated-example.png new file mode 100644 index 000000000..e16594dec Binary files /dev/null and b/docs/_static/mesh-root-node-designated-example.png differ diff --git a/docs/_static/mesh-root-node-election-example.png b/docs/_static/mesh-root-node-election-example.png new file mode 100644 index 000000000..1255c52a4 Binary files /dev/null and b/docs/_static/mesh-root-node-election-example.png differ diff --git a/docs/_static/mesh-root-node-failure.png b/docs/_static/mesh-root-node-failure.png new file mode 100644 index 000000000..cc6576031 Binary files /dev/null and b/docs/_static/mesh-root-node-failure.png differ diff --git a/docs/_static/mesh-root-node-switch-example.png b/docs/_static/mesh-root-node-switch-example.png new file mode 100644 index 000000000..9074bab01 Binary files /dev/null and b/docs/_static/mesh-root-node-switch-example.png differ diff --git a/docs/_static/mesh-routing-tables-example.png b/docs/_static/mesh-routing-tables-example.png new file mode 100644 index 000000000..2e6673cce Binary files /dev/null and b/docs/_static/mesh-routing-tables-example.png differ diff --git a/docs/_static/mesh_software_stack.png b/docs/_static/mesh-software-stack.png similarity index 100% rename from docs/_static/mesh_software_stack.png rename to docs/_static/mesh-software-stack.png diff --git a/docs/_static/mesh-traditional-network-architecture.png b/docs/_static/mesh-traditional-network-architecture.png new file mode 100644 index 000000000..d3dc9901f Binary files /dev/null and b/docs/_static/mesh-traditional-network-architecture.png differ diff --git a/docs/_static/mesh-tree-topology.png b/docs/_static/mesh-tree-topology.png new file mode 100644 index 000000000..ad70b8377 Binary files /dev/null and b/docs/_static/mesh-tree-topology.png differ diff --git a/docs/_static/mesh_network_architecture.png b/docs/_static/mesh_network_architecture.png deleted file mode 100644 index 4c54db128..000000000 Binary files a/docs/_static/mesh_network_architecture.png and /dev/null differ diff --git a/docs/_static/mesh_network_topology.png b/docs/_static/mesh_network_topology.png deleted file mode 100644 index 5bdf7a145..000000000 Binary files a/docs/_static/mesh_network_topology.png and /dev/null differ diff --git a/docs/en/api-guides/index.rst b/docs/en/api-guides/index.rst index 0a0f9c8e9..dd3dfeb2c 100644 --- a/docs/en/api-guides/index.rst +++ b/docs/en/api-guides/index.rst @@ -25,6 +25,6 @@ API Guides Console Component ROM debug console WiFi Driver - Mesh Stack + ESP-MESH BluFi External SPI-connected RAM diff --git a/docs/en/api-guides/mesh.rst b/docs/en/api-guides/mesh.rst index 4c252e792..87488be12 100644 --- a/docs/en/api-guides/mesh.rst +++ b/docs/en/api-guides/mesh.rst @@ -1,281 +1,1013 @@ ESP-MESH ======== +This guide provides information regarding the ESP-MESH protocol. Please see the +:doc:`MESH API Reference<../api-reference/mesh/esp_mesh>` for more information +about API usage. + +.. ------------------------------- Overview ----------------------------------- + Overview -------- -ESP-MESH is a "multi-hop" network, meaning that two or more wireless hops (intermediate connections of two Internet devices) are needed for conveying information from a source to a destination. Mesh networking (or mesh routing) is a type of network topology in which a device (node) transmits its own data, while serving as a relay for other nodes at the same time. The prerequisite for successful wireless mesh routing is that all mesh nodes need to be interconnected on the physical layer first. The mesh routing algorithm, then, chooses the transmission path among these physical-layer links. As a highly reliable, widely-covered Wireless Local-Area Network (WLAN) network, the ESP-MESH is ideal for wireless solutions covering a large open area (both outdoors and indoors). -ESP-MESH network is different from traditional wireless networks. The traditional wireless access technology implements a point-to-point or multipoint topology. There is generally one central node in such a topology, for example, a base station in a mobile communication system or an access point (AP) in an 802.11 WLAN. The central node and each wireless terminal are connected through single-hop wireless routing which controls each wireless terminal's access to the wireless network. Besides, the central node is connected to the backbone network through a wired link. In comparison, the ESP-MESH adopts a tree topology, with a root node, intermediate nodes and leaf nodes, making the network more expandable and fault-tolerant. Any mesh device on the network can compete to be the root node. Should the root node break down, the network will automatically select a new root node. This effectively decreases the tree topology’s dependence on a single node and allows every node to participate in the relay of information. +ESP-MESH is a networking protocol built atop the Wi-Fi protocol. ESP-MESH allows +numerous devices (henceforth referred to as nodes) spread over a large physical +area (both indoors and outdoors) to be interconnected under a single WLAN (Wireless +Local-Area Network). ESP-MESH is self-organizing and self-healing meaning the network +can be built and maintained autonomously. -.. figure:: ../../_static/mesh_network_architecture.png - :align: center - :alt: Mesh Network Architecture +The ESP-MESH guide is split into the following sections: - ESP-MESH Network Architecture +1. :ref:`mesh-introduction` + +2. :ref:`mesh-concepts` + +3. :ref:`mesh-building-a-network` + +4. :ref:`mesh-managing-a-network` + +5. :ref:`mesh-data-transmission` + +6. :ref:`mesh-network-performance` + +7. :ref:`mesh-further-notes` + + +.. ----------------------------- Introduction --------------------------------- + +.. _mesh-introduction: Introduction ------------ -ESP-MESH defines a network that organizes and heals itself, enabling faster networking and better control. -There are three types of nodes in a mesh network, in terms of their function within the mesh network: root node, intermediate node and leaf node. - -- Root node: this is the top node in the mesh network, which serves as the only interface between the mesh network and an external IP network. It functions as a gateway that relays packets outside the mesh network. - -- Intermediate node: a mesh node other than the root node and leaf nodes in a mesh network. An intermediate node can receive, send and forward the packets coming from its parent (immediately preceding) node, as well as its child (immediately following) nodes. - -- Leaf node: this is a mesh node that can only receive or send packets, but cannot forward packets. - -Each node that forwards data forms a parent/child node relationship with other nodes according to their position in the mesh network. The root node, through which the mesh network can communicate with an external IP network, is a node directly connected to the router and can transmit data between its child nodes and the router. The number of access devices and the bandwidth of the router directly affect the throughput of the root-node device, when accessing the external IP network. - -.. figure:: ../../_static/mesh_network_topology.png +.. figure:: ../../_static/mesh-traditional-network-architecture.png :align: center - :alt: Mesh Network Topology + :alt: Diagram of Traditional Network Architectures + :figclass: align-center - ESP-MESH Network Topology and Data Stream + Traditional Wi-Fi Network Architectures -As the above figure shows, node C and node D are intermediate nodes, while also being child nodes to the root node. Leaf E is the child node of node D. Leaf nodes A, B, and E have no child nodes. ESP-MESH is based on data link layer packet-forwarding, and no TCP/IP layer is needed in the mesh system except for the root node. See the figure “ESP-MESH Software Stack” for reference. +A traditional infrastructure Wi-Fi network is a point-to-multipoint network where a single +central node known as the access point (AP) is directly connected to all other +nodes known as stations. The AP is responsible for arbitrating and forwarding +transmissions between the stations. Some APs also relay transmissions to/from an +external IP network via a router. Traditional infrastructure Wi-Fi networks suffer the +disadvantage of limited coverage area due to the requirement that every station +must be in range to directly connect with the AP. Furthermore, traditional Wi-Fi +networks are susceptible to overloading as the maximum number of stations permitted +in the network is limited by the capacity of the AP. -Function Description --------------------- +.. figure:: ../../_static/mesh-esp-mesh-network-architecture.png + :align: center + :alt: Diagram of ESP-MESH Network Architecture + :figclass: align-center -1. Mesh Networking -^^^^^^^^^^^^^^^^^^^^^ -**(1) Mesh Configuration** + ESP-MESH Network Architecture -A router is mandatory during the ESP-MESH networking. Users need to configure the Service Set Identification (SSID), password and channel of the router for each node. If the router is hidden, users will need to configure the Basic Service Set Identification (BSSID) for the nodes.（For mesh configuration solutions, please refer to the link to Mesh IoT solutions. The link will be released soon.） - -The information needed for mesh networking is carried by the Vendor Information Element (VIE) in beacon frame, which includes the node type, the layer of the node in the network, the maximum number of layers allowed in the network, the number of child nodes, the maximum number of nodes allowed to be connected to a single node, and more. - -**(2) Root Node Election** - -If there is no root node in the network, all the mesh devices will broadcast the real-time signal strength (RSSI) with the router. Each device networking information, including the signal strength with the router, is transmitted to the entire mesh network, so that all mesh devices can use that infromation to choose the one with the strongest signal as the root node. - -POR, all devices are scanned separately. Each device selects the device with the greatest real-time signal strength, compared to the signal received by other devices from the router as well as to the strength of the router itself. The selection is, then, broadcast as a root-node candidate. - -Subsequently, each mesh device scans the mesh network for a second time, and selects the device with the greatest real-time signal strength as root-node candidate. The selection is broadcast again. This process is repeated until only one root-node candidate remains in the end. - -ESP-MESH also employs methods to accelerate the convergence of the root node election. - -**(3) Parent Node Selection** - -ESP-MESH provides a method for selecting the strongest parent node in a mesh network. According to this method, a node obtains information about other nodes from received VIE messages, and generates a set of parent nodes. If the parent set comprises at least two nodes, the one with the highest performance parameter is selected as the preferred parent. According to this method, a preferred parent node is selected because of the node type and the performance parameter of each node in the parent set. This method ensures that the preferred parent is the optimal one, thus reducing packet loss rate which, in turn, improves network performance. - -2. Routing Generation and Maintenance -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +ESP-MESH differs from traditional infrastructure Wi-Fi networks in that nodes are not required +to connect to a central node. Instead, nodes are permitted to connect with +neighboring nodes. Nodes are mutually responsible for relaying each others +transmissions. This allows an ESP-MESH network to have much greater coverage area +as nodes can still achieve interconnectivity without needing to be in range of +the central node. Likewise, ESP-MESH is also less susceptible to overloading as +the number of nodes permitted on the network is no longer limited by a single +central node. -3. Network Management +.. -------------------------- ESP-MESH Concepts ------------------------------- + +.. _mesh-concepts: + +ESP-MESH Concepts +----------------- + +Terminology +^^^^^^^^^^^ + ++--------------------------+----------------------------------------------------------------+ +| Term | Description | ++==========================+================================================================+ +| Node | Any device that **is** or **can be** part of an ESP-MESH | +| | network | ++--------------------------+----------------------------------------------------------------+ +| Root Node | The top node in the network | ++--------------------------+----------------------------------------------------------------+ +| Child Node | A node X is a child node when it is connected to another node | +| | Y where the connection makes node X more distant from the root | +| | node than node Y (in terms of number of connections). | ++--------------------------+----------------------------------------------------------------+ +| Parent Node | The converse notion of a child node | ++--------------------------+----------------------------------------------------------------+ +| Sub-Child Node | Any node reachable by repeated proceeding from parent to child | ++--------------------------+----------------------------------------------------------------+ +| Sibling Nodes | Nodes that share the same parent node | ++--------------------------+----------------------------------------------------------------+ +| Connection | A traditional Wi-Fi association between an AP and a station. | +| | A node in ESP-MESH will use its station interface to associate | +| | with the softAP interface of another node, thus forming a | +| | connection. The connection process includes the authentication | +| | and association processes in Wi-Fi. | ++--------------------------+----------------------------------------------------------------+ +| Upstream Connection | The connection from a node to its parent node | ++--------------------------+----------------------------------------------------------------+ +| Downstream Connection | The connection from a node to one of its child nodes | ++--------------------------+----------------------------------------------------------------+ +| Wireless Hop | The portion of the path between source and destination nodes | +| | that corresponds to a single wireless connection. A data | +| | packet that traverses a single connection is known as | +| | **single-hop** whereas traversing multiple connections is | +| | known as **multi-hop**. | ++--------------------------+----------------------------------------------------------------+ +| Subnetwork | A subnetwork is subdivision of an ESP-MESH network which | +| | consists of a node and all of its descendant nodes. Therefore | +| | the subnetwork of the root node consists of all nodes in an | +| | ESP-MESH network. | ++--------------------------+----------------------------------------------------------------+ +| MAC Address | Media Access Control Address used to uniquely identify each | +| | node or router within an ESP-MESH network. | ++--------------------------+----------------------------------------------------------------+ +| DS | Distribution System (External IP Network) | ++--------------------------+----------------------------------------------------------------+ + +Tree Topology +^^^^^^^^^^^^^ + +ESP-MESH is built atop the infrastructure Wi-Fi protocol and can be thought of +as a networking protocol that combines many individual Wi-Fi networks into a single +WLAN. In Wi-Fi, stations are limited to a single connection with an AP (upstream +connection) at any time, whilst an AP can be simultaneously connected to multiple +stations (downstream connections). However ESP-MESH allows nodes to simultaneously +act as a station and an AP. Therefore a node in ESP-MESH can have **multiple downstream +connections using its softAP interface**, whilst simultaneously having **a single +upstream connection using its station interface**. This naturally results in a +tree network topology with a parent-child hierarchy consisting of multiple layers. + +.. figure:: ../../_static/mesh-tree-topology.png + :align: center + :alt: Diagram of ESP-MESH Tree Topology + :figclass: align-center + + ESP-MESH Tree Topology + +ESP-MESH is a multiple hop (multi-hop) network meaning nodes can transmit packets +to other nodes in the network through one or more wireless hops. Therefore, nodes +in ESP-MESH not only transmit their own packets, but simultaneously serve as relays +for other nodes. Provided that a path exists between any two nodes on the physical +layer (via one or more wireless hops), any pair of nodes within an ESP-MESH network +can communicate. + +.. note:: + The size (total number of nodes) in an ESP-MESH network is dependent on the + maximum number of layers permitted in the network, and the maximum number of + downstream connections each node can have. Both of these variables can be + configured to limit the size of the network. + +Node Types +^^^^^^^^^^ + +.. figure:: ../../_static/mesh-node-types.png + :align: center + :alt: Diagram of ESP-MESH Node Types + :figclass: align-center + + ESP-MESH Node Types + +**Root Node:** The root node is the top node in the network and serves as the only +interface between the ESP-MESH network and an external IP network. The root node +is connected to a conventional Wi-Fi router and relays packets to/from the external +IP network to nodes within the ESP-MESH network. **There can only be one root node +within an ESP-MESH network** and the root node's upstream connection may only be +with the router. Referring to the diagram above, node A is the root node of the +network. + +**Leaf Nodes:** A leaf node is a node that is not permitted to have any child nodes +(no downstream connections). Therefore a leaf node can only transmit or receive +its own packets, but cannot forward the packets of other nodes. If a node is situated +on the network's maximum permitted layer, it will be assigned as a leaf node. This +prevents the node from forming any downstream connections thus ensuring the network +does not add an extra layer. Some nodes without a softAP interface (station only) +will also be assigned as leaf nodes due to the requirement of a softAP interface +for any downstream connections. Referring to the diagram above, nodes L/M/N are +situated on the networks maximum permitted layer hence have been assigned as leaf nodes . + +**Intermediate Parent Nodes:** Connected nodes that are neither the root node or +a leaf node are intermediate parent nodes. An intermediate parent node must have +a single upstream connection (a single parent node), but can have zero to multiple +downstream connections (zero to multiple child nodes). Therefore an intermediate +parent node can transmit and receive packets, but also forward packets sent from its +upstream and downstream connections. Referring to the diagram above, nodes +B to J are intermediate parent nodes. **Intermediate parent nodes without downstream +connections such as nodes E/F/G/I/J are not equivalent to leaf nodes** as they +are still permitted to form downstream connections in the future. + +**Idle Nodes:** Nodes that have yet to join the network are assigned as idle nodes. +Idle nodes will attempt to form an upstream connection with an intermediate parent +node or attempt to become the root node under the correct circumstances (see +`Automatic Root Node Selection`_). Referring to the diagram above, nodes K and O +are idle nodes. + +Beacon Frames & RSSI Thresholding +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Every node in ESP-MESH that is able to form downstream connections (i.e. has a +softAP interface) will periodically transmit Wi-Fi beacon frames. A node uses +beacon frames to allow other nodes to detect its presence and know of its status. +Idle nodes will listen for beacon frames to generate a list of potential parent nodes, +one of which the idle node will form an upstream connection with. ESP-MESH uses +the Vendor Information Element to store metadata such as: + +- Node Type (Root, Intermediate Parent, Leaf, Idle) +- Current layer of Node +- Maximum number of layers permitted in the network +- Current number of child nodes +- Maximum number of downstream connections to accept + +The signal strength of a potential upstream connection is represented by RSSI +(Received Signal Strength Indication) of the beacon frames of the potential parent +node. To prevent nodes from forming a weak upstream connection, ESP-MESH implements +an RSSI threshold mechanism for beacon frames. If a node detects a beacon frame +with an RSSI below a preconfigured threshold, the transmitting node will be +disregarded when forming an upstream connection. + +.. figure:: ../../_static/mesh-beacon-frame-rssi.png + :align: center + :alt: Diagram of the Effects of RSSI Thresholding + :figclass: align-center + + Effects of RSSI Thresholding + +**Panel A** of the illustration above demonstrates how the RSSI threshold affects +the number of parent node candidates an idle node has. + +**Panel B** of the illustration above demonstrates how an RF shielding object can +lower the RSSI of a potential parent node. Due to the RF shielding object, the +area in which the RSSI of node X is above the threshold is significantly reduced. +This causes the idle node to disregard node X even though node X is physically +adjacent. The idle node will instead form an upstream connection with the physically +distant node Y due to a stronger RSSI. + +.. note:: + Nodes technically still receive all beacon frames on the MAC layer. The RSSI + threshold is an ESP-MESH feature that simply filters out all received beacon + frames that are below the preconfigured threshold. + +Preferred Parent Node ^^^^^^^^^^^^^^^^^^^^^ -+-----------------------+------------------------------------------------------------------------------------------+ -| Function | Description | -+=======================+==========================================================================================+ -|Self-healing |Self-healing allows such routing-based network to operate when a node breaks down or when | -| |a connection becomes unreliable. | -| | | -| |If a root node breaks down, the nodes directly connected with it on the second layer will | -| |detect the root-node failure quickly and initialize a new round of root node election. If | -| |the root node and all the nodes on the second layer break down, the nodes on the third | -| |layer will initialize root node election and a new root node will be elected eventually. | -| | | -| |In the event of a failure of the intermediate nodes and the leaf nodes, failed nodes will | -| |reconnect their parent nodes respectively for a predefined number of times and will, then,| -| |reselect a new parent node to join the mesh network. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Root node switch |Users can call :cpp:func:`esp_mesh_waive_root` to switch root nodes in the network. | -| |The new root node can be specified by the users or be automatically elected by the | -| |network. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Root conflicts handling|Only the conflicts of root nodes connecting to the same router are handled. Conflicts of | -| |root nodes having the same router SSID, but different router BSSID, are not handled. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Parent node switch |Changing the physical position of a node in the mesh network will lead to declined signal | -| |strength of the parent node and problematic communication. Upon detecting such a problem, | -| |this function will automatically choose a better parent node for this node. | -| | | -| |When the position of a mobile node changes constantly, communication with the parent node | -| |deteriorates or even drops. After such a situation is detected, the parent of the mobile | -| |node is automatically reselected, so that communication with the network is maintained. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Loopback avoidance, |During the parent selection, the nodes covered in its own routing table are excluded, | -|detection and handling |so that the occurrence of a loopback is avoided. | -| | | -| |The path verification mechanism and the energy transfer mechanism are used for detecting | -| |the loopback. | -| | | -| |When a loopback is detected, the parent node will disconnect with the child node and | -| |inform it about the occurrence of the loop with a predefined reason code. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Channel switch |TO-DO | -+-----------------------+------------------------------------------------------------------------------------------+ -|Isolated node avoidance|TO-DO | -|and handling | | -+-----------------------+------------------------------------------------------------------------------------------+ +When an idle node has multiple parent nodes candidates (potential parent nodes), +the idle node will form an upstream connection with the **preferred parent node**. +The preferred parent node is determined based on the following criteria: -4. Data Transmission -^^^^^^^^^^^^^^^^^^^^ +- Which layer the parent node candidate is situated on +- The number of downstream connections (child nodes) the parent node candidate currently has -+-----------------------+------------------------------------------------------------------------------------------+ -| Function | Description | -+=======================+==========================================================================================+ -|Reliability |ESP-MESH provides P2P(point-to-point) retransmission on mesh layer. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Upstream flow control |When a node in the mesh network is chosen as a parent node, the upstream data of each of | -| |its child nodes is allocated a receiving window, the size of which can be dynamically | -| |adjusted. The child node sends a window request to the parent node before sending data | -| |packets. The parent node compares the request’s sequence number, which corresponds to the | -| |child node's pending packet in the window request, with the sequence number of the parent | -| |node's most recently received packet from the child node. The size of the receiving window| -| |is calculated and returned to the child node. The child node, then, sends the packet, | -| |according to the reply’s receiving-window size. | -| | | -| |In addition, considering that there is only one exit from the entire mesh network, which | -| |is the root node, it is only the root node which can access external IP networks. If the | -| |other nodes are uninformed of the connection status between the root node and the external| -| |network, and keep sending packets to the root node, there is a possibility of packet loss | -| |or unnecessary packet-sending. ESP-MESH provides a method of flow control on the upstream | -| |data, which stabilizes the throughput of the mesh network’s exit by monitoring the | -| |connection status between the root node and the external network, thus avoiding packet | -| |loss or unnecessary packet-sending. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Supporting multicast |Only specified devices can receive multicast packets. Thus, users need to specify these | -|packets |devices by configuring the relevant input parameters for the API :cpp:func:`esp_mesh_send`| -+-----------------------+------------------------------------------------------------------------------------------+ -|Supporting broadcast |ESP-MESH provides a method to avoid a waste of bandwidth. | -|packets | | -| |1. When the broadcast packet transmitted by the intermediate node has been received from | -| |its parent node, the intermediate node sends itself a copy of the broadcast packet, while | -| |sending the original broadcast packet to its child nodes. | -| | | -| |2. When a broadcast packet transmitted by an intermediate node has been generated by | -| |itself, the broadcast packet is sent both to its parent and child nodes. | -| | | -| |3. When a broadcast packet transmitted by an intermediate node has been received from its | -| |child node, the broadcast packet is delivered to the intermediate node itself and its | -| |remaining child nodes, while a copy of the broadcast packet is transmitted to the | -| |intermediate’s parent node. | -| | | -| |4. When a leaf node generates a broadcast packet, the leaf node sends the broadcast packet| -| |to its parent node directly. | -| | | -| |5. When the broadcast packet transmitted by the root node has been generated by the root | -| |node itself, the broadcast packet is delivered to the root’s child node. | -| | | -| |6. When the broadcast packet transmitted by the root node has been received from its child| -| |node, the broadcast packet is sent to the remaining child nodes of the root node. | -| | | -| |7. When a node receives a broadcast packet initially sent from the address of the node | -| |itself, it discards this broadcast packet. | -| | | -| |8. When a node receives a broadcast packet from its parent node, which has been originally| -| |sent from its own child node, it discards this broadcast packet. | -+-----------------------+------------------------------------------------------------------------------------------+ -|Group control |Firsty users must specify a group ID for the device via :cpp:func:`esp_mesh_set_group_id`.| -| |Then when one packet is sent target to this group, only devices in this group can receive | -| |it. | -+-----------------------+------------------------------------------------------------------------------------------+ +The selection of the preferred parent node will always prioritize the parent node +candidate on the shallowest layer of the network (including the root node). This +helps minimize the total number of layers in an ESP-MESH network when upstream +connections are formed. For example, given a second layer node and a third layer +node, the second layer node will always be preferred. -5. Performance +If there are multiple parent node candidates within the same layer, the parent +node candidate with the least child nodes will be preferred. This criteria has +the effect of balancing the number of downstream connections amongst nodes of +the same layer. + +.. figure:: ../../_static/mesh-preferred-parent-node.png + :align: center + :alt: Diagram of Preferred Parent Node Selection + :figclass: align-center + + Preferred Parent Node Selection + +**Panel A** of the illustration above demonstrates an example of how the idle +node G selects a preferred parent node given the five parent node candidates +B/C/D/E/F. Nodes on the shallowest layer are preferred, hence nodes B/C are +prioritized since they are second layer nodes whereas nodes D/E/F are on the +third layer. Node C is selected as the preferred parent node due it having fewer +downstream connections (fewer child nodes) compared to node B. + +**Panel B** of the illustration above demonstrates the case where the root node +is within range of the idle node G. In other words, the root node's beacon frames +are above the RSSI threshold when received by node G. The root node is always the +shallowest node in an ESP-MESH network hence is always the preferred parent node +given multiple parent node candidates. + +.. note:: + Users may also define their own algorithm for selecting a preferred parent + node, or force a node to only connect with a specific parent node (see the + :example:`Mesh Manual Networking Example`). + +Routing Tables ^^^^^^^^^^^^^^ -+--------------------+------------------------------------------------------------------------------------------+ -| Function | Description | -+====================+==========================================================================================+ -|Networking time |Less than 15 seconds. The time is from tests executed on a network with 50 devices. | -+--------------------+------------------------------------------------------------------------------------------+ -|Healing time |If a root node breaks down, less than 10 seconds is taken for the network to detect that | -| |and generate a new root. If a parent node breaks down, less than 5 seconds is taken for | -| |its child nodes to detect that and reselect a new parent node. | -| |The time is also from tests executed on a network with 50 devices. | -+--------------------+------------------------------------------------------------------------------------------+ -|Layer forward delay |30ms. The delay is from tests executed on a network with 100 devices and all devices did | -| |not enable AMPDU. | -+--------------------+------------------------------------------------------------------------------------------+ -|Packet loss rate |max: %0.32 in data transmitted from layer 2 to layer 4; min: %0.00 | -| |The results are also from tests executed on a network with 100 devices. | -+--------------------+------------------------------------------------------------------------------------------+ -|Network capacity |The network capacity is terminated by the maximum number of devices allowed to be | -| |connected to the softAP, and by the maximum number of network layers allowed in the | -| |network. | -+--------------------+------------------------------------------------------------------------------------------+ +Each node within an ESP-MESH network will maintain its individual routing table +used to correctly route ESP-MESH packets (see `ESP-MESH Packet`_) to the correct +destination node. The routing table of a particular node will **consist of the +MAC addresses of all nodes within the particular node's subnetwork** (including +the MAC address of the particular node itself). Each routing table is internally +partitioned into multiple subtables with each subtable corresponding to the +subnetwork of each child node. -**Note:** All device are configured 6 connections and 6 layers during the above mentioned tests. +.. figure:: ../../_static/mesh-routing-tables-example.png + :align: center + :alt: Diagram of ESP-MESH Routing Tables Example + :figclass: align-center -6. Security and Encryption -^^^^^^^^^^^^^^^^^^^^^^^^^^ -**(1) Uses WPA2-PSK** + ESP-MESH Routing Tables Example -**(2) AES Encryption for Mesh VIE** +Using the diagram above as an example, the routing table of node B would consist +of the MAC addresses of nodes B to I (i.e. equivalent to the subnetwork of node +B). Node B's routing table is internally partitioned into two subtables containing +of nodes C to F and nodes G to I (i.e. equivalent to the subnetworks of nodes C +and G respectively). -7. Power Management (TO-DO) +**ESP-MESH utilizes routing tables to determine whether an ESP-MESH packet should +be forwarded upstream or downstream based on the following rules.** + +**1.** If the packet's destination MAC address is within the current node's routing +table and is not the current node, select the subtable that contains the destination +MAC address and forward the data packet downstream to the child node corresponding +to the subtable. + +**2.** If the destination MAC address is not within the current node's routing table, +forward the data packet upstream to the current node's parent node. Doing so repeatedly +will result in the packet arriving at the root node where the routing table should +contain all nodes within the network. + +.. note:: + Users can call :cpp:func:`esp_mesh_get_routing_table` to obtain a node's routing + table, or :cpp:func:`esp_mesh_get_routing_table_size` to obtain the size of a + node's routing table. + + :cpp:func:`esp_mesh_get_subnet_nodes_list` can be used to obtain the corresponding + subtable of a specific child node. Likewise, :cpp:func:`esp_mesh_get_subnet_nodes_num` + can be used to obtain the size of the subtable. + + +.. ------------------------ Building a Mesh Network --------------------------- + +.. _mesh-building-a-network: + +Building a Network +------------------ + +General Process +^^^^^^^^^^^^^^^ + +.. warning:: + Before the ESP-MESH network building process can begin, certain parts of the + configuration must be uniform across each node in the network (see + :cpp:type:`mesh_cfg_t`). Each node must be configured with **the same Mesh + Network ID, router configuration, and softAP configuration**. + +An ESP-MESH network building process involves selecting a root node, then forming +downstream connections layer by layer until all nodes have joined the network. The exact +layout of the network can be dependent on factors such as root node selection, +parent node selection, and asynchronous power-on reset. However, the ESP-MESH network +building process can be generalized into the following steps: + +.. figure:: ../../_static/mesh-network-building.png + :align: center + :alt: Diagram of ESP-MESH Network Building Process + :figclass: align-center + + ESP-MESH Network Building Process + +1. Root Node Selection +"""""""""""""""""""""" +The root node can be designated during configuration (see section on +`User Designated Root Node`_), or dynamically elected based on the signal strength +between each node and the router (see `Automatic Root Node Selection`_). Once selected, +the root node will connect with the router and begin allowing downstream connections +to form. Referring to the figure above, node A is selected to be the root node +hence node A forms an upstream connection with the router. + +2. Second Layer Formation +""""""""""""""""""""""""" +Once the root node has connected to the router, idle nodes in range of the root +node will begin connecting with the root node thereby forming the second layer +of the network. Once connected, the second layer nodes become intermediate parent +nodes (assuming maximum permitted layers > 2) hence the next layer to form. Referring +to the figure above, nodes B to D are in range of the root node. Therefore nodes +B to D form upstream connections with the root node and become intermediate parent +nodes. + +3. Formation of remaining layers +"""""""""""""""""""""""""""""""" +The remaining idle nodes will connect with intermediate parent nodes within range +thereby forming a new layer in the network. Once connected, the idles nodes become +intermediate parent node or leaf nodes depending on the networks maximum permitted +layers. This step is repeated until there are no more idle nodes within the network +or until the maximum permitted layer of the network has been reached. Referring to +the figure above, nodes E/F/G connect with nodes B/C/D respectively and become +intermediate parent nodes themselves. + +4. Limiting Tree Depth +"""""""""""""""""""""" +To prevent the network from exceeding the maximum permitted number of layers, nodes +on the maximum layer will automatically become leaf nodes once connected. This +prevents any other idle node from connecting with the leaf node thereby prevent +a new layer form forming. However if an idle node has no other potential parent +node, it will remain idle indefinitely. Referring to the figure above, the network's +maximum permitted layers is set to four. Therefore when node H connects, it becomes +a leaf node to prevent any downstream connections from forming. + +Automatic Root Node Selection +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The automatic selection of a root node involves an election process amongst +all idle nodes based on their signal strengths with the router. Each idle node +will transmit their MAC addresses and router RSSI values via Wi-Fi beacon frames. +**The MAC address is used to uniquely identify each node in the network** whilst +the **router RSSI** is used to indicate a node's signal strength with reference to +the router. + +Each node will then simultaneously scan for the beacon frames from other idle nodes. +If a node detects a beacon frame with a stronger router RSSI, the node will begin +transmitting the contents of that beacon frame (i.e. voting for the node with +the stronger router RSSI). The process of transmission and scanning will repeat +for a preconfigured minimum number of iterations (10 iterations by default) and result +in the beacon frame with the strongest router RSSI being propagated throughout +the network. + +After all iterations, each node will individually check for its **vote percentage** +(``number of votes/number of nodes participating in election``) to determine if it should become the +root node. **If a node has a vote percentage larger than a preconfigured threshold +(90% by default), the node will become a root node**. + +The following diagram demonstrates how an ESP-MESH network is built when the root +node is automatically selected. + +.. figure:: ../../_static/mesh-root-node-election-example.png + :align: center + :alt: Diagram of Root Node Election Process Example + :figclass: align-center + + Root Node Election Example + +**1.** On power-on reset, each node begins transmitting beacon frames consisting +of their own MAC addresses and their router RSSIs. + +**2.** Over multiple iterations of transmission and scanning, the beacon frame +with the strongest router RSSI is propagated throughout the network. Node C has +the strongest router RSSI (-10db) hence its beacon frame is propagated throughout the +network. All nodes participating in the election vote for node C thus giving node +C a vote percentage of 100%. Therefore node C becomes a root node and connects with +the router. + +**3.** Once Node C has connected with the router, nodes A/B/D/E connect +with node C as it is the preferred parent node (i.e. the shallowest node). Nodes +A/B/D/E form the second layer of the network. + +**4.** Node F and G connect with nodes D and E respectively and the network building +process is complete. + +.. note:: + The minimum number of iterations for the election process can be configured + using :cpp:func:`esp_mesh_set_attempts`. Users should adjust the number + of iterations based on the number of nodes within the network (i.e. the larger + the network the larger number of scan iterations required). + +.. warning:: + **Vote percentage threshold** can also be configured using + :cpp:func:`esp_mesh_set_vote_percentage`. Setting a low vote percentage + threshold **can result in two or more nodes becoming root nodes** within the + same ESP-MESH network leading to the building of multiple networks. If + such is the case, ESP-MESH has internal mechanisms to autonomously resolve + the **root node conflict**. The networks of the multiple root nodes will be + combined into a single network with a single root node. However, root node + conflicts where two or more root nodes have the same router SSID but different + router BSSID are not handled. + +User Designated Root Node +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The root node can also be designated by user which will entail the designated root node +to directly connect with the router and forgo the election process. When a root +node is designated, all other nodes within the network must also forgo the election +process to prevent the occurrence of a root node conflict. The following diagram demonstrates +how an ESP-MESH network is built when the root node is designated by the user. + +.. figure:: ../../_static/mesh-root-node-designated-example.png + :align: center + :alt: Diagram of Root Node Designation Process Example + :figclass: align-center + + Root Node Designation Example (Root Node = A, Max Layers = 4) + +**1.** Node A is designated the root node by the user therefore directly connects +with the router. All other nodes forgo the election process. + +**2.** Nodes C/D connect with node A as their preferred parent node. Both +nodes form the second layer of the network. + +**3.** Likewise, nodes B/E connect with node C, and node F connects with +node D. Nodes B/E/F form the third layer of the network. + +**4.** Node G connects with node E, forming the fourth layer of the network. +However the maximum permitted number of layers in this network is configured as +four, therefore node G becomes a leaf node to prevent any new layers from forming. + +.. note:: + When designating a root node, the root node should call :cpp:func:`esp_mesh_set_parent` + in order to directly connect with the router. Likewise, all other nodes should + call :cpp:func:`esp_mesh_fix_root` to forgo the election process. + +Parent Node Selection +^^^^^^^^^^^^^^^^^^^^^ + +By default, ESP-MESH is self organizing meaning that each node will autonomously +select which potential parent node to form an upstream connection with. The autonomously +selected parent node is known as the preferred parent node. The criteria used for +selecting the preferred parent node is designed to reduce the number of layers in +the ESP-MESH network and to balance the number of downstream connections between +potential parent nodes (see section on `Preferred Parent Node`_). + +However ESP-MESH also allows users to disable self-organizing behavior which will +allow users to define their own criteria for parent node selection, or to configure +nodes to have designated parent nodes (see the +:example:`Mesh Manual Networking Example`). + +Asynchronous Power-on Reset ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -**(1) Network Sleep** -**(2) Standalone Station** +ESP-MESH network building can be affected by the order in which nodes power-on. +If certain nodes within the network power-on asynchronously (i.e. separated by +several minutes), **the final structure of the network could differ from the ideal +case where all nodes are powered on synchronously**. Nodes that are delayed in +powering on will adhere to the following rules: -8. User Intervention Network (TO-DO) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -+-----------------------+---------------------------------------------------------------------------------------+ -| Function | Description | -+=======================+=======================================================================================+ -|Specifying the node |The user designates a node in the network as the root node, intermediate node or leaf | -|type |node. | -+-----------------------+---------------------------------------------------------------------------------------+ -|Specifying the parent |The user designates a parent node for a certain node. | -|type | | -+-----------------------+---------------------------------------------------------------------------------------+ -|Specifying the layer |The user designates the layer in which the above-mentioned node is to be located. | -+-----------------------+---------------------------------------------------------------------------------------+ +**Rule 1:** If a root node already exists in the network, the delayed node will +not attempt to elect a new root node, even if it has a stronger RSSI with the router. +The delayed node will instead join the network like any other idle node by connecting +with a preferred parent node. If the delayed node is the designated root node, +all other nodes in the network will remain idle until the delayed node powers-on. -How to Write a Mesh Application -------------------------------- +**Rule 2:** If a delayed node forms an upstream connection and becomes an intermediate +parent node, it may also become the new preferred parent of other nodes (i.e. being +a shallower node). This will cause the other nodes to switch their upstream connections +to connect with the delayed node (see `Parent Node Switching`_). -**ESP-MESH API Error Code** +**Rule 3:** If an idle node has a designated parent node which is delayed in powering-on, +the idle node will not attempt to form any upstream connections in the absence of +its designated parent node. The idle node will remain idle indefinitely until its +designated parent node powers-on. -We suggest that users regularly check the error code and add relevant handlers accordingly. +The following example demonstrates the effects of asynchronous power-on with regards +to network building. -ESP-MESH Programming Model --------------------------- - -**Software Stack is demonstrated below:** - -.. figure:: ../../_static/mesh_software_stack.png +.. figure:: ../../_static/mesh-asynchronous-power-on-example.png :align: center - :alt: ESP-MESH Software Stack + :alt: Diagram of Asynchronous Power On Example + :figclass: align-center - ESP-MESH Software Stack + Network Building with Asynchronous Power On Example -**System Events delivery is demonstrated below:** +**1.** Nodes A/C/D/F/G/H are powered-on synchronously and begin the root +node election process by broadcasting their MAC addresses and router RSSIs. Node +A is elected as the root node as it has the strongest RSSI. -.. figure:: ../../_static/mesh_events_delivery.png +**2.** Once node A becomes the root node, the remaining nodes begin forming upstream +connections layer by layer with their preferred parent nodes. The result is a network +with five layers. + +**3.** Node B/E are delayed in powering-on but neither attempt to become the root +node even though they have stronger router RSSIs (-20db and -10db) compared to +node A. Instead both delayed nodes form upstream connections with their preferred +parent nodes A and C respectively. Both Nodes B/E become intermediate parent nodes +after connecting. + +**4.** Nodes D/G switch their upstream connections as node B is the new preferred +parent node due to it being on a shallower layer (second layer node). Due to the +switch, the resultant network has three layers instead of the original five layers. + +**Synchronous Power-On:** Had all nodes powered-on synchronously, node E would +have become the root node as it has the strongest router RSSI (-10db). This +would result in a significantly different network layout compared to the network +formed under the conditions of asynchronous power-on. **However the synchronous +power-on network layout can still be reached if the user manually switches the +root node** (see :cpp:func:`esp_mesh_waive_root`). + +.. note:: + Differences in parent node selection caused by asynchronous power-on are + autonomously corrected for to some extent in ESP-MESH (see `Parent Node Switching`_) + +Loop-back Avoidance, Detection, and Handling +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A loop-back is the situation where a particular node forms an upstream connection +with one of its descendant nodes (a node within the particular node's subnetwork). +This results in a circular connection path thereby breaking the tree topology. +ESP-MESH prevents loop-back during parent selection by excluding nodes already +present in the selecting node's routing table (see `Routing Tables`_) thus prevents +a particular node from attempting to connect to any node within its subnetwork. + +In the event that a loop-back occurs, ESP-MESH utilizes a path verification +mechanism and energy transfer mechanism to detect the loop-back occurrence. The +parent node of the upstream connection that caused the loop-back will then inform +the child node of the loop-back and initiate a disconnection. + +.. -------------------------- Network Management ------------------------------ + +.. _mesh-managing-a-network: + +Managing a Network +------------------ + +**ESP-MESH is a self healing network meaning it can detect and correct for failures +in network routing**. Failures occur when a parent node with one or more child +nodes breaks down, or when the connection between a parent node and its child nodes +becomes unstable. Child nodes in ESP-MESH will autonomously select a new parent +node and form an upstream connection with it to maintain network interconnectivity. +ESP-MESH can handle both Root Node Failures and Intermediate Parent Node Failures. + +Root Node Failure +^^^^^^^^^^^^^^^^^ + +If the root node breaks down, the nodes connected with it (second layer nodes) +will promptly detect the failure of the root node. The second layer nodes +will initially attempt to reconnect with the root node. However after multiple failed +attempts, the second layer nodes will initialize a new round of root node election. +**The second layer node with the strongest router RSSI will be elected as the new +root node** whilst the remaining second layer nodes will form an upstream connection +with the new root node (or a neighboring parent node if not in range). + +If the root node and multiple downstream layers simultaneously break down (e.g. +root node, second layer, and third layer), the shallowest layer that is still +functioning will initialize the root node election. The following example illustrates +an example of self healing from a root node break down. + +.. figure:: ../../_static/mesh-root-node-failure.png :align: center - :alt: System Events Delivery + :alt: Diagram of Self Healing From Root Node Failure + :figclass: align-center - ESP-MESH System Events Delivery + Self Healing From Root Node Failure + +**1.** Node C is the root node of the network. Nodes A/B/D/E are second layer +nodes connected to node C. + +**2.** Node C breaks down. After multiple failed attempts to reconnect, the second +layer nodes begin the election process by broadcasting their router RSSIs. Node +B has the strongest router RSSI. + +**3.** Node B is elected as the root node and begins accepting downstream +connections. The remaining second layer nodes A/D/E form upstream connections with +node B thus the network is healed and can continue operating normally. + +.. note:: + If a designated root node breaks down, the remaining nodes **will not autonomously + attempt to elect a new root node** as an election process will never be attempted + whilst a designated root node is used. + +Intermediate Parent Node Failure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If an intermediate parent node breaks down, the disconnected child nodes will initially +attempt to reconnect with the parent node. After multiple failed attempts to reconnect, +each child node will begin to scan for potential parent nodes (see +`Beacon Frames & RSSI Thresholding`_). + +If other potential parent nodes are available, each child node will individually +select a new preferred parent node (see `Preferred Parent Node`_) and form an upstream +connection with it. If there are no other potential parent nodes for a particular +child node, it will remain idle indefinitely. + +The following diagram illustrates an example of self healing from an Intermediate +Parent Node break down. + +.. figure:: ../../_static/mesh-parent-node-failure.png + :align: center + :alt: Diagram of Self Healing From Intermediate Parent Node Failure + :figclass: align-center + + Self Healing From Intermediate Parent Node Failure + +**1.** The following branch of the network consists of nodes A to G. + +**2.** Node C breaks down. Nodes F/G detect the break down and attempt to +reconnect with node C. After multiple failed attempts to reconnect, nodes F/G begin +to select a new preferred parent node. + +**3.** Node G is out of range from any other parent node hence remains idle for +the time being. Node F is in range of nodes B/E, however node B is selected as +it is the shallower node. Node F becomes an intermediate parent node after +connecting with Node B thus node G can connect with node F. The network is healed, +however the network routing as been affected and an extra layer has been added. + +.. note:: + If a child node has a designated parent node that breaks down, the child node + will make no attempt to connect with a new parent node. The child node will + remain idle indefinitely. + +Root Node Switching +^^^^^^^^^^^^^^^^^^^ + +ESP-MESH does not automatically switch the root node unless the root node breaks down. Even +if the root node's router RSSI degrades to the point of disconnection, the root node +will remain unchanged. Root node switching is the act of explicitly starting +a new election such that a node with a stronger router RSSI will be elected as the +new root node. This can be a useful method of adapting to degrading root node performance. + +To trigger a root node switch, the current root node must explicitly call :cpp:func:`esp_mesh_waive_root` +to trigger a new election. The current root node will signal all nodes within +the network to begin transmitting and scanning for beacon frames (see `Automatic +Root Node Selection`_) **whilst remaining connected to the network (i.e. not idle)**. +If another node receives more votes than the current root node, a root node switch +will be initiated. **The root node will remain unchanged otherwise**. + +A newly elected root node sends a **switch request** to the current root node +which in turn will respond with an acknowledgment signifying both nodes are ready to +switch. Once the acknowledgment is received, the newly elected root node will +disconnect from its parent and promptly form an upstream connection with the router +thereby becoming the new root node of the network. The previous root node will +disconnect from the router **whilst maintaining all of its downstream connections** +and enter the idle state. The previous root node will then begin scanning for +potential parent nodes and selecting a preferred parent. + +The following diagram illustrates an example of a root node switch. + +.. figure:: ../../_static/mesh-root-node-switch-example.png + :align: center + :alt: Diagram of Root Node Switch Example + :figclass: align-center + + Root Node Switch Example + +**1.** Node C is the current root node but has degraded signal strength with the +router (-85db). The node C triggers a new election and all nodes begin transmitting +and scanning for beacon frames **whilst still being connected**. + +**2.** After multiple rounds of transmission and scanning, node B is elected as +the new root node. Node B sends node C a **switch request** and node C responds +with an acknowledgment. + +**3.** Node B disconnects from its parent and connects with the router becoming +the networks new root node. Node C disconnects from the router, enters the idle +state, and begins scanning for and selecting a new preferred parent node. **Node +C maintains all its downstream connections throughout this process**. + +**4.** Node C selects node B as its preferred parent node, forms an upstream +connection, and becomes a second layer node. The network layout is similar after +the switch as node C still maintains the same subnetwork. However each node in +node C's subnetwork has been placed one layer deeper as a result of the switch. +`Parent Node Switching`_ may adjust the network layout afterwards if any nodes have +a new preferred parent node as a result of the root node switch. + +.. note:: + Root node switching must require an election hence is only supported when using + a self-organized ESP-MESH network. In other words, root node switching cannot + occur if a designated root node is used. + +Parent Node Switching +^^^^^^^^^^^^^^^^^^^^^ + +Parent Node Switching entails a child node switching its upstream connection to +another parent node of a shallower layer. **Parent Node Switching occurs autonomously** +meaning that a child node will change its upstream connection automatically if a +potential parent node of a shallower layer becomes available (i.e. due to a +`Asynchronous Power-on Reset`_). + +All potential parent nodes periodically transmit beacon frames (see `Beacon Frames +& RSSI Thresholding`_) allowing for a child node to scan for the availability of +a shallower parent node. Due to parent node switching, a self-organized ESP-MESH +network can dynamically adjust its network layout to ensure each connection has a good +RSSI and that the number of layers in the network is minimized. + +.. --------------------------- Data Transmission ------------------------------ + +.. _mesh-data-transmission: + +Data Transmission +----------------- + +ESP-MESH Packet +^^^^^^^^^^^^^^^ + +ESP-MESH network data transmissions use ESP-MESH packets. ESP-MESH packets +are **entirely contained within the frame body of a Wi-Fi data frame**. A multi-hop +data transmission in an ESP-MESH network will involve a single ESP-MESH packet +being carried over each wireless hop by a different Wi-Fi data frame. + +The following diagram shows the structure of an ESP-MESH packet and its relation +with a Wi-Fi data frame. + +.. figure:: ../../_static/mesh-packet.png + :align: center + :alt: Diagram of ESP-MESH Packet + :figclass: align-center + + ESP-MESH Packet + +**The header** of an ESP-MESH packet contains the MAC addresses of the source and +destination nodes. The options field contains information pertaining to the special +types of ESP-MESH packets such as a group transmission or a packet originating +from the external IP network (see :c:macro:`MESH_OPT_SEND_GROUP` and +:c:macro:`MESH_OPT_RECV_DS_ADDR`). + +**The payload** of an ESP-MESH packet contains the actual application data. This +data can be raw binary data, or encoded under an application layer protocol such +as HTTP, MQTT, and JSON (see :cpp:type:`mesh_proto_t`). + +.. note:: + When sending an ESP-MESH packet to the external IP network, the destination + address field of the header will contain the IP address and port of the target server + rather than the MAC address of a node (see :cpp:type:`mesh_addr_t`). Furthermore + the root node will handle the formation of the outgoing TCP/IP packet. + +Group Control & Multicasting +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Multicasting is a feature that allows a single ESP-MESH packet to be transmitted +simultaneously to multiple nodes within the network. Multicasting in ESP-MESH can +be achieved by either specifying a list of target nodes, or specifying a preconfigured +group of nodes. Both methods of multicasting are called via :cpp:func:`esp_mesh_send`. + +To multicast by specifying a list of target nodes, users must first set the ESP-MESH +packet's destination address to the **Multicast-Group Address** (``01:00:5E:xx:xx:xx``). +This signifies that the ESP-MESH packet is a multicast packet with a group of addresses, +and that the address should be obtained from the header options. Users must then +list the MAC addresses of the target nodes as options (see :cpp:type:`mesh_opt_t` +and :c:macro:`MESH_OPT_SEND_GROUP`). This method of multicasting requires no prior +setup but can incur a large amount of overhead data as each target node's MAC address +must be listed in the options field of the header. + +Multicasting by group allows a ESP-MESH packet to be transmitted to a preconfigured +group of nodes. Each grouping is identified by a unique ID, and a node can be placed +into a group via :cpp:func:`esp_mesh_set_group_id`. Multicasting to a group involves +setting the destination address of the ESP-MESH packet to the target group ID. +Furthermore, the :c:macro:`MESH_DATA_GROUP` flag must set. Using groups to multicast +incurs less overhead, but requires nodes to previously added into groups. + +.. note:: + During a multicast, all nodes within the network still receive the ESP-MESH + packet on the MAC layer. However, nodes not included in the MAC address list + or the target group will simply filter out the packet. + +Broadcasting +^^^^^^^^^^^^ + +Broadcasting is a feature that allows a single ESP-MESH packet to be transmitted +simultaneously to all nodes within the network. Each node essentially forwards +a broadcast packet to all of its upstream and downstream connections such that +the packet propagates throughout the network as quickly as possible. However, +ESP-MESH utilizes the following methods to avoid wasting bandwidth during a broadcast. + +**1.** When an intermediate parent node receives a broadcast packet from its parent, +it will forward the packet to each of its child nodes whilst storing a copy of the +packet for itself. + +**2.** When an intermediate parent node is the source node of the broadcast, it +will transmit the broadcast packet upstream to is parent node and downstream to +each of its child nodes. + +**3.** When an intermediate parent node receives a broadcast packet from one of its +child nodes, it will forward the packet to its parent node and each of its remaining +child nodes whilst storing a copy of the packet for itself. + +**4.** When a leaf node is the source node of a broadcast, it will directly +transmit the packet to its parent node. + +**5.** When the root node is the source node of a broadcast, the root node will transmit +the packet to all of its child nodes. + +**6.** When the root node receives a broadcast packet from one of its child nodes, it +will forward the packet to each of its remaining child nodes whilst storing a copy +of the packet for itself. + +**7.** When a node receives a broadcast packet with a source address matching its +own MAC address, the node will discard the broadcast packet. + +**8.** When an intermediate parent node receives a broadcast packet from its parent +node which was originally transmitted from one of its child nodes, it will discard +the broadcast packet + +Upstream Flow Control +^^^^^^^^^^^^^^^^^^^^^ + +ESP-MESH relies on parent nodes to control the upstream data flow of their immediate +child nodes. To prevent a parent node's message buffer from overflowing due to an overload +of upstream transmissions, a parent node will allocate a quota for upstream transmissions +known as a **receiving window** for each of its child nodes. **Each child node must +apply for a receiving window before it is permitted to transmit upstream**. The size +of a receiving window can be dynamically adjusted. An upstream transmission from +a child node to the parent node consists of the following steps: + +**1.** Before each transmission, the child node sends a window request to its parent +node. The window request consists of a sequence number which corresponds to the child +node's data packet that is pending transmission. + +**2.** The parent node receives the window request and compares the sequence number +with the sequence number of the previous packet sent by the child node. The comparison +is used to calculate the size of the receiving window which is transmitted back +to the child node. + +**3.** The child node transmits the data packet in accordance with the window size +specified by the parent node. If the child node depletes its receiving window, it +must obtain another receiving windows by sending a request before it is permitted +to continue transmitting. + +.. note:: + ESP-MESH does not support any downstream flow control. + +.. warning:: + Due to `Parent Node Switching`_, packet loss may occur during upstream + transmissions. + +Due to the fact that the root node acts as the sole interface to an external IP +network, it is critical that downstream nodes are aware of the root node's connection +status with the external IP network. Failing to do so can lead to nodes attempting +to pass data upstream to the root node whilst it is disconnected from the IP network. +This results in unnecessary transmissions and packet loss. ESP-MESH address this +issue by providing a mechanism to stabilize the throughput of outgoing data based +on the connection status between the root node and the external IP network. The root +node can broadcast its external IP network connection status to all other nodes +by calling :cpp:func:`esp_mesh_post_toDS_state`. + +Bi-Directional Data Stream +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following diagram illustrates the various network layers involved in an ESP-MESH +Bidirectional Data Stream. + +.. figure:: ../../_static/mesh-bidirectional-data-stream.png + :align: center + :alt: Diagram of ESP-MESH Bidirectional Data Stream + :figclass: align-center + + ESP-MESH Bidirectional Data Stream + +Due to the use of `Routing Tables`_, **ESP-MESH is able to handle pack forwarding +entirely on the mesh layer**. A TCP/IP layer is only required on the root +node when it transmits/receives a packet to/from an external IP network. + +.. ------------------------------ Performance --------------------------------- + +.. _mesh-network-performance: + +Performance +----------- + +The performance of an ESP-MESH network can be evaluated based on multiple metrics +such as the following: + +**Network Building Time:** The amount of time taken to build an ESP-MESH network from +scratch. + +**Healing Time:** The amount of time taken for the network to detect a node break +down and carry out appropriate actions to heal the network (such as generating a +new root node or forming new connections). + +**Per-hop latency:** The latency of data transmission over one wireless hop. In +other words, the time taken to transmit a data packet from a parent node to a +child node or vice versa. + +**Network Node Capacity:** The total number of nodes the ESP-MESH network can simultaneously +support. This number is determined by the maximum number of downstream connections +a node can accept and the maximum number of layers permissible in the network. + +The following table lists the common performance figures of an ESP-MESH network. +However users should note that performance numbers can vary greatly between +installations based on network configuration and operating environment. + ++-------------------------+------------------------------------+ +| Function | Description | ++=========================+====================================+ +|Networking Building Time | < 60 seconds | ++-------------------------+------------------------------------+ +|Healing time | Root Node Break Down: < 10 seconds | +| | | +| | Child Node Break Down: < 5 seconds | ++-------------------------+------------------------------------+ +|Per-hop latency | 10 to 30 milliseconds | ++-------------------------+------------------------------------+ + +.. note:: + The following test conditions were used to generate the performance figures + above. + + - Number of test devices: **100** + - Maximum Downstream Connections to Accept: **6** + - Maximum Permissible Layers: **6** + +.. note:: + Throughput depends on packet error rate and hop count. + +.. note:: + The throughput of root node's access to the external IP network is directly + affected by the number of nodes in the ESP-MESH network and the bandwidth of + the router. + +.. ----------------------------- Further Notes -------------------------------- + +.. _mesh-further-notes: + +Further Notes +------------- + +- Data transmission uses Wi-Fi WPA2-PSK encryption + +- Mesh networking IE uses AES encryption -ESP-MESH events define almost all system events for any application tasks needed. The events include the Wi-Fi connection status of the station interface, the connection status of child nodes on the softAP interface, and the like. Firstly, application tasks need to register a mesh event callback handler via the API :cpp:func:`esp_mesh_set_config`. This handler is used for receiving events posted from the mesh stack and the LwIP stack. Application tasks can add relevant handlers to each event. - -**Examples:** - -(1) Application tasks can use Wi-Fi station connect statuses to determine when to send data to a parent node, to a root node or to external IP network. -(2) Application tasks can use Wi-Fi softAP statuses to determine when to send data to child nodes. - -Application tasks can access the mesh stack directly without having to go through the LwIP stack. The LwIP stack is not necessery for non-root nodes. -:cpp:func:`esp_mesh_send` and :cpp:func:`esp_mesh_recv` are used in the application tasks to send and receive messages over the mesh network. - -**Notes:** - -Since current ESP-IDF does not support system initializing without calling :cpp:func:`tcpip_adapter_init`, application tasks still need to perform the LwIP initialization and do remember firstly -1. stoping the DHCP server service on the softAP interface -2. stoping the DHCP client service on the station interface. - -Code Example: - -:cpp:func:`tcpip_adapter_init`; - -:cpp:func:`tcpip_adapter_dhcps_stop`; - -:cpp:func:`tcpip_adapter_dhcpc_stop`; - -The root node is connected with a router. Thus, in the application mesh event handler, once a node becomes the root, the DHCP client service must be started immediately to obtain IP address unless static IP settings is used. +Router and internet icon made by `Smashicons `_ from `www.flaticon.com `_ \ No newline at end of file diff --git a/docs/en/api-reference/mesh/esp_mesh.rst b/docs/en/api-reference/mesh/esp_mesh.rst index d22e86d67..2d5349c5e 100644 --- a/docs/en/api-reference/mesh/esp_mesh.rst +++ b/docs/en/api-reference/mesh/esp_mesh.rst @@ -1,11 +1,266 @@ -Mesh -===== +ESP-MESH Programming Guide +========================== + +This is a programming guide for ESP-MESH, including the API reference and coding +examples. This guide is split into the following parts: + +1. :ref:`mesh-programming-model` + +2. :ref:`mesh-writing-mesh-application` + +3. :ref:`mesh-application-examples` + +4. :ref:`mesh-api-reference` + +For documentation regarding the ESP-MESH protocol, please see the +:doc:`ESP-MESH API Guide<../../api-guides/mesh>`. + + +.. ---------------------- ESP-MESH Programming Model -------------------------- + +.. _mesh-programming-model: + +ESP-MESH Programming Model +-------------------------- + +Software Stack +^^^^^^^^^^^^^^ + +The ESP-MESH software stack is built atop the Wi-Fi Driver/FreeRTOS and may use +the LwIP Stack in some instances (i.e. the root node). The following diagram +illustrates the ESP-MESH software stack. + +.. _mesh-going-to-software-stack: + +.. figure:: ../../../_static/mesh-software-stack.png + :align: center + :alt: ESP-MESH Software Stack + :figclass: align-center + + ESP-MESH Software Stack + +System Events +^^^^^^^^^^^^^ + +An application interfaces with ESP-MESH via **ESP-MESH Events**. Since ESP-MESH +is built atop the Wi-Fi stack, it is also possible for the application to interface +with the Wi-Fi driver via the **Wi-Fi Event Task**. The following diagram illustrates +the interfaces for the various System Events in an ESP-MESH application. + +.. figure:: ../../../_static/mesh-events-delivery.png + :align: center + :alt: ESP-MESH System Events Delivery + :figclass: align-center + + ESP-MESH System Events Delivery + +The :cpp:type:`mesh_event_id_t` defines all possible ESP-MESH system events and +can indicate events such as the connection/disconnection of parent/child. Before +ESP-MESH system events can be used, the application must register a **Mesh Event +Callback** via :cpp:func:`esp_mesh_set_config`. The callback is used to receive +events from the ESP-MESH stack as well as the LwIP Stack and should contain handlers +for each event relevant to the application. + +Typical use cases of system events include using events such as +:cpp:enumerator:`MESH_EVENT_PARENT_CONNECTED` and :cpp:enumerator:`MESH_EVENT_CHILD_CONNECTED` +to indicate when a node can begin transmitting data upstream and downstream respectively. Likewise, +:cpp:enumerator:`MESH_EVENT_ROOT_GOT_IP` and :cpp:enumerator:`MESH_EVENT_ROOT_LOST_IP` can be +used to indicate when the root node can and cannot transmit data to the external IP +network. + +.. warning:: + When using ESP-MESH under self-organized mode, users must ensure that no calls + to Wi-Fi API are made. This is due to the fact that the self-organizing mode + will internally make Wi-Fi API calls to connect/disconnect/scan etc. + **Any Wi-Fi calls from the application (including calls from callbacks and + handlers of Wi-Fi events) may interfere with ESP-MESH's self-organizing behavior**. + Therefore, user's should not call Wi-Fi APIs after :cpp:func:`esp_mesh_start` + is called, and before :cpp:func:`esp_mesh_stop` is called. + +LwIP & ESP-MESH +^^^^^^^^^^^^^^^ + +The application can access the ESP-MESH stack directly without having to go through +the LwIP stack. The LwIP stack is only required by the root node to transmit/receive +data to/from an external IP network. However, since every node can potentially +become the root node (due to automatic root node selection), each node must still +initialize the LwIP stack. + +**Each node is required to initialize LwIP by calling** :cpp:func:`tcpip_adapter_init`. +In order to prevent non-root node access to LwIP, the application should stop the +following services after LwIP initialization: + + - DHCP server service on the softAP interface. + - DHCP client service on the station interface. + +The following code snippet demonstrates how to initialize LwIP for ESP-MESH applications. + +.. code-block:: c + + /* tcpip initialization */ + tcpip_adapter_init(); + /* + * for mesh + * stop DHCP server on softAP interface by default + * stop DHCP client on station interface by default + */ + ESP_ERROR_CHECK(tcpip_adapter_dhcps_stop(TCPIP_ADAPTER_IF_AP)); + ESP_ERROR_CHECK(tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA)); + /* do not specify system event callback, use NULL instead. */ + ESP_ERROR_CHECK(esp_event_loop_init(NULL, NULL)); + +.. note:: + + ESP-MESH requires a root node to be connected with a router. Therefore, in + the event that a node becomes the root, **the corresponding handler must start + the DHCP client service and immediately obtain an IP address**. Doing so will + allow other nodes to begin transmitting/receiving packets to/from the external + IP network. However, this step is unnecessary if static IP settings are used. + + +.. ---------------------- Writing a Mesh Application -------------------------- + +.. _mesh-writing-mesh-application: + +Writing an ESP-MESH Application +------------------------------- + +The prerequisites for starting ESP-MESH is to initialize LwIP and Wi-Fi, The +following code snippet demonstrates the necessary prerequisite steps before +ESP-MESH itself can be initialized. + +.. code-block:: c + + tcpip_adapter_init(); + /* + * for mesh + * stop DHCP server on softAP interface by default + * stop DHCP client on station interface by default + */ + ESP_ERROR_CHECK(tcpip_adapter_dhcps_stop(TCPIP_ADAPTER_IF_AP)); + ESP_ERROR_CHECK(tcpip_adapter_dhcpc_stop(TCPIP_ADAPTER_IF_STA)); + /* do not specify system event callback, use NULL instead. */ + ESP_ERROR_CHECK(esp_event_loop_init(NULL, NULL)); + + /* Wi-Fi initialization */ + wifi_init_config_t config = WIFI_INIT_CONFIG_DEFAULT(); + ESP_ERROR_CHECK(esp_wifi_init(&config)); + ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_FLASH)); + ESP_ERROR_CHECK(esp_wifi_start()); + +After initializing LwIP and Wi-Fi, the process of getting an ESP-MESH network +up and running can be summarized into the following three steps: + +1. :ref:`mesh-initialize-mesh` +2. :ref:`mesh-configuring-mesh` +3. :ref:`mesh-start-mesh` + +.. _mesh-initialize-mesh: + +Initialize Mesh +^^^^^^^^^^^^^^^ + +The following code snippet demonstrates how to initialize ESP-MESH + +.. code-block:: c + + /* mesh initialization */ + ESP_ERROR_CHECK(esp_mesh_init()); + +.. _mesh-configuring-mesh: + +Configuring an ESP-MESH Network +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. todo - Add note about unified configuration + +ESP-MESH is configured via :cpp:func:`esp_mesh_set_config` which receives its arguments +using the :cpp:type:`mesh_cfg_t` structure. The structure contains the following +parameters used to configure ESP-MESH: + ++------------------+-------------------------------------+ +| Parameter | Description | ++==================+=====================================+ +| Channel | Range from 1 to 14 | ++------------------+-------------------------------------+ +| Event Callback | Callback for Mesh Events, | +| | see :cpp:type:`mesh_event_cb_t` | ++------------------+-------------------------------------+ +| Mesh ID | ID of ESP-MESH Network, | +| | see :cpp:type:`mesh_addr_t` | ++------------------+-------------------------------------+ +| Router | Router Configuration, | +| | see :cpp:type:`mesh_router_t` | ++------------------+-------------------------------------+ +| Mesh AP | Mesh AP Configuration, | +| | see :cpp:type:`mesh_ap_cfg_t` | ++------------------+-------------------------------------+ +| Crypto Functions | Crypto Functions for Mesh IE, | +| | see :cpp:type:`mesh_crypto_funcs_t` | ++------------------+-------------------------------------+ + +The following code snippet demonstrates how to configure ESP-MESH. + +.. code-block:: c + + /* Enable the Mesh IE encryption by default */ + mesh_cfg_t cfg = MESH_INIT_CONFIG_DEFAULT(); + /* mesh ID */ + memcpy((uint8_t *) &cfg.mesh_id, MESH_ID, 6); + /* mesh event callback */ + cfg.event_cb = &mesh_event_handler; + /* channel (must match the router's channel) */ + cfg.channel = CONFIG_MESH_CHANNEL; + /* router */ + cfg.router.ssid_len = strlen(CONFIG_MESH_ROUTER_SSID); + memcpy((uint8_t *) &cfg.router.ssid, CONFIG_MESH_ROUTER_SSID, cfg.router.ssid_len); + memcpy((uint8_t *) &cfg.router.password, CONFIG_MESH_ROUTER_PASSWD, + strlen(CONFIG_MESH_ROUTER_PASSWD)); + /* mesh softAP */ + cfg.mesh_ap.max_connection = CONFIG_MESH_AP_CONNECTIONS; + memcpy((uint8_t *) &cfg.mesh_ap.password, CONFIG_MESH_AP_PASSWD, + strlen(CONFIG_MESH_AP_PASSWD)); + ESP_ERROR_CHECK(esp_mesh_set_config(&cfg)); + +.. _mesh-start-mesh: + +Start Mesh +^^^^^^^^^^ + +The following code snippet demonstrates how to start ESP-MESH. + +.. code-block:: c + + /* mesh start */ + ESP_ERROR_CHECK(esp_mesh_start()); + +After starting ESP-MESH, the application should check for ESP-MESH events to determine +when it has connected to the network. After connecting, the application can start +transmitting and receiving packets over the ESP-MESH network using +:cpp:func:`esp_mesh_send` and :cpp:func:`esp_mesh_recv`. + +.. --------------------- ESP-MESH Application Examples ------------------------ + +.. _mesh-application-examples: Application Examples -------------------- -See :example:`mesh` directory of ESP-IDF examples that contains the following applications. +ESP-IDF contains these ESP-MESH example projects: +:example:`The Internal Communication Example` demonstrates +how to setup a ESP-MESH network and have the root node send a data packet to +every node within the network. + +:example:`The Manual Networking Example` demonstrates +how to use ESP-MESH without the self-organizing features. This example shows how +to program a node to manually scan for a list of potential parent nodes and select +a parent node based on custom criteria. + + +.. ------------------------- ESP-MESH API Reference --------------------------- + +.. _mesh-api-reference: API Reference -------------- diff --git a/docs/zh_CN/api-guides/index.rst b/docs/zh_CN/api-guides/index.rst index 0a0f9c8e9..dd3dfeb2c 100644 --- a/docs/zh_CN/api-guides/index.rst +++ b/docs/zh_CN/api-guides/index.rst @@ -25,6 +25,6 @@ API Guides Console Component ROM debug console WiFi Driver - Mesh Stack + ESP-MESH BluFi External SPI-connected RAM