Mesh architecture for Generic On/Off servers - multiple subscription groups vs single group with node models grouped by app keys

[crypt3d]

First of all, thank you and kudos to Nordic Support Team for having an awesome and functional forum. 

Having said that, I have a question related to the architecture of mesh network in lighting application. What's the difference between having multiple groups and a single group that is fragmented using app keys ? For example, having different nodes subscribing to different groups (rooms, hallways, public toilets etc) based on their location in building vs. all nodes subscribing to one single group(whole building) but the node models are bound to different app keys based on their location in building ( for example, app key #1 for nodes in rooms, app key #2 for nodes in hallways etc)

[tesc]

Hi,

While it does sound technically possible, the suggestion to put everything in the same group but with different app keys breaks massively with the intentions put forward in the Bluetooth mesh specifications. I would not be surprised if it has an impact on power consumption and/or network performance as well, since it means the nodes will think the packet is for them and they will route it to the model and they will try to decrypt them before figuring out they are corrupted and discarding them. Especially if there are Friend nodes and Low Power nodes involved, as it would mean the Friend nodes keeps messages not really intended for the Low Power nodes they have befriended. I would strongly advice against it.

Is there a reason for wanting to do it that way, or is it just as an academic exercise? There is nothing wrong with using a different application key for different parts of the network (even if they use the same models), in order to partition parts of the network into separate "applications", or areas that cannot communicate with each other / control each other, but then you would typically want to use a different set of group addresses as well.

Regards,
Terje

[crypt3d]

Hi Terje,

Thank you for the clarification.

1. Now, I'm thinking about having different groups for nodes based on floor level like #Floor_1, #Floor_2, #Floor_3 and also groups based on the nodes location like #Rooms, #Hallways, #Washrooms etc. So, if I want to turn off all the hallway lights for entire building, I would publish the message to group #Hallways. Similarly, if i want to turn off all the lights(rooms, hallways, washrooms) in second floor, I would publish the message to group #Floor_2. Furthermore, I was thinking about  having 3 different appkeys for nodes in each floor based on their location within the floor. So, if I want to turn off only the hallway lights in second floor, I would still publish the message to #Floor_2 from the client model that has the same app key as the hallway lights in second floor. Does this make sense ? Or should I have even more groups for each floor like #Floor_1_Hallways, #Floor_2_Hallways, #Floor_3_Rooms etc to control location based nodes for each floor ? 

tesc said:

Especially if there are Friend nodes and Low Power nodes involved,

There will be no friend and low power nodes, every lights will be hooked to the mains.

tesc said:

Is there a reason for wanting to do it that way, or is it just as an academic exercise?

 I'm writing Bachelor thesis that shows proof-of-concept for using bluetooth mesh in lighting infrastructure like hotels and buildings and none of this is going to production, just that i'd like to explore and evaluate the topic with little more depth.

2. Also, I'm trying to control the lights from the GUI exposed by the Raspi that is connected via UART to a nRF52 DK board(which is programmed with pyACI). In this case, the DK would also have Generic On/Off client models in addition to being the provisioner, right ? I would also want the client models to subscribe to state changes from the light servers. Does the DK(PCA10040) board has enough flash and RAM to support all of these functionalities ? Also, this should be possible given the aforementioned resources are enough, right ?

[tesc]

Hi,

1. The way to go then should be to use groups. There are 16128 dynamically assigned group addresses in a Bluetooth mesh network. You may want to create a data model for the device doing configuration for the network, so that e.g. selecting the placement of "hallway" and "floor N" results in subscribing to the groups "hallways", "floor N" and "floor N hallways". That is, the configuration tool works on a higher abstraction level than the underlying group assignments of the network.

One place where application keys may fit, is for each room in a hotel. That is, for preventing access to a switch in one room to give control over the light in a different room. Security is all about putting in place hurdles for those who want to break in, and you tend to think about "how costly are the security measures, what does it cost to get around them, and what is the worth of what they protect." I do not know if protecting the light in a hotel room with its own app key is worth it. Protecting the door lock on the other hand, probably is. Note that this is not about routing the messages, though, it is about what devices may communicate with what other devices.

2. In order to control the lights from a gateway you would have on/off clients on the gateway, yes. Depending on the number of on/off clients needed (one for each publish address) you may have to use a set amount of clients and reprogram the publish address on an on-need basis.

If you have 100 unicast addresses and 40 groups that means 140 on/off clients. Instead you may for instance use say 10 on/off clients, and every time you need to set on/off to an address you first check if you already have a client configured to that particular address and if not you take the least recently used client and reconfigures it for the now needed address. Please note that the way our stack works we store configuration to flash and so reconfiguring nodes will count against flash wear. (If I recall correctly, flash on the nRF52832 is rated for 10k write/erase cycles.) If you use the PyACI (or serial interface in general) I think you should be able to run things from the PC (RPi) and with persistent storage disabled from the stack running on the nRF, though.

Regards,
Terje