Before diving into message flow, you need to know the layers. Think of them like floors in a building — a message enters from the ground floor (Bearer) and walks up to the top floor (Application/Model).

When a message is received, it flows bottom-up — from Bearer → Network → Transport → Access → Model.
When a message is sent, it flows top-down — from Model → Access → Transport → Network → Bearer.

2.1 Bearer Layer

The Bearer layer is the physical entry point. In practice, there are two bearers:

• Advertising Bearer (ADV) — uses standard BLE advertising packets. Most mesh nodes use this.
• GATT Bearer — used by phones or tablets that can’t do raw advertising but can connect via GATT (like a provisioning app).

A packet arrives at the bearer and passes through an interface input filter. The filter decides: is this a Mesh Message, a Mesh Beacon, or a Bearer Control message? Each goes on a different path.

2.2 Network Layer

Once past the bearer, the network layer takes over. Here’s what happens step by step:

TTL (Time To Live) is the mesh equivalent of IP’s hop count. Every relay node decrements TTL by 1. When TTL drops below 2, the packet is dropped — this prevents infinite forwarding loops in the mesh.

2.3 Lower Transport Layer — SAR

Mesh PDUs are small (max ~15 bytes of application data in a single segment). If your message is bigger, the Lower Transport layer splits it using SAR — Segmentation and Reassembly.

If a node has a Friend node, messages destined for a low-power node (LPN) get queued in the Friend’s queue instead of being broadcast immediately. The LPN wakes up, sends a Friend Poll, and the Friend node delivers queued messages.

3.1 Upper Transport Layer

After SAR reassembly, the Upper Transport layer does two important things:

• Transport Decryption — uses the AppKey (for application messages) or the DevKey (for configuration messages) to decrypt the payload.
• Replay Protection — checks the sequence number. If this sequence number was seen before, the message is dropped. This blocks replay attacks.

3.2 Access Layer

The access layer is the gatekeeper before your application model sees data. Three checks happen here:

3.3 Node-level vs Element-level Access Processing

A mesh node can have multiple elements (think of each element as an addressable endpoint — a single bulb in a fixture). Here’s how the access layer routes to the right element:

3.4 Foundation Model vs Application Model

Once the opcode is parsed, the message goes to either:

• Foundation Model — handles network configuration messages (add/remove AppKeys, set subscriptions, set publication). These are sent using the DevKey, not AppKey.
• Application Model — your actual application logic (Generic OnOff, Light Lightness, Sensor, Vendor models, etc.).

Foundation Models are built-in models that every mesh node must support. They are the remote control for the network itself. A Provisioner (like a phone app) uses them to set up a node after provisioning.

4.1 Two Foundation Models

4.2 Log Field Transformation

Foundation models often use small 1-byte fields to represent large 2-byte values. They use a logarithmic compression: the 1-byte log field stores the value n such that 2^(n-1) ≤ actual value.

For example, a Publish Period of 320ms (0x0140) can’t fit in one byte. But log field value 0x09 means “the value is somewhere between 0x0100 and 0x01FF” — good enough for period encoding.

BlueZ includes a mesh daemon (bluetooth-meshd) and a test tool (mesh-cfgclient). Here’s how to observe and interact with mesh message flow on Linux.

5.1 Start the Mesh Daemon

# Start bluetoothd first (if not already running)
sudo bluetoothd -d &

# Start the mesh daemon with debug output
sudo bluetooth-meshd --debug

# You will see lines like:
# mesh/net.c: Network authenticate & decrypt
# mesh/transport.c: Upper transport decrypt
# mesh/access.c: Replay protection check

5.2 Provision a Node using mesh-cfgclient

# Run the interactive config client
mesh-cfgclient

# Inside the client shell:

# Discover unprovisioned beacons
discover-unprovisioned on

# Start provisioning (replace UUID with your device's UUID)
provision 0011223344556677889900aabbccddeeff

# After provisioning completes, you get a unicast address (e.g., 0x0002)
# Now you can configure the node's Foundation Model (Config Server)

5.3 Add AppKey to a Node (Foundation Model: Config AppKey Add)

# Still inside mesh-cfgclient shell
# Target node address 0x0002, NetKey index 0, AppKey index 0
appkey-add 0x0002 0 0

# This sends a "Config AppKey Add" message to the Config Server
# on the target node using that node's DevKey for encryption.
# On success you get: AppKey Add Status: Success

5.4 Bind AppKey to a Model on the Node

# Bind AppKey 0 to the Generic OnOff Server model (Model ID: 0x1000)
# on element 0 of node 0x0002
bind 0x0002 0 0x1000 0

# This sends Config Model App Bind message
# On success: Model App Bind Status: Success

5.5 Set a Subscription (Group Address)

# Subscribe element 0, model 0x1000 on node 0x0002
# to group address 0xC000
sub-add 0x0002 0 0xC000 0x1000

# Now if you send a Generic OnOff Set to group 0xC000,
# this node will receive and process it.
# This is how you control multiple lights with one command.

5.6 Watching TTL and Relay in Action (btmon)

# In a separate terminal, run btmon to see raw HCI/ADV packets
sudo btmon

# Look for Mesh ADV packets. You will see the same PDU
# appearing multiple times as relay nodes forward it,
# each time with TTL decremented by 1.

# Example output snippet:
# HCI Event: LE Meta (0x3e) plen 43
#   LE Advertising Report (0x02)
#   Type: Non connectable undirected (0x03)
#   Data length: 29
#   Mesh Message (type 0x2a)
#   ...

5.7 Python: Send a Generic OnOff Set via BlueZ D-Bus Mesh API

import dbus

# Connect to the BlueZ mesh application over D-Bus
bus = dbus.SystemBus()

# Get the mesh network manager
mesh_mgr = dbus.Interface(
    bus.get_object("org.bluez.mesh", "/org/bluez/mesh"),
    "org.bluez.mesh.Network1"
)

# Send message to group address 0xC000 (all lights)
# AppKey index 0, TTL 5
# Generic OnOff Set: Opcode 0x8202, OnOff=1 (ON), TID=0x01
app_key_index = 0
destination   = 0xC000
ttl           = 5
payload       = bytes([0x82, 0x02, 0x01, 0x01])  # GenOnOff Set ON

# Call Send on your model's element interface
element = dbus.Interface(
    bus.get_object("org.bluez.mesh", "/my/app/element0"),
    "org.bluez.mesh.Element1"
)
element.Send(destination, app_key_index, payload)

print("Generic OnOff SET (ON) sent to group 0xC000")