This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bluetooth mesh gateway architectures and implementations

Hi!
Could you clarify a bit about Bluetooth mesh gateways' implementations. I wonder to know possible ways of Bluetooth mesh gateway implementations. How is it possible right now?
If I have a SoM (for simplification it could be a Raspberry Pi board) with Linux, which uses BlueZ stack underhood, and I want to control Bluetooth mesh network from it. Is it possible to directly control Bluetooth mesh nodes, sending packets to them and receiving packets from them throught Bluetooth mesh? Should be the gateway a part of Bluetooth mesh network as a separate node? It seems that SimpleLink Starter Mobile App from TI employes a specific opportunity to control devices via PB-GATT packet, connecting to a Bluetooth mesh node with Proxy feature. A mobile device connects to the node using Bluetooth LE and encapsulates Bluetooth mesh packets, sending through this node, and not directrly, using Bluetooth mesh advertising packets. So, could you clarify, is it possible to control Bluetooth mesh networks from such kind of device with Linux? And if yes, where could I look to understand, how it's possible? And if no, which options do we have to control Bluetooth mesh network from the gateway? Do we need to connect a microcontroller (like CC13x2 and CC26x2) via UART/SPI to our host MCU and write a custom firmware for it to control Bluetooth mesh network, using this microcontroller as a proxy between gateway and Bluetooth mesh network? Or could we control the Bluetooth mesh network, connecting to a arbitrary Bluetooth mesh node with Proxy feature through Bluetooth LE and control the the network, encapsulating packets, as it SimpleLink Starter Mobile App does?
How do companies realize their Bluetooth mesh gateways? How do they control the mesh network from them if BlueZ doesn't support a native Bluetooth mesh controlling?
Thank you in advance for any assistance with understanding such the details and any recommendations. It would great to hear others' thoughts about this problem.

  • Hi,

    I have assigned an expert to address your query.

    Best Regards,

    Jan

  • Thank you, Jan! I am looking forward to read the expert answer.

  • Hey Roman,

    These are great questions, I will try to address them here.

    Do we need to connect a microcontroller (like CC13x2 and CC26x2) via UART/SPI to our host MCU and write a custom firmware for it to control Bluetooth mesh network

    There are really two angles (maybe more) to look at: controlling a single node through a linux host, or controlling the entire network.

    To control the node, TI's gateway solution for Bluetooth mesh implements a "2 chip" architecture, where one chip acts as the gateway and the other implements the Bluetooth mesh functionality. You summed this part up correctly already as I can see. We provide a Python based application that connects to the node over UART (see User's Guide section on this)

    To controlling the network, you can probably do this in a few ways:

    1. Having the linux side be the provisioner (most commonly in the field, the provisioner is a mobile phone application) through BlueZ.
    2. You can connect to a Proxy enabled mesh node over the GATT bearer and use the SIG defined Proxy protocol to communicate with the node/network.
    How do companies realize their Bluetooth mesh gateways? How do they control the mesh network from them if BlueZ doesn't support a native Bluetooth mesh controlling?

    This is a tough one to answer, I think current solutions have a proprietary approach to solve this. It is up to the designer to find the most efficient way to control the network. Factors like network topology play a big role in this. For example, you may consider adding a node configured with "2 chip support" to the mesh network. Depending on your design, you can directly leverage this node in the network so the linux side can be aware of the network data. This is done by controlling a single node and using that to communicate within the network.

    One common question I would like to clarify is: can we have a CC13x2/CC26x2 device be the provisioner? The answer right now is unfortunately no, we do not have that capability yet.

    Hope this helps.