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!

[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.

[Edvin]

I don't see why that would be necessary, and why not just reading it out would be just as good, but I can check with our Thread team.

I'll let you know when I hear from them.

Best regards,

Edvin

[Edvin]

Hello,

I received a reply today:

In case you have full control of the Thread network, you can pre-commission the devices with specific Mesh Local Prefix by using the function:

otThreadSetMeshLocalPrefix() (https://github.com/openthread/openthread/blob/master/include/openthread/thread.h#L457 )

This API has to be called before the interface and Thread is brought up.

On Border Router, if you want to change the default Mesh Local Prefix in the /etc/border_router.conf file, please execute "wpanctl leave & sudo reboot", or else the NCP will use the Operational Dataset stored in the flash.

Please remember that in a regular network, the Mesh Local Prefix might be randomly chosen, and all devices receive the Operational Dataset (which includes the Mesh Local Prefix) during the Commissioning process. We don't have built in support for automatic change of the GatewayUDP6Broadcast value in the paho_mqttsn_gateway.conf gile. What you can do is to implement a small script wich will react on changes of MeshLocalPrefiz from wpantund/wpanctl and adjust the value of the GatewatUDP6Broadcast field and restart the Paho MWTT-SN gateway.

Another alternative could be to subscribe to some random multicast address on all MQTT-SN client devices, including SEDs (e.g. FF03::cafe) using the "otIp6SubscribteMulticastAddress" API (https://github.com/openthread/openthread/blob/master/include/openthread/ip6.h#L307 ) and then use this address in the GatewayUDP6Broadcast field. This way, you won't be dependent on the MeshLocalPrefix, but at the same time you will create a proprietary solution.

BR,

Edvin