Outbound HTTPS/MQTT via Thread Border Router—Supported?

[ysato]

We are currently considering developing a device (Matter over Thread) that can be linked with Google Nest Hub(Matter compatible).

We basically plan to use Matter's functionality, but if possible, we would like to communicate with our server (HTTPS/MQTT, etc.) via your smart speaker from our device. (For example, for log collection.)

Based on our internal testing with the system configuration shown in the diagram below, it appears that this can be achieved with Google Nest Hub.
Therefore, if possible, could you please provide us with the following information, to the extent that you are comfortable disclosing (public information level)?

[Questions]
1. When using a smart speaker (Thread Border Router), is the following outbound communication to an external server a use case that is expected and permissible according to the specifications? (Is it safe to consider this a standard function?)

2. If it is an expected use case, which of the following patterns ① or ② is expected? (Or are both expected?)

3. If it is not currently expected, but may be restricted in the future, please briefly explain the reason.

If this is outside of Mr. Hatanaka's area of ​​expertise, I would be very grateful if you could forward/introduce me to the person (or contact person) who is more familiar with this matter.

Thank you for your cooperation.

[arm_dpe · Accepted solution]

1. Is outbound communication to an external server a permissible use case?

Yes. This is an expected and standard function of a Thread Border Router (TBR).

By definition, a Thread Border Router’s primary job is to provide connectivity between the IEEE 802.15.4 Thread network (where your device lives) and the adjacent IP network (Wi-Fi/Ethernet and, by extension, the Internet).

• Standard Function: Matter devices are IPv6-based. When a device uses "Matter over Thread," it is a full-fledged IP device. The Nest Hub acts as a gateway at the Network Layer (Layer 3).
• Permissibility: There is nothing in the Matter specification that forbids a device from maintaining a secondary non-Matter connection (like HTTPS/MQTTS to your cloud) for telemetry, logging, or firmware updates.
  
  2. Which pattern is expected?

In the context of a Google Nest Hub and standard Thread networking, Pattern A is the primary expected behavior.

In this scenario, the Nest Hub acts as a transparent bridge/router.

• Your device sends an IPv6 packet destined for your server's IP.
• The Nest Hub receives the radio signal (Thread) and passes the IP packet onto the Wi-Fi/Ethernet network.
• This utilizes the native IP capabilities of Thread. Your device manages its own HTTPS/MQTTS stack. The Nest Hub doesn't need to "know" what is inside the packet; it just routes it.

Pattern B is generally not how standard Thread Border Routers work for third-party traffic.

• In Pattern B, the Smart Speaker would need a "translator" or "agent" application specifically designed to ingest your device's data and re-upload it.
• While Google provides APIs for Matter (the Matter SDK), they do not typically allow third-party developers to run custom "conversion" code directly on the Nest Hub hardware for generic data logging.
• Conclusion: You should design for Pattern A. Your device should implement its own MQTTS/HTTPS client and use the Nest Hub simply as the path to the internet
  
  3. Potential future restrictions or considerations

While Pattern A is standard today, there are two areas where you might face "restrictions" (though these are usually security features rather than arbitrary bans):

• IPv6/IPv4 Transition: Most cloud servers still use IPv4. Since Thread is strictly IPv6, the Nest Hub must support NAT64/DNS64 to allow your device to talk to an IPv4 server. Google Nest Hubs generally support this, but it is a dependency you must verify for your specific target environments.
• Sleepy End Devices (SEDs): If your device is battery-powered and "sleeps" frequently, maintaining a persistent MQTTS connection can be difficult. You will need to ensure your logging intervals align with the Thread polling cycles to keep the connection active and prevent the Nest Hub from disconnecting the device.

[ysato]

Thank you for your response.

I have a much better understanding of the relationship between smart speakers (Echo Hub) and Thread Border Routers.

I would like to ask you further questions in the future.