Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

[MarcoLG]

Hello,

i have been struggling with this issue for several days now, maybe due to my limited knowledge of thread networks.

I'm developing a solution where some devices (based on the NRF52840) wake up several (once, twice or something like that) times a day, connect to a MQTT-SN gateway and send some data they recorded during the day. The MQTT-SN is part of the Nordic Border Router on a raspberry pi (last image available at the moment, 4.1.0-1alpha).

As long as i understand, the MQTT-SN gateway configuration includes a "GatewayUDP6Broadcast" address used to broadcast the gateway ipv6 address to clients during the discovery procedure.

I configured my end devices as sleepy end devices (setting  radio_mode = THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE in thread_configuration_t structure), therefore the standard multicast address ff03::1 will not work for the GatewayUDP6Broadcast. Instead, I read in the thread protocol specification that i need to use a special realm-local unicast prefix-based multicast  address that is derived from the mesh local prefix (chapter 5.2.3.2 of thread specification, v. 1.1.1).

Since i need to hardcode such address in the MQTT-SN gateway configuration file, i need to force a known mesh-local prefix in my thread network.

However, I was unable to do so. I tried to set the thread_on_mesh_prefix to the prefix I want to use in /etc/border_router.conf file, but it didn't work...

I managed to obtain some results by using wpanctl form command with -M <mesh_prefix>, however this solution did not work all the times (i don't know why) and was not very robust to reboots of the raspberry. 

Can you please give me some advice on this matter? I'm not even sure that this is the correct approach for this kind of issues.

Thanks!

[Edvin]

Hello,

So the devices are not connected to the network most of the time, but from time to time you want to send messages from the border router to the nodes (when they wake up?). Is that correct?

I don't know if it is possible to predict the addresses, since this is decided when the network is formed, I guess. How about storing the assigned addresses when the nodes connect to the network? Did you try something like this?

What is your plan for the messages that you try to send out to all nodes when nodes are not connected to the network? Is the plan to store them until they wake up, or to send to the devices that are awake at this point in time?

To be honest, I don't know the answer to your questions by heart, but perhaps if I understand the use case scenario, I can check with our Thread team.

Best regards,

Edvin

[Edvin]

I configured my end devices as sleepy end devices (setting  radio_mode = THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE in thread_configuration_t structure),

 Does this mean that the nodes have a parent node that is always awake, or do you disconnect from the network, and reconnect once of twice per day?