Problem on Thread use extaddr to locate a End Device

211 views
Skip to first unread message

yinzhou tao

unread,
May 25, 2021, 5:32:29 AM5/25/21
to openthread-users
Hi All,

I want to synchronize the cloud platform to know whether the End Device is still connected to the OTBR's Thread network in an IPv4 environment.

The End Device is usually in a deep sleep, and OPENTHREAD_CONFIG_MLE_CHILD_TIMEOUT_DEFAULT is set to 60, so the gateway can know whether the Thread of the End Device is still alive. I want to use extaddr as the identifier. The End Device will report EUI64 and SN to the cloud platform. I changed extaddr to be the same value as EUI64. By looking at the extaddr field in OTBR's child table, I can identify to the corresponding End Device. The OTBR can then report to the cloud platform whether the End Device is still connected or not. This is done by setting extaddr after the commissioning process completes. The code is shown below: 

微信图片_20210525105841.png

During my testing, I found that sometimes when I looked at the child table from the OTBR, the extaddr of the End Device was a random value instead of the value I set. I know extaddr is a random value by intentional, but Rloc16 seems to be more inaccessible to use as a device unique identification. Therefore, mark a specific device in the thread topology, I can only use extaddr to establish a connection with Rloc16 in OTBR's child table.

I want to know why the extaddr sometimes changed after I modified it. Or is there any other way for the platform to be able to locate the specific End Device through the gateway? 

Jonathan Hui

unread,
May 25, 2021, 1:04:09 PM5/25/21
to yinzhou tao, openthread-users
If you are using a cloud service, I think just reporting the EUI-64 to the cloud service and not changing the MAC Extended Address and/or IPv6 address is the better approach. You can always map the EUI-64 to the IPv6 address using information in the cloud. The MAC Extended Address is intentionally chosen at random during commissioning to help prevent device tracking. Also, the IPv6 address may change depending on how the overall IPv6 network is configured.

--
Jonathan Hui



--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/298a19ac-f788-4582-a293-08b86bdb7c3fn%40googlegroups.com.
Message has been deleted

yinzhou tao

unread,
May 26, 2021, 9:47:34 AM5/26/21
to openthread-users
Hi Jonathan,

Thank you for your reply. 

I fully understand that this is intentional. But there is a special reason for this. The background is that the cloud needs to be notified within a few minutes of a thread End Device being offline in an IPv4 internet connection through OTBR's NAT64. 

Since the End Device has low power consumption and the heartbeat sent to the cloud platform is calculated by day. So the only way to judge whether a thread End Device is still connected is to the observer whether there is End Device information in the child table from OTBR. Only Rloc16 and extaddr in OTBR's child table are suitable for identifying a Thread Child device. Therefore, I tried to changed extaddr to be the same value as EUI64, so that The OTBR can observe the device and report it to the cloud. In fact, it is the same as the End Device reporting EUI64 to the cloud as you said, but for the purpose of low power consumption, the information of the End Device is collected through OTBR.

I also tried the command Eidcache, which is explained in the documentation as "Print the eid-to-rloc cache entries". The code looks like it prints each set of RLOC and IPv6 addresses. Is it refer to the RLOC and IPv6 addresses of other end devices under this OTBR? If so, would that solve the problem? 

Thanks again.

Best,
Tao

Jonathan Hui

unread,
May 26, 2021, 4:13:46 PM5/26/21
to yinzhou tao, openthread-users
Thread is a mesh network. If you have Thread routers in your network, the SEDs may not be directly attached to OTBR. In this case, observing the child table would not be sufficient to determine the liveness of a Thread device.

I think the best way to determine liveness is to have the SED send a message periodically to whatever is monitoring the liveness (OTBR, cloud, etc.). The payload of that message can include whatever identifier is most convenient for you.

--
Jonathan Hui



yinzhou tao

unread,
May 27, 2021, 7:18:35 AM5/27/21
to openthread-users

If you have Thread routers in your network, the SEDs may not be directly attached to OTBR

We do have other OTBRs in our environment, and each OTBR regularly reports its child table to the cloud, so even if the SED jumps to a different OTBR, it will still be perceived by the cloud platform. The main difficulty is how to accurately locate a SED according to the child tables reported from OTBRs. Therefore, I think use eidcache might be a good idea?

I think the best way to determine liveness is to have the SED send a message periodically to whatever is monitoring the liveness (OTBR, cloud, etc.). The payload of that message can include whatever identifier is most convenient for you.

Thanks for the suggestion but it cannot be implement in the actual use of this product. Because the SED is a smoke detector, in order to save battery, if there is no fire, it may not send any message to the cloud platform for a long time. The background is that the cloud needs to be notified within a few minutes of a thread End Device being offline, which is an IPv4 internet connection through OTBR's NAT64 with no IPv6 direct connection capability. So, I want to get the online status from the topology diagram from OTBRs.


Thanks in advance.

Best,
Tao

Jonathan Hui

unread,
May 27, 2021, 2:13:43 PM5/27/21
to yinzhou tao, openthread-users
A SED maintains its liveness in the parent's child table by sending a message periodically to its parent. The period is based on the child timeout configuration.

When the SED attaches, it could send a single message to OTBR so that OTBR knows the mapping between EUI-64 and IPv6 address. Then OTBR can monitor if/when the child is removed based on the IPv6 address and report the removal to the cloud.

With this model, the energy would still be dominated by the SED periodically communicating with the parent to maintain its child status.

--
Jonathan Hui



Reply all
Reply to author
Forward
0 new messages