Thread Radio Encapsulation Link (TREL) use case

[agners]

Hello,

I am trying to understand the reasons why Thread Radio Encapsulation Link (TREL) has been added. From what I understand, it allows border routers to exchange IEEE 802.15.4 packets through a backbone link (e.g. Ethernet). TREL capable routers do so automatically via DNS-SD discovery.

But why is it needed in first place? What is the exact use case behind it? If two border routers are on the same mesh network, shouldn't the packets make it through the mesh network anyhow?

One thing which comes to mind is to avoid partitioning, essentially tie together Thread networks which lost connectivity on radio level. Are there use cases beyond that?

Reading through logs it seems to be related to multiradio support as well, where TREL essentially operates like a "remote radio". Is this being done to lower the load on the mesh network?

From what I understand multiradio tries to select the "best" radio for any given destination. I was wondering how is "best" determined here, from the commit log it seems this is based on successful transmissions (from ffb3fdf, the commit when it has been first introduced):

This commit adds a new class RadioSelector which selects the radio
link for each message transmission. Per neighbor it tracks the
supported radio types and a preference value for each type.
RadioSelector updates the preference value based on the history of
rx/tx events with the neighbor, e.g., a successful tx on a radio link
increases the preference, whereas a failed tx attempt decreases it.

If the mesh network is not partitioned, any neighbor will be reachable from any radio, and those counter will be the same. It seems to me that TREL doesn't really add a benefit in the not partitioned case, is this correct?

Best regards,
Stefan

[abtink]

Hi @agners ,

The main idea is to allow BRs (or in general any Thread device) that has other IP-based links (e.g. WiFi) to incorporate it into the Thread mesh topology. This allows Thread network to leverage the benefits of the other links, e.g. higher throughout, capacity, coverage etc.

Basically it helps make the Thread mesh more connected

• Which then helps avoid with network partitioning (as you mentioned).
• It also can help reduce traffic over 15.4 radio allowing BRs to talk to each other over their higher capacity WiFi link.

---

If the mesh network is not partitioned, any neighbor will be reachable from any radio, and those counter will be the same. It seems to me that TREL doesn't really add a benefit in the not partitioned case, is this correct?

Mesh network will be more connected. We can have nodes that may not be directly connected on 15.4 now see it each other as immediate neighbor over their TREL (WiFi) link.

From what I understand multiradio tries to select the "best" radio for any given destination. I was wondering how is "best" determined here

Short/simple version is:

• We track a "preference" value per radio link (for each neighbor) which is updated as we rx and tx frames over the radio (and through a "probe mechanism").
• If there are multiple radio links (all with good/same preference value) then there is an order to use, e.g. higher capacity links (WiFI) is preferred over 1.54 radio on routers.

There are more details in 1.3 spec and/or in the OT implementation (the RadioSelector module and in particular its RadioSelector::SelectRadio() method).

[lancersky2017]

So, If we want to support TREL, we need to enable OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE both on RCP firmware and ot-br-posix. Is that so?

[jwhui]

TREL feature only needs to be enabled on host side. TREL does not require any code on the RCP itself.

[lancersky2017]

It's great. Thanks for the clarification.

[haitao52198]

is trel need firewall config , which port used?

[jwhui]

By default, TREL uses UDP ports in the ephemeral range.