WO2025185678A1

WO2025185678A1 - Method for remotely controlling a matter device

Info

Publication number: WO2025185678A1
Application number: PCT/CN2025/080898
Authority: WO
Inventors: Hrishikesh DHAYAGUDE; Chirag ATAL; Piyush Shah; Kedar Sovani
Original assignee: Espressif Systems Shanghai Co Ltd
Current assignee: Espressif Systems Shanghai Co Ltd
Priority date: 2024-03-08
Filing date: 2025-03-06
Publication date: 2025-09-12
Anticipated expiration: 2026-09-08
Also published as: WO2025185678A8; CN121058221A

Abstract

A method for remotely controlling a Matter device is provided which includes establishing a tunnel between a forwarder device and a remote client terminal; receiving, by the forwarder device via the tunnel, a first message from the remote client terminal, where the first message may include a header, and the header may include a device ID of a target Matter device as a destination address; querying, by the forwarder device, a discovery table to determine an IP address corresponding to the device ID of the target Matter device; generating, by the forwarder device, a new header having an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replacing the header of the first message with the new header to obtain a second message; and transmitting, by the forwarder device, the second message to the target Matter device.

Description

METHOD FOR REMOTELY CONTROLLING A MATTER DEVICE

FIELD OF THE INVENTION

The present invention relates generally to the field of IoT network, and in particular, relates to a method for remotely controlling a Matter device.

BACKGROUND

Matter is a new standard for smart home technology launched by the Connectivity Standards Alliance (CSA) . Matter is an open-source connectivity standard that aims to improve the compatibility and security of IoT devices. Matter protocol is based on Internet Protocol (IP) . Matter devices run locally over Wi-Fi, Ethernet or Thread (IEEE 802.15.4) and do not rely on an internet connection

Matter devices are devices that can implement the Matter protocol and can communicate with each other in a Matter network. For example, a Matter device can be a light, a door lock or a video player, which provides a function or service according to their physical properties. A client terminal in a Matter network refers to a node that can perform interactions with other Matter devices by sending commands, reading and writing attributes, or subscribing to events. A client terminal may be a smartphone, a tablet, or a voice assistant. For example, one example of a client terminal is a smart home controller, where the smart home controller may act as a client terminal and send a command to toggle the state of a smart light bulb.

A client terminal normally communicates with Matter devices via a local network. However, there is still a problem in the current situation with Matter protocol, where it is unsolved how to remotely control a Matter device by a client device. For example, a user may want to control a Matter light bulb in their home from a Matter smartphone app in their office, or a user may want to monitor a Matter security camera in their vacation house from a Matter-enabled tablet. These scenarios require a reliable and secure way to establish a connection between the remote client terminal and the Matter device, and to transmit commands and data between them.

As the current technical specification of Matter protocol does not talk about remote control, there is a need for a new method and system to remotely control a Matter device via a remote Matter client terminal, which can overcome the limitations and challenges of the existing methods and provide better user experience and performance.

SUMMARY

In order to overcome the defects in the existing art, the present invention provides a novel way of implementing a method for remotely controlling a Matter device. The method allows local discovery of Matter devices performed by a forwarder device. The method also supports local management of communication reliability on a forwarder device, which ensures retransmission by adjusting the timeouts on the Matter client terminal according to the network conditions. The method according to the present disclosure further enables a mechanism for demultiplexing data from Matter devices to various Matter clients, which route and distribute data transmission from multiple remote Matter client terminals, such as different apps, to multiple Matter devices based on the device type, user preference, or context etc.

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

In a first general aspect, a method for remotely controlling a Matter device is provided which includes establishing a tunnel between a forwarder device and a remote client terminal. Method may also include receiving, by the forwarder device via the tunnel, a first message from the remote client terminal, where the first message may include a header, and the header may include a device ID of a target Matter device as a destination address. Method may furthermore include querying, by the forwarder device, a discovery table to determine an IP address corresponding to the device ID of the target Matter device. Method may in addition include generating, by the forwarder device, a new header having an address of the forwarder device as a source address and an IP address corresponding to the device ID of the target Matter device as a destination address, and replacing the header of the first message with the new header to obtain a second message. Method may moreover include transmitting, by the forwarder device, the second message to the target Matter device. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The header of the first message further may include a remote ID of the remote client terminal as a source address, and the method further may include: assigning, by the forwarder device, an UDP port for the remote ID of the remote client terminal; and transmitting, by the forwarder device, the second message to the target Matter device via the assigned UDP port.

Preferably, the first message further comprises an encrypted payload which is decryptable only by the target Matter device.

Preferably, the established tunnel between the forwarder device and the remote client terminal is a secure tunnel built on a cloud.

The method may further include: receiving, by the forwarder device, a response message from the target Matter device via the assigned UDP port; and, transmitting, by the forwarder device via the tunnel, the response message to the remote client terminal.

The method may further include: retransmitting, by the forwarder device, the second message to the target Matter device within a predefined time window.

The method may further include: in response to no response message being received from the target Matter device within the predefined time window, transmitting, by the forwarder device, a notification message to the remote client terminal.

Method may include: receiving a subscription request message from a remote client terminal; forwarding the subscription request message to a target Matter device via an assigned UDP port based on the destination address in the header of subscription request message; receiving, by the forwarder device, a subscription response message from a Matter device via the assigned UDP port; and, transmitting, by the forwarder device, the subscription response message to the remote client terminal, where the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.

Implementations of the described techniques may include hardware, a method or process, or a computer tangible medium.

In a second general aspect, a system for remotely controlling Matter devices is provided, which may include at least one remote client terminal, a forwarder device, and at least one Matter device, wherein the forwarder device is configured to: establish a tunnel between a forwarder device and a remote client terminal; receive a first message from the remote client terminal via the tunnel, where the first message may include a header, and the header may include a device ID of a target Matter device as a destination address; query a discovery table to determine an IP address corresponding to the device ID of the target Matter device; generate a new header having an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replace the header of the first message with the new header to obtain a second message, and transmit the second message to the target Matter device.

Implementations may include one or more of the following features. The header of the first message further may include a remote ID of the remote client terminal as a source address, and the forwarder device is further configured to: assign an UDP port for the remote ID of the remote client terminal; and transmit the second message to the target Matter device via the assigned UDP port.

Preferably, the first message further may include an encrypted payload which is decryptable only by the target Matter device.

Preferably, the forwarder device is further configured to: receive a response message from the target Matter device via the assigned UDP port; and transmit the response message to the remote client terminal via the tunnel.

Preferably, the forwarder device is further configured to retransmit the second message to the target Matter device within a predefined time window.

Preferably, the forwarder device is further configured to transmit a notification message to the remote client terminal in response to no response message being received from the target Matter device within the predefined time window.

Preferably, the forwarder device is further configured to: receive a subscription request message from a remote client terminal; forward the subscription request message to a target Matter device via an assigned UDP port based on the destination address in the header of subscription request message; receive a subscription response message from a Matter device via the assigned UDP port; and transmit the subscription response message to the remote client terminal, where the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.

In a fourth general aspect, a forwarder device is provided, which may include a processor and a memory, where the memory contains instructions executable by the processor so that the forwarder device is operative to perform the method according to any of the solutions. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

In a further general aspect of the present disclosure, a non-transient computer storage medium storing a computer program is provided, where the computer program when being executed by a processor causes the processor to perform the actions of the methods. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

The present disclosure enables a local discovery mechanism that allows a remote client terminal to control a Matter device in a local Matter network. By managing transmission reliability on the forwarder device, the present disclosure also provides a fine-tuning mechanism of retransmission timeouts on remote Matter client terminals, which improves the communication effectiveness and efficiency. Furthermore, the present disclosure provides demultiplexing data from Matter devices to various remote Matter client terminals, so that a remote Matter client terminal will receive only the data packets that they are interested in, and avoid unnecessary or redundant data transmissions.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the present disclosure will be further explained on the basis of embodiments with reference to the attached drawings.

Fig. 1 schematically illustrates a diagram of a network structure including a Matter network, a forwarder device, and a plurality of remote client terminals.

Fig. 2 schematically illustrates a flowchart of an example process 200 of the method according to the present disclosure.

Fig. 3 schematically illustrates a flowchart of a specific implementation of a method provided by the present disclosure for remotely controlling a Matter device by a remote client terminal.

Fig. 4 schematically illustrates another flowchart of a specific implementation of a method provided by the present disclosure for handling retransmissions.

Fig. 5 schematically illustrates a flowchart of an implementation of the method according to the present disclosure for a Matter device to set up a subscription relationship with the remote client terminal via a forwarder device.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The method implemented in a Matter network and a system therefore according to the present disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments shown in the accompanying drawings and described hereinafter are merely illustrative and not intended to limit the disclosure. In addition, it should be understood that in this disclosure, ordinal words such as "first" , "second" , "third" , etc., unless explicitly specified or determined by the technical context, are used only to indicate different or identical elements in the technical solution, and do not imply any limitation on the order or importance of those elements.

Matter is a new smart home standard that aims to enable interoperability and compatibility among different brands and ecosystems of smart devices. Fig. 1 illustrates a diagram of a network structure, which includes a Matter network (also called Matter Fabric) , a forwarder device, and a plurality of remote client terminals, where the Matter network consists of a plurality of Matter devices and a local client terminal, the forwarder device is connected to the devices within the Matter network, and the forwarder device is further connected to a plurality of remote client terminals. According to the present disclosure, a forwarder device may be a hub, a smart speaker, or any other entity, e.g., even one of the local Matter devices, in the same local network as the other Matter devices. Typically, a Matter device can be a headless physical device that has connectivity and can provide services. For instance, Matter devices can be either end devices, such as lights, sensors, speakers, displays, or cameras, or routers, such as hubs or bridges, that relay messages between end devices. Examples of a client terminal include smartphones, tablets, laptops, and smart speakers.

Currently, the plurality of Matter devices shares a same security domain and can communicate with each other securely, and the client terminal can access, control and/or monitor Matter devices and services based on the authentication and authorization level of the user that is logged into the local client terminal. However, it remains unsolved how to remotely control Matter devices in a local Matter network with a remote client terminal, while ensuring security and reliability.

In the present disclosure, a method implemented by a forwarder device is provided to remotely control a Matter device. Fig. 2 is a flowchart of an example process 200 of the method according to the present disclosure. In some implementations, one or more process blocks of Fig. 2 may be performed by a forwarder device. Whenever a Matter client terminal initiates communication with a target Matter device that is currently not in the same network (i.e., the Matter client terminal is a remote client terminal) , the process 200 described above will be triggered to enable remote control of the target Matter device by the Matter client terminal.

As shown in Fig. 2, process 200 may include step 202: establishing a tunnel between a forwarder device and a remote client terminal. In a preferred embodiment, the tunnel established is a secure tunnel built on a cloud platform. The secure tunnel enables an end-to-end transmission of Matter data between the remote client terminal and the forwarder device, without exposing the data to any intermediate nodes or servers. Matter data refers to any messages that conform to the Matter protocol. As the established tunnel is an end-to-end tunnel, it means that even the cloud will not be able to understand the actual data being transmitted from the remote client terminal to the Matter device, as the data is encrypted with cryptography according to the Matter protocol.

As also shown in Fig. 2, process 200 may include step 204: receiving, by the forwarder device via the tunnel, a first message from the remote client terminal, where the first message may include a header, and the header may include a device ID of a target Matter device as a destination address.

In a preferred embodiment, the communication framework between the remote client terminal and the forwarder device is based on a command-response architecture. For example, the remote client terminal and the forwarder device exchange commands and responses using a predefined format and protocol.

As an example, the commands are used to control the transmission of data between the clients and the forwarder, wherein the command format may be a JSON object with the following fields:

“cmd” : a string that specifies the type of command. The possible values of “cmd” include: transmit, transmitResponse, and other customized command types.

“value” : a string that contains the data to be transmitted, in this example, the value can be the Matter data that the remote client terminal intends to send to a target Matter device in a local network, where the Matter data is encoded by base64 encoding.

“reliable” : a boolean that indicates whether the transmission requires reliability or not. This field is optional and defaults to false. This field will be set as true when reliability is required. If the reliability is required, a retransmission and time-out mechanism, as per the Matter specification, will be enabled in the forwarder device which is described in detail in the below Example 2.

An example of the command sent from the remote client terminal to the forwarder device is provided below:

As a further example, a “transmit” command is used when the remote client terminal sends data to the forwarder device, where the value field contains the data in Base64 encode format and the reliable field indicates whether the client expects an acknowledgement from the forwarder or not. A “transmitResponse” command is used to acknowledge the receipt of data from the forwarder device, where the value field contains the status of the transmission and the reliable field is ignored for this command.

Table 1 provides an example of a first message format sent from a remote client terminal to a forwarder device is adapted from a standard Matter message format, including the following fields:

For example, according to Table 1, the device ID of the target Matter device is specified in the field [Destination Node ID] in the Message Header.

As defined by the Matter protocol, a Matter communication requires private keys from the NOC (Node Operational Certificate) to be used for generating messages. As an example, the remote client terminal keeps its private key within itself. Whenever the Matter client is on the local network, it gets the Node IDs of all the Matter devices in the network. The Matter client terminal will remember this information for remote access even when it becomes a remote client terminal.

In a preferred embodiment, the first message further includes an encrypted payload which is decryptable only by the target Matter device. In particular, as the data sent from the remote client terminal is encrypted with a cryptography mechanism according to the Matter protocol, only the target Matter device to which the data is intended can decrypt the data. Therefore, even the cloud platform that hosts the secure tunnel will not be able to access or understand the actual data being sent over the tunnel. This ensures the privacy and security of the Matter data when transmitting data from a remote client terminal to a Matter device.

As further shown in Fig. 2, process 200 may include step 206: querying, by the forwarder device, a discovery table to determine an address corresponding to the device ID of the target Matter device. For example, the forwarder device parses the header of the first message to obtain the device ID of the target Matter device, without the need to decrypt the encrypted payload of the first message. Instead, the forwarder device simply send the payload of the first message to the target Matter device. In an example, a device ID is a 64-bit number that uniquely identifies every Matter device in the Matter fabric.

In a preferred embodiment, the forwarder device maintains an mDNS cache and identifies the device ID of the target Matter device by looking it up in the mDNS cache. For example, the mDNS is a local storage area that temporarily stores and keeps track of the device ID and UDP addresses of the Matter devices iin the Matter network.

In an alternative embodiment, the forwarder device determines the UDP address corresponding to the device ID of the target Matter device by performing an mDNS discovery. For instance, the mDNS discovery may be a process of broadcasting query messages to all the Matter devices in the Matter network to identify the target Matter device with the queried device ID. The corresponding target Matter device will then respond with a message that includes its UDP address, which the forwarder device can use to forward the first message. The forwarder will also update its mDNS cache with the new information. This way, the forwarder can efficiently route packets within the local Matter network.

As also shown in Fig. 2, process 200 may include step 208: generating, by the forwarder device, a new header having an address of the forwarder device as a source address and the UDP address corresponding to the device ID of the target Matter device as a destination address, and replacing the header of the first message with the new header to obtain a second message.

Preferably, the header of the first message further comprises a remote ID of the remote client terminal as a source address.

Preferably, the process 200 further includes: assigning a UDP port for the remote ID of the remote client device; and transmitting the second message to the target Matter device via the assigned UDP port. For example, when the forwarder device transmits the second message, the source address of the second message is the UDP address of the forwarder device, and the destination address of the second message is the address of the target Matter device identified in step 206.

Process 200 may include additional implementations, such as any single implementation or any combination of implementations described below and/or in connection with one or more other processes described elsewhere herein.

As further shown in Fig. 2, process 200 may include step 210: transmitting the second message to the target Matter device. For example, the forwarder device may, according to the IP address of the target Matter device, transmit the second message to the target Matter device, as described above.

In a preferred embodiment, a retransmission mechanism is designed between the forwarder device and the Matter device for local management of reliability. The retransmission mechanism is implemented through the following steps 210 (a) and 210 (b) .

Optionally, the process 200 may further include step 210 (a) : retransmitting the second message to the target Matter device within a predefined time window.

Optionally, the process 200 may further include step 210 (b) : transmitting a notification message to the remote client terminal in response to no response message being received from the target Matter device within the predefined time window.

As an example, the notification message sent from the forwarder device to the remote client terminal when timing out may take the below format:

As illustrated in dashed bloc in Fig. 2, optionally, the process 200 may include step 212: receiving a response message from the target Matter device via the assigned UDP port; and transmitting the response message via the tunnel to the remote client terminal.

For example, when a response message is generated by the target Matter device, the response message will be received by the forwarder device. Upon receiving the response message, the forwarder device will, according to the UDP port through which the response message is received, determine the corresponding remote client terminal to which the response message shall be forwarded to.

Another important feature of Matter is the ability to send and receive notifications when a device setting changes. For example, a Matter light bulb can notify other devices when it is turned on or off, or when its brightness or color changes. Similarly, a Matter thermostat can notify other devices when it adjusts the temperature or switches between heating and cooling modes. These notifications allow other devices to react accordingly, such as displaying the current status on a user interface or triggering an automation routine.

In an example, a remote terminal subscribing to a Matter device will receive an update from the Matter device which notifies the setting changes on the Matter device.

For a Matter device to set up a subscription relationship with the remote client terminal via a forwarder device, the process 200 implemented by the forwarder device may further include: receiving a subscription response message from a Matter device via a UDP port; and, transmitting the subscription response message to a remote client terminal, wherein the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.

This means that the subscriber device, e.g., the remote client terminal, sends a request to the publisher device, e.g., a Matter device, indicating which settings it wants to be notified about. The publisher device then accepts or rejects the subscription request, and sends a subscription response message to the subscriber device. Once the subscription is established, the publisher will send a notification message to the subscriber device whenever the subscribed setting changes. According to the embodiment of the present disclosure, the response message will be transmitted via the forwarder device, and the forwarder device will look up in its cache based on the UDP port through which the response message is received to determine the remote ID of the targeted remote client terminal. The forwarder device will demultiplex the response message and send it to the targeted remote client terminal.

Example 1: Discovery of Local Matter Device and Identification of Response Message Destination by the Forwarder Device

Fig. 3 illustrates a specific implementation of the method according to the present disclosure for remotely controlling a Matter device by a remote client terminal. In this example, the remote client terminal wants to communicate with a Matter device located in a local network that is connected to the forwarder device. The steps are as follows:

Step 301: Establishing a tunnel between a forwarder device and a remote client terminal.

Step 302: The remote client terminal sends a first message via the established tunnel to the forwarder device. The first message contains the Matter Node ID of the Matter device in the header.

Step 303: The forwarder device queries a discovery table to determine an IP address corresponding to the device ID of the target Matter device. It can be understood that the discovery step is performed by the forwarder device by looking up the Matter Node ID of the destined Matter device from the unencrypted part of the first message generated by the remote client terminal.

Step 304: The forwarder device generates a new header comprising an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replaces the header of the first message with the new header to obtain a second message. As a result, the header of the second message indicates the IP address of the Matter device as the destination and the IP address of the forwarder device as the source.

Step 305: The forwarder device transmits the second message to the target Matter device identified in Step 304.

Step 306: The forwarder device receives a response message from the target Matter device via the assigned UDP port within a predefined time window.

Step 307: The forwarder device transmits the response message to the remote client terminal via the tunnel, where the remote client terminal is determined based on the UDP port of the forwarder device through which the response message is received. As described in above embodiments, every remote client terminal is assigned with a unique remote ID and the forwarder device reserves a set of outbound UDP ports designated for forwarding messages received from remote client terminals. For instance, when the forwarder device receives a message from a remote client terminal, it will allocate a UDP port to this remote client terminal. The forwarder device will maintain a table of local UDP port versus remote ID mappings. In a preferred configuration, the forwarder device will flush the mapping table to a persistent storage area so that the UDP port –ID mappings will not change even after power reset events. Whenever the forwarder device transmits the data received from the remote client terminal, it will always use the local UDP port designated for this remote client terminal. By this configuration, it is ensured that when the forwarder device receives a corresponding response from the target Matter device, the response message will be received on the same UDP port. This way, the forwarder device can then look up the mapping table to identify the remote ID corresponding to the UDP port, and subsequently send the response message to the correct remote client terminal.

Example 2: Retransmission Mechanism

Fig. 4 illustrates another specific implementation of the method according to the present disclosure for handling retransmissions between a remote client terminal and a Matter device via a forwarder device. In this example, in particular, a retransmission mechanism is implemented in the forwarder device. The steps are as follows:

Step 401: Establishing a tunnel between a forwarder device and a remote client terminal.

Step 402: The remote client terminal sends a first message via the established tunnel to the forwarder device. The first message contains the Matter Node ID of the Matter device in the payload.

Step 403: The forwarder device queries a discovery table to determine an IP address corresponding to the device ID of the target Matter device. It can be understood that the discovery step is performed by the forwarder device by looking up the Matter Node ID of the destined Matter device from the unencrypted part of the first message generated by the remote client terminal.

Step 404: The forwarder device generates a new header comprising an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replaces the header of the first message with the new header to obtain a second message. As a result, the header of the second message indicates the IP address of the Matter device as the destination and the IP address of the forwarder device as the source.

Step 405: The forwarder device transmits the second message to the target Matter device identified in Step 304.

Step 406: The forwarder device retransmits the second message to the target Matter device at a predefined interval. Advantageously, retransmissions are handled by the forwarder device locally, so that the remote client terminal does not need to perform retransmissions over the tunnel. As an example, in order to enable the retransmission mechanism which is to be implemented by the forwarder device, the remote client terminal can set the “reliable” field in the JSON format message it sends out as “true” . After receiving the message, the forwarder device will check the “reliable” field and decide whether to perform Reliability Protocol handling or not.

Step 407: The forwarder device sends a notification message to the remote client terminal via the tunnel in response to that no response message has been received from the target Matter device within a predefined time window.

In a preferred embodiment, as the data exchange takes place through a tunnel built on a cloud, the remote client terminals may relax the timing requirements to an extent.

Example 3: Establish Subscription

Fig. 5 illustrates an implementation of the method according to the present disclosure for a Matter device to set up a subscription relationship with the remote client terminal via a forwarder device. The process may include the following steps:

Step 501: The remote client terminal sends a subscription request message to the forwarder device via the established tunnel.

Step 502: The forwarder device queries a discovery table to determine an IP address corresponding to the device ID of the target Matter device. It can be understood that the discovery step is performed by the forwarder device by looking up the Matter Node ID of the destined Matter device from the unencrypted part of the first message generated by the remote client terminal.

Step 503: The forwarder device generates a new header comprising an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replaces the header of the subscription message with the new header to obtain a second message. As a result, the header of the second message indicates the IP address of the Matter device as the destination and the IP address of the forwarder device as the source.

Step 504: The forwarder device transmits the second message to the target Matter device identified in Step 503.

Step 505: The forwarder device receives a subscription response message from the target Matter device via the assigned UDP port within a predefined time window.

Step 506: The forwarder device transmits the subscription response message to the remote client terminal via the tunnel, where the remote client terminal is determined based on the UDP port of the forwarder device through which the subscription response message is received.

After the subscription is established between the remote client terminal and the Matter device, whenever the subscribed setting changes, in Step 507, the Matter device will send a notification message to the forwarder device via the assigned UDP port.

Step 508: The forwarder device will then transmit the notification message to the remote client terminal via the tunnel, and similarly as in Step 506, the remote client terminal is determined based on the UDP port of the forwarder device through which the notification message is received.

To enable secure and reliable communication between Matter devices through a forwarder, a CASE (Chip Authentication Session Establishment) session needs to be established. A CASE session is a cryptographic protocol that allows two Matter devices to authenticate each other and establish a shared secret key for encrypting and decrypting messages. A CASE session can be initiated by either device, and involves exchanging certificates, signatures, and random numbers. In the case of subscription, a CASE session between the remote client terminal and the Matter device has already been established through the forwarder device, for example, by the process illustrated in Fig. 3. Thus, the forwarder device already has a reverse lookup entry for the UDP port to the remote ID of the remote client terminal. The forwarder device will demultiplex the subscription response message and send it to the targeted remote client terminal.

As another embodiment, a system is provided in the present disclosure, which includes at least one remote client terminal, a forwarder device, and at least one Matter device, wherein the forwarder device and the at least one Matter device are in a local network.

The forwarder device is configured to: establish a tunnel between a forwarder device and a remote client terminal; receive a first message from the remote client terminal via the tunnel, wherein the first message comprises a header, and the header comprises a device ID of a target Matter device as a destination address; query a discovery table to determine an IP address corresponding to the device ID of the target Matter device; generate a new header comprising an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replace the header of the first message with the new header to obtain a second message; and, transmit the second message to the target Matter device.

In a preferred embodiment, the header of the first message further includes a remote ID of the remote client terminal as a source address, and the forwarder device is further configured to: assign a UDP port for the remote ID of the remote client terminal; and transmit the second message to the target Matter device via the assigned UDP port.

In a preferred embodiment, the first message further includes an encrypted payload which is decryptable only by the target Matter device.

In a preferred embodiment, the established tunnel between the forwarder device and the remote client terminal is a secure tunnel built on a cloud.

In a preferred embodiment, the forwarder device is further configured to: receive a response message from the target Matter device via the assigned UDP port; and transmit the response message to the remote client terminal via the tunnel.

Preferably, the forwarder device is further configured to: receive a subscription response message from a Matter device via a UDP port; and transmit the subscription response message to a remote client terminal, wherein the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.

As another embodiment, a forwarder device is provided in the present disclosure, which includes a processor and a memory, wherein the memory contains instructions executable by the processor so that the forwarder device is operative to perform the method according to any of the above embodiments.

As another embodiment, a non-transient computer-readable storage medium is provided in the present disclosure, which stores instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above embodiments.

The present disclosure relates is designed to enable remote control of Matter devices by one or more remote client terminals. The solutions according to the present invention allow a remote Matter client to communicate with local Matter devices that are located on a local network via a forwarder device. By performing an end-to-end tunnelling of Matter data between the remote client terminal and the forwarder device, the data is encrypted with Matter’s cryptography and only the target Matter device can decrypt it. This enhances the security and privacy of communication. The present disclosure also ensures reliable and timely delivery of data between the remote Matter client and the Matter device, by using a forwarder device that acts as a proxy, and can adjust the retransmission timeouts based on the network conditions and the device capabilities. Moreover, it enables multiple Matter clients to control and monitor the same Matter device, by using a demultiplexing mechanism in the forwarder device, which can route the data from the Matter device to the appropriate Matter client, based on the mapping of UDP ports and remote ID of remote client terminals.

The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications may be made in light of the above disclosure or may be acquired from practice of the implementations. As used herein, the term “component” is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It will be apparent that systems and/or methods described herein may be implemented in different forms of hardware, firmware, and/or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods are described herein without reference to specific software code -it being understood that software and hardware can be used to implement the systems and/or methods based on the description herein. As used herein, satisfying a threshold may, depending on the context, refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, and/or the like, depending on the context. Although particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

Although each dependent claim listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set. No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more. ” Further, as used herein, the article “the” is intended to include one or more items referenced in connection with the article “the” and may be used interchangeably with “the one or more. ” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and/or the like) , and may be used interchangeably with “one or more. ” Where only one item is intended, the phrase “only one” or similar language is used. Also, as used herein, the terms “has, ” “have, ” “having, ” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Also, as used herein, the term “or” is intended to be inclusive when used in a series and may be used interchangeably with “and/or, ” unless explicitly stated otherwise (e.g., if used in combination with “either” or “only one of” ) .

It should be understood that the above method and system in a Matter network are provided as examples only and are not limitations of the present disclosure. Those skilled in the art should understand that the principles of the present disclosure can be applied to systems and methods other than the above-described sharing control in a Matter network without departing from the scope of the present disclosure. While various embodiments of various aspects of the disclosure have been described for the purpose of the disclosure, it shall not be understood that the teaching of the disclosure is limited to these embodiments. The features disclosed in a specific embodiment are therefore not limited to that embodiment, but can be combined with the features disclosed in different embodiments. For example, one or more features and/or operations of the method according to the present disclosure described in one embodiment can also be applied individually, in combination or as a whole in another embodiment. Descriptions of the system/device embodiments are equally applicable to method embodiments, and vice versa. It can be understood by those skilled in the art that more optional embodiments and variations are possible, and that various changes and modifications can be made to the system described above, without departing from the scope defined by the claims of the present disclosure.

Claims

A method for remotely controlling a Matter device, the method being implemented by a forwarder device, the method comprising:

establishing a tunnel between the forwarder device and a remote client terminal;

receiving a first message from the remote client terminal via the tunnel, wherein the first message comprises a header, and the header comprises a device ID of a target Matter device as a destination address;

querying a discovery table to determine an IP address corresponding to the device ID of the target Matter device;

generating a new header comprising an address of the forwarder device as a source address and an IP address corresponding to the device ID of the target Matter device as a destination address, and replacing the header of the first message with the new header to obtain a second message; and

transmitting the second message to the target Matter device.
The method according to claim 1, wherein the header of the first message further comprises a remote ID of the remote client terminal as a source address, and the method further comprises:

assigning a UDP port for the remote ID of the remote client terminal; and

transmitting the second message to the target Matter device via the assigned UDP port.
The method according to claim 1, wherein the first message further comprises an encrypted payload which is decryptable only by the target Matter device.
The method according to claim 1, wherein the established tunnel between the forwarder device and the remote client terminal is a secure tunnel built on a cloud.
The method according to claim 2, further comprising:

receiving a response message from the target Matter device via the assigned UDP port; and

transmitting the response message to the remote client terminal via the tunnel.
The method according to claim 1, further comprising:

retransmitting, by the forwarder device, the second message to the target Matter device within a predefined time window.
The method according to claim 6, further comprising:

transmitting a notification message to the remote client terminal in response to no response message being received from the target Matter device within the predefined time window.
The method according to claim 1, further comprising:

receiving a subscription request message from a remote client terminal;

forwarding the subscription request message to a target Matter device via an assigned UDP port based on the destination address in the header of subscription request message;

receiving a subscription response message from a Matter device via the assigned UDP port; and

transmitting the subscription response message to the remote client terminal, wherein the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.
A system, comprising at least one remote client terminal, a forwarder device, and at least one Matter device, wherein the forwarder device and the at least one Matter device are in a local network,

wherein, the forwarder device is configured to:

- establish a tunnel between a forwarder device and a remote client terminal;

- receive a first message from the remote client terminal via the tunnel, wherein the first message comprises a header, and the header comprises a device ID of a target Matter device as a destination address;

- query a discovery table to determine an IP address corresponding to the device ID of the target Matter device;

- generate a new header comprising an address of the forwarder device as a source address and the IP address corresponding to the device ID of the target Matter device as a destination address, and replace the header of the first message with the new header to obtain a second message; and

- transmit the second message to the target Matter device.
The system according to claim 9, wherein the header of the first message further comprises a remote ID of the remote client terminal as a source address, and the forwarder device is further configured to:

- assign a UDP port for the remote ID of the remote client terminal; and

- transmit the second message to the target Matter device via the assigned UDP port.
The system according to claim 9, wherein the first message further comprises an encrypted payload which is decryptable only by the target Matter device.
The system according to claim 9, wherein the established tunnel between the forwarder device and the remote client terminal is a secure tunnel built on a cloud.
The system according to claim 10, wherein the forwarder device is further configured to:

- receive a response message from the target Matter device via the assigned UDP port; and

- transmit the response message to the remote client terminal via the tunnel.
The system according to claim 9, wherein the forwarder device is further configured to retransmit the second message to the target Matter device within a predefined time window.
The system according to claim 14, wherein the forwarder device is further configured to transmit a notification message to the remote client terminal in response to no response message being received from the target Matter device within the predefined time window.
The system according to claim 9, wherein the forwarder device is further configured to:

- receive a subscription request message from a remote client terminal;

- forward the subscription request message to a target Matter device via an assigned UDP port based on the destination address in the header of subscription request message;

- receive a subscription response message from a Matter device via the assigned UDP port; and

- transmit the subscription response message to the remote client terminal, wherein the remote client terminal is determined in response to the UDP port being assigned for the remote ID of the remote client terminal.
A forwarder device, comprising:

a processor and a memory, wherein the memory contains instructions executable by the processor so that the forwarder device is operative to perform the method according to any of claims 1 to 8.
A non-transient computer-readable storage medium, storing instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 8.