Bluetooth mesh uses the concept of a flood network. In a flood network, each incoming packet received by a node in the mesh is sent through every outgoing link, except the link to the parent of the message. Flooding has the advantage that if a packet can be delivered, it will be delivered (albeit probably many times via many routes). It will automatically find the shortest route (which can vary by signal quality and distance in a dynamic mesh). The algorithm is the simplest to implement as far as routing protocols are concerned. Additionally, it requires no central manager such as a Wi-Fi network based around a central router. For comparison, the alternate types of mesh routing include tree-based algorithms. With tree algorithms (or cluster-tree algorithms), a coordinator is necessary to instantiate the network and becomes the parent node. Trees aren't necessarily true mesh networks, however. Other mesh routing protocols include proactive routing, which keeps up-to-date routing tables on each node, and reactive routing, which only updates routing tables on each node on demand; for example, when data needs to be sent through a node. Zigbee (covered later) is a form of proactive routing called an Ad Hoc On-Demand Distance Vector (AODV). The following figure illustrates a flood broadcast. The time arrival at each level can vary dynamically from node to node. Additionally, the mesh network must be resilient to duplicate messages arriving at any node as in the case of node 7 and node D. 

The main disadvantage with a flood network is bandwidth waste. Depending on the fan out from each node, the congestion on a Bluetooth mesh can be significant. Another issue is a denial-of-service attack. If the mesh simply fans out messages, a facility is needed to know when to stop transmissions. Bluetooth accomplishes this through time-to-live identifiers, which we will cover later.

The nodes in a Bluetooth mesh include the following:

• Nodes: These are Bluetooth devices that have been previously provisioned and are members of a mesh.
• Unprovisioned devices: These are devices with the potential to join a mesh fabric that is not yet part of a mesh and has not been provisioned. 
• Elements: A node with multiple constituent parts. Each part can be independently controlled and addressed. An example could be a Bluetooth node with temperature, humidity, and lumens sensors. This would be a single node (sensor) with three elements.
• Mesh gateway: A node that can translate messages between the mesh and a non-Bluetooth technology. 

Once provisioned, a node may support an optional set of features, which include:

• Relay: A node that supports relay is termed a relay node and can retransmit messages received. 
• Proxy: Allows for Bluetooth LE devices that do not support Bluetooth mesh natively to interact with nodes on the mesh. This is performed using a proxy node. The proxy exposes a GATT interface with the legacy Bluetooth device, and a proxy protocol based on a connection-oriented bearer is defined. The legacy device reads and writes to the GATT proxy protocol and the proxy node transforms the messages into true mesh PDUs.
• Low power: Some nodes on the mesh need to obtain extremely low levels of power consumption. They may serve up environmental sensor information (such as temperature) once an hour and be configured by a host or cloud managed tool once a year. That type of device cannot be placed in a listening mode when a message will only arrive once a year. The node enters a role termed the low power node (LPN), which pairs it with a friend node. The LPN enters a deep sleep state and polls the associated friend for any messages that may have arrived while it was sleeping. 
• Friend: The friend node is associated with the LPN but is not necessarily power constrained like an LPN. A friend may use a dedicated circuit or wall power. The friend's duty is to store and buffer messages destined for the LPN until the LPN wakes and polls it for messages. Many messages may be stored and the friend will transmit them in order using a more data (MD) flag.

The following diagram illustrates a Bluetooth mesh topology with the various components as they would be associated with one another in a real mesh. 

A Bluetooth mesh will cache messages on each node; this is crucial in a flood network. As the same message may arrive at different times from different sources, the cache provides a lookup of recent messages received and processed. If the new message is identical to one in the cache, it is discarded. This ensures system idempotence. 

Each message carries a time-to-live field (TTL). If a message is received by a node and then re-transmitted, the TTL is decremented by one. This is a safety mechanism to prevent endless loops, and networks create amplifying denial-of-service attacks internal to the mesh. 

A heartbeat message is broadcast periodically from each node to the mesh. The heartbeat informs the fabric that the node is still present and healthy. It also allows the mesh to know how far away the node is and if it has changed distance since the last heartbeat. Essentially, it is counting the number of hops to reach the node. This process allows the mesh to re-organize and self-heal.