When an LPN wants a friend, it broadcasts a Friend Request message to the whole mesh. Any nearby Friend-capable node hears this and can reply with a Friend Offer.

Multiple Friend nodes may reply — the LPN picks the best one (based on signal strength and receive window size) and sends a Friend Poll directly to that chosen node. The Friend node responds with a Friend Update, and the friendship is now officially established.

Friendship Establishment Flow:

Once friendship is established, the Friend node creates an empty Friend Subscription List and starts storing incoming messages for the LPN in the Friend Queue.

The LPN wakes up periodically and sends a Friend Poll message to ask: “Do you have anything for me?” The Friend node replies with the oldest message in the queue.

The LPN uses a Friend Sequence Number (FSN) bit in the Poll message to confirm receipt. If the FSN value is the same as the previous Poll, it means the LPN didn’t get the last message — the Friend re-sends it. If the FSN changes, the Friend knows the LPN got it and sends the next message.

FSN Logic — What the Friend Does:

The Friend must reply within a window: ReceiveDelay ≤ reply time ≤ (ReceiveDelay + ReceiveWindow). This gives the LPN a predictable wakeup window — it can go to sleep right after the window closes.

Response Timing Window:

Important note: Messages in the Friend Queue are sent unchanged — even if the IV Index (network security index) has changed on the Friend node. The LPN must poll at least once every 96 hours, or the Friend may discard queued messages.

A friendship has a PollTimeout timer on the Friend node side. Every time the Friend receives a Friend Poll, a Friend Subscription List Add, or a Friend Subscription List Remove message from the LPN, the timer resets.

If the LPN goes silent — doesn’t send any of those messages — and the PollTimeout timer expires, the Friend node:

• Terminates the friendship
• Discards everything in the Friend Queue

Friendship Termination by PollTimeout:

The Friend also terminates the friendship immediately if it receives a Friend Clear message — this happens when the LPN has moved on and found a new Friend (see next section).

When an LPN drops its old Friend and establishes a friendship with a new one, the new Friend must notify the old Friend to clean up. This is done using a Friend Clear message.

The new Friend knows about the previous Friend because the LPN includes the old Friend’s address in the PreviousAddress field of the Friend Request message.

Friend Clear Procedure — Step by Step:

Friend Clear Retry with Exponential Backoff:

By default, the Friend only stores messages addressed directly to the LPN’s unicast address. But what if the LPN also wants messages sent to a group address (like “all lights” or “all sensors”)?

The LPN sends a Friend Subscription List Add message telling the Friend: “Also buffer messages sent to these group addresses for me.” The Friend adds them to the Friend Subscription List and replies with a Friend Subscription List Confirm.

Similarly, the LPN can send Friend Subscription List Remove to stop buffering messages for a particular group address.

Subscription List Update Flow:

BlueZ supports Bluetooth Mesh via the bluetooth-meshd daemon. You interact with it through D-Bus or the bluetoothctl / mesh-cfgclient tools. Below are practical examples.

1. Check if mesh daemon is running:

sudo systemctl status bluetooth-meshd

# Start it if not running
sudo systemctl start bluetooth-meshd
sudo systemctl enable bluetooth-meshd

2. Join a mesh network and provision a node:

# Start mesh-cfgclient (BlueZ mesh configuration client)
mesh-cfgclient

# Inside the tool — discover unprovisioned devices
discover-unprovisioned on

# Provision a device (UUID shown in scan results)
provision <device-UUID>

3. Get feature information from a node (including Friend/LPN support):

# Inside mesh-cfgclient — get composition data (includes feature flags)
composition-get <node-unicast-address> 0

# Feature flags in Composition Data Page 0:
# Bit 0 = Relay
# Bit 1 = Proxy
# Bit 2 = Friend       <-- Friend feature supported
# Bit 3 = Low Power    <-- LPN feature supported

4. Enable the Friend feature on a node via config model:

# Set Friend feature ON (1 = enable, 0 = disable)
# Uses Configuration Friend Set message
friend-set <node-unicast-address> 1

# Verify Friend state
friend-get <node-unicast-address>

5. D-Bus — interact with mesh node programmatically (Python example):

import dbus

# Connect to the system bus
bus = dbus.SystemBus()

# Get the mesh management interface
mesh_obj = bus.get_object(
    'org.bluez.mesh',
    '/org/bluez/mesh'
)
manager = dbus.Interface(mesh_obj, 'org.bluez.mesh.Network1')

# Attach to an existing mesh network node
# token is a 64-bit value returned at provisioning time
token = dbus.UInt64(0x1234567890ABCDEF)
manager.Attach('/org/example/mesh_app', token)

6. Monitor Friend/LPN messages using btmon:

# btmon captures all HCI events — mesh PDUs go over HCI as LE advertising
sudo btmon -w mesh_capture.btsnoop

# In another terminal, run your mesh application
# Then open the .btsnoop file in Wireshark for full mesh dissection

# Alternatively, filter mesh ADV packets live:
sudo btmon | grep -A5 "ADV_NONCONN_IND"

7. Check PollTimeout value on a Friend node (Config model):

# LPN Poll Timeout Get — asks Friend what timeout is configured for a given LPN
# inside mesh-cfgclient:
lpn-poll-timeout-get <friend-node-address> <lpn-unicast-address>

# Expected response includes PollTimeout in 100ms units
# e.g. value 0x000320 = 800 units × 100ms = 80 seconds