Mesh Scalability

[Arepa]

Hi there,

This is a general question about addresses types in Bluetooth mesh and specs:

As far as I know, Bluetooth mesh specs talk about the 32767 nodes in the theoretical limits assuming all the nodes are active all the time, but the practical limit is most likely lower due to performance issues and limited bandwidth.

Info from specs:

Group addresses are used to identify a group of nodes and the max number the group address is 16834

Virtual address or virtual groups can be assigned to one or more elements and multiple nodes, it can take form of a 128-bit UUID, it means it is a different kind of group with more address available

• 1) Do the specs refers exclusively to the unicast addresses for the node limit up 32767?
• 2) How many nodes are allowed per group addresses?
• 3) if I have 128-bit for combinations for a new virtual group addresses, is it associate to the max number of nodes using virtual addresses or the number of nodes should keep below 32767?

I am asking the above because I am planning to deploy more than 500k+ devices most of them are sleepy devices and almost 0.001% (low messaging traffic) are active at the same time to report data and goes to sleep again. The idea of using Bluetooth mesh is for extending the range and cover a greater area, it could work fine for my application if all the nodes are within the same network regardless they are actives or not.

Could Bluetooth mesh fix to a project where are going to use such amount of devices/ nodes?

Regards

[Edvin]

Hello,

There is a blog post on Bluetooth org's web page regarding Bluetooth Mesh addressing. You can find it here.

1: Yes. As you see in the address fields, unicast addresses are on the format 0b0xxxxxxxxxxxxxxx, which leaves 15 bits that can be changed, minus the address 0b0000000000000000, so (2^(15)) -1 = 32767.

2: There is no limit to how many nodes that can be listening (or publishing) on one group address. 

3: As you can see, the group addresses are on the form: 0b10xxxxxxxxxxxxxx, so the maximum number of group addresses is (2^(14))-1 = 16384.

4:

Either way, 500k devices is above the limit of the network size. It isn't possible to have that many devices in a network, because each device requires a unicast address, and I don't think kicking a device every time it is done sending data, and then provision them again the next time is a good solution either, because this means you must provision 500k devices every cycle. It seems quite messy.

I rather suggest that you split the 500k devices into 32k-sized groups, and then have some application based information flow between the networks. Some nodes that are connected between the networks, or alternatively some cloud gateways to pass the data directly to the cloud.

Best regards,

Edvin

[Arepa]

Hi Edvin, Thanks for your reply.

Splitting into 32k-size groups looks like the path I have to follow, now my question is:

Is it necessary subscribe my client to different group addresses? I did some testing with 3 nodes I provisioned, one Client node and 2 servers nodes, then inside client_status_cb (client code) I have a filter for each group address

server 1 using group address 0xC0FE: I am receiving all the messages from there

server 2 using group address 0xC0F2: this one is publishing, but still using the 0xC0FE  instead of 0xC0F2 address, Is the group address specified on the node when the node is provisioned? if so how can I manage to use multiple groups?

[Edvin]

Hello,

The group addresses are set up differently in the different versions of the Mesh SDK. Which version of the Mesh SDK are you using?

Also, the group addresses are typically given by the provisioner. Which provisioner do you use? The mobile app (where you set the addresses manually), or the provisioner node example?

BR,

Edvin

[Arepa]

Hi Edvin, 

Currently, I am using the Mesh SDK 2.1.1, SDK 15.0.0 and the provisioner node example

Being able to provisioning different groups into the Mesh network. For example the nodes who are relaying messages, are they going to be able to relay messages from differents groups?

[Edvin]

The way that a mesh network works is that every node will relay all messages (within the network), regardless of whether the message is intended for that node or not. This is the reason Bluetooth Mesh networks are called "flooding networks". The only exception is if the message is intended for a unicast address intended for that specific node. Then it will not relay the message (all other nodes will, though).

In the provisioner example, the provisioning is done in node_setup.c. When a new node is discovered, the provisioner decides what role it has in setup_select_steps(). In this example, it is either client_config_steps, server1_server2_config_steps or server_config_steps.

This means that the first node that it finds (which is always the client, because it is looking for this device first), will go through the steps listed in client_config_steps.

The second and third node will go through the server1_server2_config_steps, and the rest of the servers will go through the server_config_steps.

You can see in e.g. server1_server2_config_steps, that one of the steps are NODE_SETUP_CONFIG_PUBLICATION_ONOFF_SERVER1_2, which will give the nodes a publish address which is the address of the client.

I know this setup is a bit confusing, but let me try to explain (and understand) how this is set up.

The client has 4 publication addresses, NODE_SETUP_CONFIG_PUBLICATION_ONOFF_CLIENT1-4. These are set to:

Server 1, Server 2, odd group, even group.

The first two are unicast addresses, and the two last are group addresses.

All server nodes go through NODE_SETUP_CONFIG_SUBSCRIPTION_ONOFF_SERVER, which will make them subscribe to either the odd or the even group.

The first two servers to be provisioned will, in additiion to be assigned the unicast address of the ..._PUBLICATION_ONOFF_CLIENT1-2, also get a publication channel, which corresponds to the unicast address of the client. This is so that the nodes can send an application layer ACK to the client that they in fact toggled the light when the client told them to.

Exactly the values of the different addresses in this example is a bit hard to tell. They are mostly used as conn_handles in the button event handler from in the client application. But this describes basically how mesh works. Every node has a unicast address, which they will always listen on, and they can be configured to listen to a number of channels besides that. They are also told what channels they should subscribe to. So in fact, there is no difference on the server and client nodes in these examples, except that they are told to publish and subscribe to different channels. All nodes will relay all messages, except for messages that are intended for their "personal" unicast address. But every node will relay messages with unicast addresses that are not their own.

Best regards,

Edvin

[Arepa]

Thanks  Edvin, your last comment was very clear for me and solve some confusion I had with the provisioner code

Regards