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?

[MarcoLG]

Hello,

no it is basically the opposite.

The border router (which includes the mqttsn gateway) is alway on and forms the thread network when it boots up. It is the only router node in the network.

The other devices sleep most of the day (they are not connected and in low power mode) and periodically wake up. When they wake up, they try to connect to the network, then try to discover the mqttsn gateway, connect to it and finally publish some content. Then, they return to sleep.

What i'm observing is that when a device wakeup, it connects to the thread network as child (as expected), then it broadcasts a mqttsn gateway search packet to the multicast address  ff03::1. The problem, now, is that when the gateway responds to this message, it should broadcast the response to the realm-local unicast prefix-based multicast  address in order for the message to be forwarder to the child node during the next poll (the child, as i said, is configured with THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE so it will not receive messages sent to ff03::1). The unicast prefix-based address, on the other hand, depends on the thread mesh local prefix, which i have been unable to set. When the router forms the network, it sets a mesh local prefix that appears randomly generated. As a consequence, I don't know how to set the GatewayUDP6Broadcast option in the border router mqttsn gateway config file.

Just to be as clear as possible, i'm referring to the "IPv6:MeshLocalPrefix" => "fdc0:de1a:b5c0::/64" that appears when i write "sudo wpanctl status" after forming the thread network. See the below command output:

pi@raspberrypi:~ $ sudo wpanctl status
wpan0 => [
"NCP:State" => "associated"
"Daemon:Enabled" => true
"NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
"Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
"Config:NCP:DriverName" => "spinel"
"NCP:HardwareAddress" => [F4CE366E33AE613F]
"NCP:Channel" => 11
"Network:NodeType" => "leader"
"Network:Name" => "MSquare-Test"
"Network:XPANID" => 0xC0DE1AB5C0DE1AB5
"Network:PANID" => 0xABCD
"IPv6:LinkLocalAddress" => "fe80::1cb9:e183:e22c:3816"
"IPv6:MeshLocalAddress" => "fdc0:de1a:b5c0:0:efd2:518b:d2c8:c4c3"
"IPv6:MeshLocalPrefix" => "fdc0:de1a:b5c0::/64"
"com.nestlabs.internal:Network:AllowingJoin" => false
]

[Edvin]

So I assume that your border router is using a dongle or a DK to communicate with the mesh network, right? You want to be able to fetch this IPv6:MeshLocalPrefix from your border router without using the wpanctl status command from your command line, but using a CLI command, is that correct?

If so, did you try to use the "dataset" command after forming the network?

Please see the guide on how to form the network:
https://infocenter.nordicsemi.com/topic/sdk_tz_v3.2.0/thread_ot_commissioning_configuring.html?cp=7_7_1_2_7_5_0_0_2#thread_ot_commissioning_configuring_on-mesh_cli_forming

Let me know if this is not what you are looking for.

Best regards,

Edvin

[MarcoLG]

I don't want to fetch the IPv6:MeshLocalPrefix, i want to set it to a predetermined value, so that i can hardcode it into the paho_mqttsn_gateway.conf file under the GatewayUDP6Broadcast option.