Discovering Proxy Nodes
Bluetooth® Low Energy devices use GAP advertising to facilitate their discovery by other devices. Bluetooth mesh Proxy Nodes use exactly the same technique, advertising their availability, their role as a Proxy Node, and their identity in GAP connectable advertising packets.
GAP advertising packets contain fields of various types, known as AD Types. These are defined in the Core Specification Supplement. Proxy Nodes include the following fields in advertising packets:
Table 1 – Mesh Proxy Advertising
Indicates General Discoverable Mode.
Complete List of 16-bit Service UUIDs
Incomplete List of 16-bit Service UUIDs
Includes the UUID of the Mesh Proxy Service.
Contains data relating to the Mesh Proxy Service which identifies the network or node that the Proxy is providing the service for.
The contents of the Service Data AD Type bear further examination.
Service Data Field
The value in this field lets us correctly interpret the content of the Identification Parameters field.
0x00 : Network ID type
0x01 : Node Identity type
A Network ID or a Node Identity, depending on the Identification Type.
A Network ID is a unique, public identifier derived from a Network Key (NetKey – see Mesh Network Management). Node Identity is derived from a combination of the Proxy Server node’s Unicast Address and a network identifier, such as the network ID for one of the subnets it is enabled on.
If a Proxy Server is a member of more than one subnet, it will interleave advertising packets containing each subnet’s network ID, one advertising packet at a time.
A primary use of Node Identity advertising is to allow a Provisioner to quickly connect directly back to a newly provisioned node, so that configuration of the new node may be completed.
The Proxy Protocol
The Proxy Client and Proxy Server communicate using the Proxy Protocol and send each other Proxy PDUs. These PDUs can be thought of as containers for various types of Bluetooth mesh PDU.
Bluetooth® mesh access messages use the core Bluetooth mesh stack and messages are therefore contained within Network PDUs. Network PDUs can be encapsulated within Proxy PDUs.
A variety of beacons are defined in the Bluetooth Mesh Profile Specification, including the unprovisioned device beacon and the secure network beacon. Bluetooth mesh beacons can be accommodated by the Proxy Protocol.
The provisioning process involves its own protocol and Provisioning PDUs can also be exchanged within Proxy PDUs.
Finally, the Proxy Client and Proxy Server may exchange special proxy configuration messages, which we’ll cover shortly. These too may be encapsulated within Proxy PDUs.
As you can see, most types of mesh data can be exchanged using the Proxy Protocol and therefore be sent and received by a GATT client connected to a Proxy Node.
Proxy PDUs vary in size across different devices, with the size of PDUs dynamically set according to the Maximum Transmission Unit (MTU) of the Bluetooth Low Energy Attribute Protocol (ATT), which is the underlying basis for transporting Proxy PDUs over a GATT connection. Furthermore, the Proxy Protocol can accommodate long Bluetooth mesh messages by allowing either complete Bluetooth mesh messages to be encapsulated in a Proxy PDU or individual segments of multi-segment messages.
An important point to note is that any Bluetooth mesh node may implement the Proxy Protocol and therefore support direct interactions over a GATT connection, not just Proxy Nodes. This can be useful in provisioning scenarios.
Further information on the Proxy Protocol, including the format of Proxy PDUs can be found in the Bluetooth Mesh Profile Specification.
Proxy Filters and Proxy Configuration
Proxy Clients can exercise fine control over precisely what network traffic they receive by configuring a filter which the Proxy Server applies. Filters take the form of accept lists and reject lists and they each specify lists of destination addresses. Addresses in the list may be any mix of the supported address types, namely unicast, group, or virtual addresses. Messages with destination addresses not included in an accept list filter are dropped by the Proxy Server’s proxy filter. Similarly, messages with destinations which are included in reject list filters are dropped.
Proxy configuration messages are exchanged between the Proxy Client and Proxy Server and allow the configuration of the proxy filter.
Provisioning using a Bluetooth Low Energy Smartphone or Tablet
The Provisioning process, by which new devices are added to a Bluetooth mesh network, is typically carried out using a smartphone or tablet. Most such devices will not implement the full Bluetooth mesh networking stack and it’s likely they will use the Proxy Protocol for all interactions with the Bluetooth mesh network, including provisioning. As stated earlier, Provisioning PDUs can be encapsulated within Proxy PDUs and therefore can be exchanged over a GATT connection via a Proxy Server node. This use of the Provisioning Protocol with the Proxy Protocol is given the name PB-GATT in the Bluetooth Mesh Profile Specification.
The provisioning process was described in a previous article on our series entitled Bluetooth mesh network management and we’ll look under the hood at the associated security details of provisioning later in this series.
What’s Required to Use the Proxy Protocol with a Proxy Node?
For a device, such as a smartphone, to use the Proxy Protocol to communicate with a Bluetooth® mesh network via a Proxy Node, the device must scan and connect to the Proxy Node. In other words, it must support the GAP Central role.
Furthermore, the smartphone must first be provisioned. No device may interact with nodes in the Bluetooth mesh network without having first been provisioned.
Support for in-market Bluetooth Low Energy devices via GATT, the Proxy Protocol, and Bluetooth mesh Proxy Nodes is big news and opens the world of Bluetooth mesh networking to enormous numbers of devices which people already own. I’d say that’s pretty exciting. Hope you feel the same way!