Addressing of a node in BLE Mesh

RE: Addressing of a node in BLE Mesh

Omkar Kulkarni — Wed, 18 Sep 2019 15:12:04 GMT

As far as I understand, the Bluetooth Mesh is designed to be interoperable networking standard. Since it a networking standard, it is imperative to have a notion of addresses and a way of categorizing the end-application functionality in suitably defined blocks so that this functionality can be developed, tested, qualified and deployed as required. That is why Bluetooth Mesh uses the notion of elements for addressing, and a notion of models that broadly define end-application use cases.

RE: Addressing of a node in BLE Mesh

bivay — Wed, 18 Sep 2019 13:40:18 GMT

I have one doubt that why there is elements or models in Bluetooth, it can be simple as sending messages and then translate them into useful work, in this single element and model needed, no need to worry about future expansion in code side if it provisioned or not.

I searched many time for this reason but didn't get answer. I asked Bluettoth SIG about it, but didn't get response from there.

How models are better than one single model with only trans receive of messages and then use message as need.

I didn't means that Models are wrong or anything else, and I know if it is standard, then there must be reason for it. I want to know this reason.

RE: Addressing of a node in BLE Mesh

Omkar Kulkarni — Wed, 18 Sep 2019 13:29:44 GMT

Hi,

A couple of points:

1. Are you trying to deploy this product as a qualified Bluetooth Mesh device? If the answer is Yes, you cannot change the device composition of such device (i.e. adding more elements and models), once the device is provisioned. This is because third party provisioner will not know such change has occurred and it will break the addressing of the nodes in a network by having multiple nodes/elements with the same address. This may break the functionality of the network for those nodes which have overlapping addresses.

2. If the answer to (1) is No, probably you can do certain tricks to minimize reconfiguration efforts. Such as: leaving gaps in the address spaces. For example, the unicast address of each node can be assigned such that, this address is a multiple 5, instead of assigning them sequentially. Leaving you a gap of 2 addresses (since each node has 3 elements in your case) for future expansion. Once you have this, for the reconfiguration purpose, you may only have to reconfigure publish or the subscribe setting of the affected models on affected nodes, or, directly use access and DSM APIs to change the publication and subscription settings on the node locally (see config_server module code for handling publication and subscription messages as a reference).