How different is a Mesh packet from BLE advertising packet?

[Mitch996]

Hi, I want to confirm if the Mesh packet is a "special" form of advertising packet or it is completely different, i.e. all the headers and addresses etc are changed.

By reading relevant document I get the impression that the 2 are completely different - instead of a packet which is "embedded" inside the payload of an advertising packet, or a packet which alters the fields of an advertising packet to different values but preserved all the formats for an advertising packet.

This means it could be extremely problematic if I want to adopt it to android, which offers very limited capability for me to customize what packet it sends out (with the latest android release that could be a different story).

Any insight?

[bjorn-spockeli]

Hi Mitch,

my interpretation of the Bluetooth Mesh Profile Specification is that is a standard non-connectable and non-scannable undirected advertising packet with the AD type is set to "Mesh Message", see screenshot below.

Not all smartphones will be able to support the Advertisement Bearer(the Mesh Message AD type might not be an option available in the stack), but the Bluetooth Mesh also specifies a GATT bearer, which essentially allows you to tunnel mesh packets through a regular BLE connection.

I recommend that you take a look at the GATT Bearer section and the GATT Proxy Service sections in the Bluetooth Mesh Profile, available here.

Best regards

Bjørn

[Mitch996]

Hello @bjorn-spockeli, I hope you don't mind me asking 2 more questions. I'm very concerned about the length of developing a GATT interface. So I wanna know:

1. If I were to tunnel all messages through the GATT interface, all I have to do is to register certain GATT event handler/callbacks in the stack of the softdevice right? No future complications regarding implementing GATT interface alone? (Although actual provisioning itself will be a very different story)
2. There already are provisioner examples, but it was done on a "node"/nrf5x chip instead of a PC or tablet what not. Is it possible to have BOTH provisioner AND provisonee running on the same node, and switch back and forth depends on whether GATT was utilized? In other words, if say a tablet connected via GATT to a node, then this node will switch into "provisoner" role, and provision the rest of the network.

You might wanna ask why I want such a bizarre setup. Well I want to code as little as possible to save time so not implementing a provisioner myself on my tablet or PC would be

(continued...)

[Mitch996]

very time-saving and that's what I want, is it possible?

Awaiting your expertly opinion on both questiosns :)

Edit: I could have got it completely wrong, the GATT interface could be something very, very different, nevertheless I'm still curious.

[bjorn-spockeli]

1. Yes, from the tablet side you'll just see the GATT Proxy Service and you'll write to and read its characteristics. The GATT Proxy Service is a standardized service, so you'll just have to add the service and the conversion from the GATT to ADV bearer is done by the service.
2. Yes, the tablet can provision in a node via the GATT bearer and configure it as a proxy node. The tablet(provisioner) can then use the Remote provisioning feature of the Nordic Bluetooth mesh to relay provisioning messages to other devices that should be provisioned into the mesh.

[Mitch996]

@bjorn-spockeli Thank you for the detailed answer! Regarding question #2, I think since the softdevice with both provisioner boards and provisionee boards are the same, the role-switching could be completed with some de-initialization and re-initializations.

Nevertheless, one last thing, let's say I have a net work of as much as 100 nodes, and I'm relying on the board (the nrf52 series chip) to do the provisioning. Will it be too much workload for the chip? Can it handle the situation? I know the nrf52 chip usese cortex M4 and can run up to 64Mhz but I still wanna be certain.

Edit: all information regarding the network of course, will be stored in the tablet, not in the board.