While Bluetooth Low Energy has made major inroads as a foundation technology for the Internet of Things (IoT) it has an Achilles’ heel. Because it was primarily designed to sustain battery-powered peripherals communicating with a central device such as a smartphone, the technology is unable to support mesh networking. But now, the adoption of the Bluetooth mesh 1.0 specification has eliminated the weakness.
Mesh networking allows devices within a network (“nodes”) to communicate with any other node using packets relayed via other nodes if necessary and without recourse to a central hub device. Such a system enables extended range, flexibility, and redundancy, and is a prerequisite for any self-respecting IoT wireless technology. Key applications for Bluetooth mesh include enterprise lighting installations, back-ends for managed beacons, and industrial monitoring.
Several companies, notably Silvair, considered this requirement so fundamental that it developed proprietary mesh solutions based on Bluetooth Low Energy technology to fill the gap. It’s perhaps little surprise then that the company’s engineers have taken a key role in the drafting of the official Bluetooth mesh specification which was formally released in July.
Not just for Bluetooth 5
Because developers are familiar with a linear progression for the technology it might be assumed that Bluetooth mesh is an update of Bluetooth 5 - but that’s not the case. Rather, with a software update, any Bluetooth Low Energy chip compatible with Bluetooth 4.0 (or later) can support Bluetooth mesh. This allows networked Bluetooth low energy installations that currently employ a proprietary mesh solution to be upgraded over-the-air to become Bluetooth mesh compliant.
That’s not to say that the firmware updates are insignificant. Bluetooth mesh is a new architecture with seven layers (bearer, network, lower and upper transport, access, foundation models, and models) on top of the standard Bluetooth low energy physical layer (radio). A node, upon receiving a message, passes it up the layers from the underlying Bluetooth Low Energy physical layer, via the bearer layer to the network layer.
The network layer applies various checks to decide whether to pass the message higher up the stack or discard it. (Further details on the function of these layers can be found in reference 1.)
The Bluetooth mesh specification details four types of nodes: “Relay Nodes”, “Low Power Nodes”, “Friend Nodes”, and “Proxy Nodes”.
Relay nodes can retransmit received packets and are the mechanism by which packets rapidly propagate across the entire network. The downside of relaying is increased current consumption because it relies on the
nodes being continuously ‘awake’. While Bluetooth Low Energy’s power consumption in a mesh network configuration will compete favorably with competitive technologies, such an operational mode isn’t sustainable with battery power alone. This is not a disadvantage for applications such as smart lighting, because fixtures are wired into the mains supply to power the LEDs, but it could be a problem for other non-mains powered devices incorporated into the network such as switches.
To overcome this problem, Bluetooth mesh includes “Low Power Nodes” (LPNs) which can operate from batteries or energy harvesting. LPNs work in tandem with “Friend Nodes”. Friend Nodes are typically mains powered so can remain permanently awake; the devices cache any messages destined for the LPN. The LPNs switch to ‘receive’ mode according to a predetermined schedule, accept cached messages, operate as instructed, and then rapidly return to a power-saving ‘sleep’ state.
“Proxy Nodes” allow devices that run the Bluetooth Low Energy stack but don’t support Bluetooth mesh (for example, the current generation of smartphones) to connect to a Bluetooth mesh network. Interaction is achieved via both the node and device’s Generic Attribute Profile (GATT) interface.
Bluetooth mesh follows Bluetooth technology’s architecture whereby GATT “Profiles” allow many use cases to share a common information structure. However, because of the distributed nature of a mesh network, the design of the Profiles is different. And to avoid GATT Profiles being mistaken for the mesh equivalent, mesh profiles are called “Models”.
Bluetooth mesh 1.0 includes “Configuration”, “Heartbeat”, and “Health” Foundation Models. The Foundation Models are complemented by “Mesh Models” for use cases such as “Generic”, “Lighting”, “Sensors”, and “Scene”. Mirroring GATT Profiles, it is also possible to create custom Foundation and Mesh Models. (Models is an involved subject and readers are advised to consult reference 1 for more detail.)
Driven by lighting
Smart lighting is a pioneer application for wireless IoT technologies so it’s perhaps little surprise that much of the initial Bluetooth mesh specification has been tailored to this role. In a blog, the Bluetooth Special Interest Group (SIG) explains as much, saying: “Bluetooth mesh will make the largest initial impact in commercial lighting”.
That said, the mechanisms incorporated for smart lighting conveniently support other key applications such as beacons, security networks, as well as heating, ventilation, and air conditioning (HVAC) networks. Key among these mechanisms is communication via “flooding”; each packet is broadcast to every node in the network until it reaches the target node(s).
Flooding is complemented by three types of addressing: “Unicast” (used during initial node set-up), “group”, and “virtual” (primarily used by device manufacturers to ‘label’ their products). Of these, group addressing is the most applicable to everyday operation. A group address is a multicast address which represents one or more elements in the network. The SIG has defined four “Fixed Group Addresses” named “All-proxies”, “All-friends”, “All-relays”, and “All-nodes” to specifically address the types of nodes defined above.
In addition to these group addresses, the installer will likely allocate dynamic group addresses during configuration to reflect the physical mesh layout. For example, dynamic group addresses could be allocated to the lights in each room of a building.
A flooding mesh and group addressing makes sense for key smart home applications such as lighting. A flooding mesh allows an “ON” command from a switch to a group of smart lights to rapidly propagate through a network with every node receiving the command and acting accordingly. The lights in the target group illuminate almost instantaneously. The latency is much lower than, for example, a star network, where the hub
is required to transmit an individual command to each connected light.
A flooding architecture brings other advantages ... and some compromises. A key additional advantage is simplicity, underscored by limiting communication to Bluetooth Low Energy technology’s three advertising and scanning channels (remembering that the technology
has 40 frequency channels in total). But this comes at the cost of
reduced bandwidth due to the need to manage traffic to prevent
packets overwhelming this limited subset of frequencies.
The specification includes several mechanisms to mitigate advertising and scanning channel congestion. The first is a “Time-To-Live” (TTL) counter that defines how many times a specific packet can be relayed – after a defined number of steps, the packet will not be relayed further.
Setting the TTL counter to three, for example, allows a packet to move a maximum of three steps from its source before it’s not retransmitted.
The second congestion-prevention mechanism is a message cache of transmitted packets. A packet can only arrive in the cache once it has circulated completely around the mesh – at which point it can safely be assumed that further transmission is unnecessary. An “optional relaying” feature also limits mesh congestion. By switching off relaying, nodes can receive packets but not pass them on. Optional relaying adds complexity— because the designer must trade-off mesh flexibility against bandwidth consumption — but in doing so improves overall mesh performance.
Security first
Bluetooth mesh draws Bluetooth technology ever tighter into the Internet of Things (IoT) - making security vital. Consequently, the designers of Bluetooth mesh have ensured the network, individual applications, and devices are all secure and cannot be switched off or otherwise restricted. With Bluetooth mesh, security is not optional, it’s mandatory.
This mandatory approach starts with ‘provisioning’. Provisioning is the process by which otherwise isolated devices become nodes on the mesh network and can be implemented via an app supported on a smartphone or tablet. The process follows five steps: Beaconing (indicating availability to join the mesh); Invitation (from the provisioning device); Public Key Exchange; Authentication; and Session Key Exchange (securing the subsequent distribution of data to complete provisioning).
The provisioning process implements a high degree of security. Thereafter, packets are end-to-end encrypted with AES-128, with privacy enhanced by additional AES-128 encryption between each relay (in part to hide the node addresses). In addition, procedures are included to periodically refresh the encryption keys, and to detect and repel “replay attacks”.
Further information on Bluetooth mesh is available from Nordic’s website and DevZone. Nordic’s recently introduced nRF5 SDK for Mesh allows developers to start designing Bluetooth mesh applications with the company’s nRF51 and nRF52 Series SoCs. Nordic’s implementation of the Bluetooth mesh stack includes some useful features that aren’t included in the Bluetooth mesh 1.0 specification.