Feature, IoT/Smart Lighting, Lighting Controls

Nodes, heartbeats, friendship…Bluetooth jargon explained

Don’t know your cache from your element? Let our special pre-LuxLive jargon buster get up up to speed so that you can talk Bluetooth mesh like a pro come November…

YOU’RE GOING to start hearing an awful lot more about Bluetooth mesh in the lighting industry – not least at the tech fest which is LuxLive 2019 in London this November. So, to help you talk Bluetooth like a pro, we’ve compiled the ultimate Bluetooth jargon buster.




Devices such as luminaires, nodes, elements and provisioning devices which are part of a mesh network are called nodes, and those which are not are called unprovisioned devices.



This is the process in which an unprovisioned device is transformed into a node. Provisioning is a secure process that typically involves a smartphone application which will issue the unprovisioned device with a series of security keys that allow it to participate in the network. Once a device has those keys, it becomes a node.



Some nodes are more complex than others and may have more than one independently controllable part. Such parts are called elements. A lighting unit with four independent LEDs is an example of a node comprising four elements. Messages Nodes in the mesh network communicate and interact with each other using messages. Elements contain state values, which reflect or allow the control of some physical aspect of that element, such as whether it is currently switched on or off.



Messages allow state values to be queried by another element or changed. Changing a state value is often accompanied by a change the user can observe, such as a light switching on. Messages therefore represent various types of operations a node may initiate.



Messages are sent from and to an address of some kind. Bluetooth mesh defines three types of addresses. A unicast address uniquely identifies a single element. Unicast addresses are assigned to devices during the provisioning process. A group address is a multicast address which represents one or more elements. Group addresses will be established by the primary user via a configuration application and usually reflect the physical arrangement of a building and perhaps correspond to each of its rooms.


Virtual addresses

A virtual address also identifies a collection of elements, but acts much like a label which has been associated with an element. Virtual addresses will often be assigned in advance by manufacturers and might be used for scenarios, such as sending a message to all vending machines in the building, regardless of the room they are in.


Publish and subscribe

At Gatwick Airport, an indoor navigation system comprising of 2,000 Bluetooth beacons is enabling passengers to steer a course through the complex. The lighting at the North Terminal, seen here, was designed by StudioFractal and supplied by Dextra.

Bluetooth mesh uses a message-oriented communication pattern known as publish-subscribe. The act of sending a message is known as publishing. Elements are configured to select messages sent to specific addresses for processing, and this is known as subscribing. Typically, published messages will be addressed to group or virtual addresses.

The use of group and virtual addresses with the publish/ subscribe communication model has the benefit that removing, replacing or adding new nodes to the network does not require reconfiguration of other nodes. Imagine we have a group address for all lights on the third floor of our building called ‘Third Floor Lights’. Each light on the third floor has been configured to subscribe to this address. We also have a switch in the reception area which publishes ON and OFF messages to the Third Floor Lights address.

Consider what would be involved in installing an additional light on the third floor. The new light would be added to the network using the provisioning process and configured to subscribe to the Third Floor Lights address. No other nodes would be affected by this change to the network. The switch will continue to publish messages to Third Floor Lights as before and the new light will respond alongside the other lights.



Tesla has installed high bay fixtures from Thrive Energy using its Avi-on Bluetooth-based commercial lighting controls at the plant in Fremont, California. With the new proximity technology, the company could use its lights to track equipment and components.

Models define and implement the message types, state values and associated behaviours governing a particular aspect of a device. A device’s total set of capabilities and behaviours is a consequence of the collection of models it implements.

There are three categories of model types, namely client models, server models and controller models (which contain both client and server parts). Server models contain state values, whereas client models do not. In all cases, models publish and respond to a variety of defined message types, which act upon or report server state values. There are currently four classes of models, including lighting, sensors, ‘timing and scenes’ and generics.

The lighting models support sophisticated, modern lighting systems. Sensor models support all manner of sensor type and allow the building of sensor networks. Timing and Scenes models are used in automation scenarios. Generic models are the basic building blocks and define the most fundamental types of functionality that a device might have, such as the ability to have a simple on/off state or the ability for a state (e.g. brightness) to be set to a certain level.


Generic models

Examples of generic server models include the Generic OnOff Server and the Generic Level Server. As suggested by the name, the Generic OnOff Server includes a state value which indicates whether the host element is currently on or off and defines messages which can both get and set that state value. In other words, it allows other mesh nodes, like light switches, to send messages which cause the light to switch on or off. The Generic Level Server allows the representation and control of continuous level quantities, such as, but not limited to, brightness levels in lights. To reinforce the point of generic models, these common concepts apply to numerous types of devices, not just lights, and therefore can be used to meet the requirements of a great many product types.


Lighting models

The various lighting server models provide access to and control of a range of lighting product capabilities and characteristics, such as on/off, level, colour, temperature, lightness, lightness range, hue, saturation, chromaticity coordinates and more. The states representing these concepts have defined state transitions, which may be triggered by messages received from clients. States can be bound to other states so that a change in one produces a change in the other. Complex lighting behaviours may be supported in this way.


Managed flooding

A network which uses Wi-Fi is based around a central network node called a router, and all network traffic passes through it. If the router is unavailable, the whole network becomes unavailable. In contrast, Bluetooth mesh uses a technique known as ‘managed flooding’ to deliver messages. Messages, when published by a node, are broadcast rather than routed directly to one or more specific nodes. All nodes receive all messages from nodes in direct radio range and, if configured to do so, will relay received messages. Relaying involves broadcasting the received message again, so that other nodes, more distant from the originating node, receive the message broadcast.


Multipath delivery

An important consequence of Bluetooth mesh’s use of managed flooding is that messages arrive at their destination via multiple paths through the network. This makes for a highly reliable network, and it is the primary reason the Bluetooth mesh networking design uses a flooding approach rather than routing. Multipath delivery is inherent in the design of Bluetooth mesh and requires little effort to plan and set up.



Heartbeat messages are transmitted by nodes periodically. A heartbeat message indicates to other nodes in the network that the node sending the heartbeat is still active. In addition, heartbeat messages contain data which allows receiving nodes to determine how far away the sender is, in terms of the number of hops required to reach it. This knowledge can be exploited with the time-to-live (TTL) field.



TTL – which stands for ‘time to live’ – is a field which all Bluetooth mesh Protocol Data Units (PDU) include. It controls the maximum number of hops over which a message is relayed. Setting the TTL allows nodes to exercise control over relaying and conserve energy by ensuring messages are not relayed further than required. Heartbeat messages allow nodes to determine what the optimum TTL value should be for each message published.


Message cache

A network message cache must be implemented by all nodes. The cache contains all recently seen messages and if a message is found to be in the cache, indicating the node has seen and processed it before, it is immediately discarded.



The most significant optimisation mechanism in a Bluetooth mesh network is provided by a concept known as friendship. Nodes with a plentiful supply of power may form a partnership with nodes which are highly constrained with respect to power (e.g. they run off small batteries which must last for years). The former is termed a friend node and the latter a low power node. Friend nodes provide a message store and forward service to associated low power nodes. This allows low power nodes to operate in a highly energy-efficient manner with minimal use of the radio required for their operation.


Separation of concerns

Network security, the security of individual applications and device security are addressed independently. Area Isolation A Bluetooth mesh network can be divided into subnets, each cryptographically distinct and secure from the others.


Key refresh

Security keys can be changed during the life of the mesh network via a Key Refresh procedure.


Message obfuscation

Message obfuscation makes it difficult to track messages sent within the network and, as such, provides a privacy mechanism to make it difficult to track nodes.


Replay attack protection

A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. Mesh security protects the network against replay attacks.


Trashcan attack protection

Discarded network equipment at the end of their useful lives can still contains your network credentials. This information, including passwords can be extracted from its memory. However, nodes can be removed from the network securely, in a way which prevents trashcan attacks.


Secure device provisioning

The process by which devices are added to the mesh network to become nodes is itself a secure process.


  • Access more information, explainers and videos about Bluetooth mesh HERE.


  • Learn more about Bluetooth mesh and its role in the next generation of lighting control at the LuxLive 2019 exhibition. The show takes place on Wednesday 13 November and Thursday 14 November 2018 at ExCeL London. Entry is free if you pre-register HERE.