But my point is that SmartThings hub groups have a suggested maximum separation between hubs of about ten feet (?), and in practice it can be significantly less. Even by UK standards that can mean they are all in the same room.
It isn’t obvious why they have this limited separation but one could speculate that it has something to do with the secondaries doing Thread, Zigbee, or Z-Wave routing themselves. However that doesn’t necessarily add any value if you already have strong meshes. If the secondaries just could just act as standby ‘hub replace’ candidates and TBRs they could potentially be located much further apart.
Guess we’ll have to revisit this topic when we’ll see in real-life what it is. I guess reading the white paper only once is not enough.
What is TREL - Summary <- click here
Use cases at the end…
What is TREL?
Thread Radio Encapsulation Link (TREL) is a protocol defined in the Thread 1.4 specification that enables the encapsulation of IEEE 802.15.4 MAC frames within UDP/IPv6 packets. This allows Thread network messages—originally designed for low-power, low-data-rate wireless personal area networks (WPANs) using 802.15.4 radios—to traverse high-speed IP-based infrastructure networks, such as Wi-Fi or Ethernet, while remaining fully compatible with existing Thread devices. Once the packets reach their destination, they are de-encapsulated back into standard 802.15.4 frames, ensuring seamless integration into the Thread mesh topology.
In essence, TREL acts as a “virtual radio link” over IP infrastructure, treating Ethernet or Wi-Fi connections as extensions of the Thread mesh. It is a core enabler of the “Thread over Infrastructure” feature in Thread 1.4, allowing Border Routers (BRs) and other Thread devices with IP-capable interfaces to incorporate these links into the overall network. TREL-capable devices automatically discover each other using DNS-SD (DNS Service Discovery) on the IPv6 network, establishing peer relationships without manual configuration. This discovery process advertises and resolves service records for TREL endpoints, enabling them to exchange encapsulated packets.
TREL was introduced to address limitations in traditional Thread networks, where connectivity relies solely on 802.15.4 radios, which can suffer from range constraints, interference, or partitioning in large or complex environments. By bridging to IP backbones, TREL extends the mesh’s reach and resilience.
How TREL Works
TREL operates at the link layer, integrating with Thread’s Multi-PHY (Physical Layer) framework, which allows devices to use multiple radio technologies simultaneously. Here’s a step-by-step breakdown:
Encapsulation and Message Formats:
An 802.15.4 MAC frame (e.g., a Thread data packet) is wrapped in a UDP/IPv6 packet. The TREL header includes fields for versioning, packet type (unicast, multicast/broadcast, or acknowledgment), channel information, source/destination addresses (EUI-64), sequence numbers, and the encapsulated frame payload.
For unicast messages, the header optimizes for point-to-point delivery. Broadcasts include flags to indicate multi-hop handling.
Security is preserved: TREL inherits 802.15.4’s MAC-layer encryption and frame counters, and derives a separate MAC key for TREL-specific communications to ensure end-to-end protection.
Peer Discovery and Connection:
Devices on the same IPv6 link (e.g., Ethernet segment) use DNS-SD to browse for “_trel._udp” services, registering their own IPv6 addresses and ports as TREL endpoints.
Once discovered, peers are added to a local TREL peer table, which tracks active connections (up to a configurable capacity, e.g., via OPENTHREAD_CONFIG_TREL_MAX_PEERS in OpenThread).
No dedicated TREL “handshake” is needed; communication begins immediately upon peer resolution.
Transmission and Reception:
When the Multi-PHY layer selects an IP-based PHY (e.g., Wi-Fi over 802.15.4), the stack routes the frame via TREL: it encapsulates the packet, sends it over UDP/IPv6 to the peer’s address/port, and the receiver de-encapsulates it.
Acknowledgments use lightweight TREL Ack packets, leveraging IPv6’s inherent reliability to avoid redundant 802.15.4 ACKs.
MTU (Maximum Transmission Unit) is dynamically negotiated based on the path (e.g., reducing for 6LoWPAN headers) to prevent fragmentation and optimize bandwidth.
Multi-PHY Integration:
Thread’s Radio Selector (in OpenThread) dynamically chooses the “best” PHY per neighbor based on preference scores. These scores update via transmission history: successful TX/RX boosts the score for that link (e.g., Wi-Fi gets higher preference for its capacity), while failures decrease it. Probes periodically test links.
Broadcasts (critical for discovery) are sent over all PHYs, including TREL, while unicasts prefer the highest-scoring link (with ties broken by capacity or power profile).
In non-partitioned meshes, TREL still adds value by enabling “direct” neighbor relationships over IP, reducing hops even if 802.15.4 paths exist.
Error Handling and Reliability:
Retransmissions follow Thread’s MAC-layer rules but adapt to IP’s hop-by-hop delivery.
Counters track inbound/outbound packets, bytes, and failures for diagnostics.
Benefits of TREL
TREL addresses key pain points in Thread deployments by hybridizing low-power mesh with high-speed infrastructure:
Enhanced Connectivity and Resilience: Prevents partitioning by “gluing” disjoint 802.15.4 segments via IP links, making the mesh self-healing and more robust in sparse or obstructed environments.
Improved Performance: Offloads traffic from congested 802.15.4 channels to high-capacity backbones (e.g., Wi-Fi’s 100s of Mbps vs. 802.15.4’s 250 kbps), reducing latency, hops, and congestion. Dynamic MTU and preference-based routing optimize this further.
Energy Efficiency: Battery-powered Thread devices (e.g., sensors) conserve power by shortening paths; Mesh Extenders handle less relay traffic.
Scalability and Coverage: Extends range in large areas without dense 802.15.4 repeaters, leveraging existing wired/wireless infrastructure for broader IoT deployments.
Cost Savings: Reuses installed IP networks (e.g., home Ethernet), reducing need for dedicated Thread hardware.
In non-partitioned scenarios, TREL still boosts throughput by preferring IP for high-volume links, treating distant nodes as “immediate neighbors.”
Use Cases
TREL shines in scenarios where Thread’s low-power mesh needs augmentation by reliable, high-bandwidth infrastructure:
Large-Scale Smart Homes: In multi-story homes, TREL lets BRs on different floors communicate over Ethernet/Wi-Fi, bridging coverage gaps for lights, locks, and thermostats. Avoids “dead zones” without extra 802.15.4 extenders.
Commercial Building Automation: For offices or hotels, integrate Thread HVAC/sensors with building Ethernet, routing control traffic over wired backbones to minimize wireless interference and ensure low-latency alerts.
Outdoor/Industrial IoT: In smart agriculture or campus monitoring, sparse 802.15.4 nodes connect via long-range Wi-Fi hotspots, enabling reliable data from remote soil sensors or gates without full mesh density.
Hybrid Multi-Radio Gateways: BRs with Wi-Fi/802.15.4 use TREL for “remote radio” emulation, offloading video/sensor streams to IP while keeping low-power control on 802.15.4.
Partition-Prone Environments: Factories with metal barriers or urban smart grids, where TREL ties radio-isolated clusters, ensuring failover for critical safety systems.
Basically extending the L1/L2 Thread radio network between different disconnected pockets of the same Thread network over an IP network. In fact, Cisco did a similar thing to unify disparate first responder radio systems with their IPICS (IP Integrated Communications) platform back in late 2000’s.
Still no sign of the hub v4 on Amazon uk.
I spotted this though on Slovakian site smarterhome.sk. It’s a fair bit cheaper than uk, even after adding 30€ postage to uk
There’s a chance you could be hit with a VAT charge on import though, which might be another £13 which would take a chunk out the savings.
It’s possibly supplied without a UK plug which would be annoying. The release date is supposedly 20th-30th October, I expect it should show up on amazon uk by then.
I recall that being typically the case 15-20 years ago, although I haven’t looked at it much in the interim: whatever something would cost here in USD, the price in the UK would be about the same number in GBP…
I just want to throw my hat into the discussion regarding the lack of Z-Wave support out of the box.
Many (most?) of my devices are Z-Wave, they’re generally very reliable. I am still buying Z-Wave devices up to today!
I also register my support for the possibility of using the USB-A port at the back of the new hub to add a Z-Wave stick for those of us that want/need to continue with Z-Wave into the future. Although, I expect that this design decision would have already been made, so all we can do now is hope and wait and see.
