Mesh networking

What is a relay node?

A relay node is a device in a mesh network that receives messages addressed to other devices and retransmits them, so a message can reach a destination beyond the sender's radio range. Relaying is usually a role a device can switch on or off, because it costs the relay airtime and energy for traffic that is not its own.

Learning objectives

After reading this article you will be able to:

  • Describe the checks a relay node makes before forwarding a message
  • Identify which devices make good relays by power, position, availability and stability
  • Explain what a relay can still see when messages are end-to-end encrypted

What a relay does

In a mesh network, most messages cannot go straight from sender to recipient because the two are out of each other’s radio range. They travel in hops, and each device in the middle is a relay: it receives a message that is not addressed to it and sends it on.

For each message it hears, a relay makes a small decision:

  1. Is it for me? If so, deliver it locally. Some messages, such as group or broadcast messages, are for this device and others too, so it delivers and may still forward.
  2. Have I already handled it? If the message’s identifier is in the relay’s recent cache, drop it. See how mesh networks avoid duplicate messages.
  3. Is it allowed to go further? If its hop limit has run out, stop.
  4. Am I a useful next step? In a routed mesh, the relay checks whether it lies on a path towards the destination. In a flooded mesh, it simply rebroadcasts.
  5. Send it on, with the hop limit lowered by one.

Relaying as a role

In many mesh designs, relaying is a feature a device may have and may switch on or off, not something every node must do.

Bluetooth Mesh is explicit about this. The Relay feature is one of four optional node features, alongside Proxy, Friend and Low Power. The Bluetooth SIG glossary defines it as the ability to receive and retransmit mesh messages “to enable larger networks”, and a node that supports it and has it enabled is a Relay node. A node without it can still send and receive; it just does not carry anyone else’s traffic.

IETF mesh routing protocols choose relays dynamically. In OLSR (RFC 3626), each node picks a set of neighbours called multipoint relays, chosen so that together they reach every node two hops away. Only those neighbours rebroadcast its flooded messages; the rest receive and process them but do not retransmit. RFC 6621, which applies the same idea to forwarding data, calls this a reduced relay set, and expects it to be recalculated by distributed algorithms as neighbours come and go.

The reason for choosing is efficiency. If every device in a crowded room relays everything, most transmissions reach devices that already have the message.

Which devices should relay

A relay spends three things on other people’s traffic: radio airtime, energy, and a little memory for caches and queues. That makes some devices better relays than others.

  • Power source. RFC 2501 notes that in mobile ad hoc networks some or all nodes may run on batteries, and that for them energy conservation may be the most important design criterion. Bluetooth Mesh pairs battery-powered Low Power nodes with a Friend node that is “not power-constrained”, which stores messages for them until they wake and ask.
  • Position. A device that links two otherwise separate groups is far more useful as a relay than one in the middle of a dense cluster.
  • Availability. A device that sleeps for long periods, or whose app is often suspended, makes routes through it unreliable. RFC 2501 lists support for such sleep periods as a desirable property of routing protocols.
  • Stability. A device that stays in place keeps routes valid for longer than one that is moving quickly through the network.

Software meshes can apply these rules automatically. As one example, the Offline Protocol mesh SDK sets relay participation with a relayPriority of never, auto or always, and documents a relay battery threshold of 30% as the default in v0.27.0.

What a relay can see

A relay handles every message it forwards, so what it can read depends on how messages are protected.

Bluetooth Mesh separates the two with different keys. Relays hold the network key, which lets them authenticate and process a message at the network layer so they can relay it. Application data is encrypted with separate application keys, so, as the Bluetooth SIG primer puts it, a light relaying messages for a building’s security system “has no justifiable reason” to read them and cannot.

The same principle applies to any mesh: with end-to-end encryption, a relay carries ciphertext plus the routing details it needs, such as the destination, the hop limit and the message identifier. Those details are still visible, so a relay can learn who is talking to whom and how often, even when it cannot read what they say.

A relay node is not a relay server

The word relay also describes servers on the internet that pass messages between devices that cannot reach each other directly. A relay server is fixed infrastructure that every participant connects to. A relay node is one of the participants, lending its radio to its neighbours. Many systems use both: relay nodes for nearby devices, and a relay server when a device has an internet connection and the recipient is far away.

Frequently asked questions

Can a relay node read the messages it forwards?

It depends on the encryption. If messages are encrypted end to end, a relay sees only the routing information it needs and ciphertext it cannot read. If they are protected only on each link, every relay can read them.

Should every device in a mesh relay?

Not necessarily. In a dense network, a few well-placed relays reach everyone and the rest only add copies and collisions. Battery-powered or sleeping devices are often left out of relaying altogether.

Sources

Build it with Offline Protocol

The transports and routing API reference covers the mesh SDK calls for setting a device's relay priority, reporting battery level and charging state, and checking whether the device is currently relaying.

Read the transports and routing API