Addressing of a node in BLE Mesh

[bivay]

As unicast address is a address of a element in a node.

We have to assign unicast address to 500 nodes each contains 2 elements, and we configured publish and subscribe addresses to each model. 

We have to use client and server model both in our application.

In future if there is an new element adds in node and code is updated via mesh to all node simultaneously(its easy to load code in all), but this causes problem of reconfiguration of each nodes, instead of single element of each node as address of each element of every node got changed . this causes a huge problem.  

let we have a node having 3 elements having 2 model each. Then unicast address assigned to this node will be 0x0002,0x0003, and 0x0004. and to 2nd node 0x0005, 0x0006 and 0x0007, and continues, if new element add in node by any xyz reason. then unicast address have to assign 0x0002,0x0003,0x0004 and 0x0005 and to 2nd node 0x0006,0x0007,0x0008 and 0x0009 and so on.

on one side,  we can update code to all nodes easily way, on other side I have to configure whole network again which is mostly time and money consuming.

Then Have BLE Mesh any solution for it.

There is also a problem with element address if in a network many device may have different number of elements, then we have to remember the address of each node in sequence which may causes issue to server side management (internet side).

[Omkar Kulkarni]

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).

[bivay]

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.

[Omkar Kulkarni]

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.