This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE mesh single node remove from network

Is there any method to remove a single node from the network in current mesh SDK 2.1.0 with s132 soft-device 6.0?

With "config_client_node_reset" it will remove all the nodes from the network who has received this message at the time, but I wanted to remove only one specific node from the network.

I've looked through Device State Manager Key refresh APIs which might be used for the same functionality, but I wasn't able to figure out how to use those for removing a node. so could you point out me for the same?

P.S. My observed Key refresh APIs was:

uint32_t dsm_subnet_kr_phase_get(dsm_handle_t subnet_handle, nrf_mesh_key_refresh_phase_t * p_phase);
uint32_t dsm_subnet_update(dsm_handle_t subnet_handle, const uint8_t * p_key);
uint32_t dsm_subnet_update_swap_keys(dsm_handle_t subnet_handle);
uint32_t dsm_subnet_update_commit(dsm_handle_t subnet_handle);

If there was any other method to achieve the same then also suggest.

Parents
  • Hi Spiderman :)   

    Are you sure "config_client_node_reset" is to remove all nodes in the network that receive the message ? 

    Note that "config_client_node_reset" is used by configuration client model. And configuration model use device key as its app key. Each device has its own unique devicekey that distributed when propositioning. So there will be only one device can process the reset command from the configuration client. 

    However, there isn't a way to be really sure that the node that receive the config_client_node_reset() would actually remove itself from the network. To really force a node out of the network (black listing) we need to do key refresh.

    Your Key refresh sequence looks good. There is  a little bit more info in this case.

Reply
  • Hi Spiderman :)   

    Are you sure "config_client_node_reset" is to remove all nodes in the network that receive the message ? 

    Note that "config_client_node_reset" is used by configuration client model. And configuration model use device key as its app key. Each device has its own unique devicekey that distributed when propositioning. So there will be only one device can process the reset command from the configuration client. 

    However, there isn't a way to be really sure that the node that receive the config_client_node_reset() would actually remove itself from the network. To really force a node out of the network (black listing) we need to do key refresh.

    Your Key refresh sequence looks good. There is  a little bit more info in this case.

Children
  • ok, so if I'm going through the key refresh approach then might be the following scenario will be hit:

    During the key refresh procedure might be some of the node(s) are power down or out of network, then they are not able to receive the new network key & when they resume the network unable to communicate with other nodes.

    so how should I prevent such case or any workaround for this scenario?

  • Hi sorry for late response. 

    The key refresh procedure is handled by the configuration client that uses the device key to talk to each node to distribute the new network key( and appkeys if any). If a node is not available, the configuration client shall not continue until all node receive the new key (phase 2). It should retry until all nodes receive new key.

    Please have a look at section 3.10.4 in the spec. 

    There is a possibility that a node is inactive for a long time when the key refresh is underway and it can halt the procedure for long time. Network administrator can configure so that those nodes should be marked as inactive and blacklisted as well so that the procedure can be carried on. 

Related