• State Verified Answer
  • Replies 10 replies
  • Subscribers 63 subscribers
  • Views 6758 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 128502
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bluetooth Mesh key generetion and handling?

SørenHN

The Bluetooth Mesh Light Switch example shows how to work with keys for a Mesh Network. But I have some questions about who generate the keys and what they are used for.

The example provisioner uses these keys:

dsm_handle_t m_netkey_handle;
dsm_handle_t m_appkey_handle;
dsm_handle_t m_devkey_handles[...];
dsm_handle_t m_server_handles[...];
dsm_handle_t m_group_handle;

Network Key: I think I understand the network key, but i am a bit confused about the function it is used in, dsm_subnet_add(). The name of the function indicates that it is used for adding subnetwork, but is it also used for adding the overall Mesh network to the Device State Manager?

And just to be sure, the network key is generated by the provisioner and distributed to all the nodes, right?

Application Key: I am not sure what the application key is used for and who initially knows it. Is it distributed by the provisioner to the nodes of the network or does every node participating in the application on the network know this before being provisioned?

Device Keys: It seems like the device key is distributed to the node from the provisioner, is this correct?

Server Handles: These keys is for each of the elements holding a Light Switch server on the nodes in the network right?

Group Handle: To my understanding, this key functions like the Server Handle, it is just possible to address more than one node with this address. But in the example it is used in dsm_address_publish_add() together with NETWORK_GROUP_ADDRESS. Does this mean that every node in the network should also be added to a group for the whole network?

Edit 1: ...

Edit 2: I have moved my additional question from Edit 1 to its own question here on the forum.

I am still interested in clearing my confusion on the different keys if anybody can provide an explanation.

  • 0 in reply to Bjørn Kvaale

    Yes, i think it makes sense.

    The thing I don't understand about subnetworks is, are a subnetwork somehow connected to the network or are a subnetwork just another network, which the node also is a part of?

  • 0 in reply to Bjørn Kvaale

    I am pretty sure subnetworks are connected to the network (see Bluetooth Mesh Glossary, search for subnet). The definition posted there is: "Networks may contain one or more subnets". Therefore, the subnetwork must be a part of the bigger main mesh network.

  • 0 in reply to Bjørn Kvaale

    Hi SørenHN. Sorry for the delayed response. I hope my updated answer answers all of your questions. Let me know if something doesn't make sense.

  • 0 in reply to Bjørn Kvaale

    Hi Bjørn, thank you for you answers. I think I finally have figured out how the group address work. I thought the node was somehow added to the group. But it is more like the group being added to a node by being sent the group ID.

    I do still not completely understand how the subnetworks work, but I will look the dsm source code and see if i can figure it out.

  • 0

    After working more with this and reading the other answer, I think i understand it this better and write this for others who would like a better understanding.

    Network Keys: Network keys is generated and distributed by the provisioner, the main network key is shared by all nodes in the network and the config client and server uses this subnetwork to communicate.

    The netkey_index is used for avoiding sending the whole network key every time a model should use a subnetwork. Instead the network key is sent once and when the key is to be used again later, it is just referenced by its index.

    Application Key: The application key is used the same way as the network. It is just used by another layer in the bluetooth mesh stack.

    Device Keys: The device key is a specific key for each device. It is used by the config_client for configuring a device.

    Server Handles: The server handles is maybe no given the best name in the example as they reefer to the element in which the light server models exist. I have renamed them to element_handle in my own project for clarity.

    Group Handle: The group handle reefers to the group address for all the light servers in the example.

    For being able to use a group address, the config_client should first tell the model to listen for messages to this group address, also known as adding the model to a group.

Related