Method for remotely controlling MATTER equipment

Abstract

The invention provides a method for remotely controlling Matter equipment. The method comprises the following steps: establishing a tunnel between repeater equipment and a remote client; receiving, by the repeater device, a first message from the remote client via the tunnel, where the first message may include a header, and the header may include a device ID of the target Matter device as a destination address; querying, by the repeater device, the discovery table to determine an IP address corresponding to the device ID of the target Matter device; generating, by the repeater device, a new header having the address of the repeater 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, by the repeater device, the second message to the target Matter device.

Description

Technical Field

[0001] This invention relates generally to the field of IoT networks, and more particularly to a method for remotely controlling Matter devices. Background Technology

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

[0003] Matter devices are devices that implement the Matter protocol and can communicate with each other within a Matter network. For example, a Matter device can be a light, a door lock, or a video player, providing functionality or services based on its physical characteristics. A client in a Matter network is a node that can interact with other Matter devices by sending commands, reading and writing attributes, or subscribing to events. Clients can be smartphones, tablets, or voice assistants. For example, an example of a client is a smart home controller, which can act as a client and send commands to toggle the status of smart light bulbs.

[0004] Clients typically communicate with Matter devices via a local network. However, under the current Matter protocol, a problem remains: how to remotely control Matter devices from a client device has not been resolved. For example, a user might want to control a Matter light bulb in their home via a Matter smartphone app in their office, or a user might want to monitor Matter security cameras in a vacation home via a Matter-enabled tablet. These scenarios require a reliable and secure way to establish a connection between the remote client and the Matter device and to transmit commands and data between them.

[0005] Since the current technical specifications of the Matter protocol do not mention remote control, a new method and system are needed to remotely control Matter devices via a remote Matter client, which can overcome the limitations and challenges of existing methods and provide a better user experience and performance. Summary of the Invention

[0006] To overcome the shortcomings of existing technologies, this invention provides a novel implementation of a method for remotely controlling Matter devices. This method allows local discovery of Matter devices to be performed by a repeater device. The method also supports local management of communication reliability on the repeater device, which ensures retransmission by adjusting timeouts on the Matter client according to network conditions. The method according to this disclosure also implements a mechanism for demultiplexing data from Matter devices to various Matter clients, which routes and distributes data transmissions from multiple remote Matter clients (e.g., different applications) to multiple Matter devices based on device type, user preferences, or context.

[0007] A system of one or more computers can be configured to perform a specific operation or action by means of software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform actions during operation. One or more computer programs can be configured to perform a specific operation or action by means of instructions that, when executed by a data processing device, cause the device to perform the action.

[0008] In a first general aspect, a method for remotely controlling a Matter device is provided, comprising establishing a tunnel between a repeater device and a remote client. The method may further include the repeater device receiving a first message from the remote client via the tunnel, wherein the first message may include a header, and the header may include a device ID of the target Matter device as a destination address. The method may further include the repeater device querying a discovery table to determine an IP address corresponding to the device ID of the target Matter device. The method may further include the repeater device generating a new header with the repeater device's address as the source address and the IP address corresponding to the device ID of the target Matter device as the destination address; and replacing the header of the first message with the new header to obtain a second message. The method may further include the repeater device transmitting 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 method.

[0009] The implementation may include one or more of the following features. The header of the first message may also include the remote ID of the remote client as the source address, and the method may further include: the repeater device allocating a UDP port for the remote client's remote ID; and the repeater device transmitting the second message to the target Matter device via the allocated UDP port.

[0010] Preferably, the first message also includes an encrypted payload that can be decrypted only by the target Matter device.

[0011] Preferably, the tunnel established between the repeater device and the remote client is a secure tunnel built on the cloud.

[0012] The method may further include: receiving a response message from the target Matter device via an assigned UDP port by the repeater device; and transmitting the response message to the remote client via a tunnel by the repeater device.

[0013] The method may also include: the repeater device retransmitting the second message to the target Matter device within a predefined time window.

[0014] The method may further include: in response to the failure to receive a response message from the target Matter device within a predefined time window, the repeater device transmits a notification message to the remote client.

[0015] The method may include: receiving a subscription request message from a remote client; forwarding the subscription request message to a target Matter device via an allocated UDP port based on the destination address in the header of the subscription request message; receiving a subscription response message from the Matter device via the allocated UDP port by a forwarder device; and transmitting the subscription response message to the remote client by the forwarder device, wherein the remote client determines the UDP port in response to allocating a remote ID for the remote client.

[0016] Implementation of the technology may include hardware, methods or processes, or a tangible computer medium.

[0017] In a second general aspect, a system for remotely controlling a Matter device is provided, which may include at least one remote client, a repeater device, and at least one Matter device, wherein the repeater device is configured to: establish a tunnel between the repeater device and the remote client; receive a first message from the remote client via the tunnel, wherein the first message may include a header, and the header may include a device ID of the 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 that uses the repeater's address 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.

[0018] The implementation may include one or more of the following features. The header of the first message may also include the remote ID of the remote client as the source address, and the repeater device is further configured to: allocate a UDP port for the remote client's remote ID; and transmit the second message to the target Matter device via the allocated UDP port.

[0019] Preferably, the first message may also include an encrypted payload that can be decrypted only by the target Matter device.

[0020] Preferably, the tunnel established between the repeater device and the remote client is a secure tunnel built on the cloud.

[0021] Preferably, the repeater device is also configured to: receive response messages from the target Matter device via an assigned UDP port; and transmit the response messages to the remote client via a tunnel.

[0022] Preferably, the repeater device is also configured to retransmit the second message to the target Matter device within a predefined time window.

[0023] Preferably, the repeater device is further configured to transmit a notification message to the remote client in response to not receiving a response message from the target Matter device within a predefined time window.

[0024] Preferably, the repeater device is further configured to: receive a subscription request message from a remote client; forward the subscription request message to a target Matter device via an allocated UDP port based on the destination address in the header of the subscription request message; receive a subscription response message from the Matter device via the allocated UDP port; and transmit the subscription response message to the remote client, wherein the remote client determines the UDP port in response to allocating a remote ID for the remote client.

[0025] The implementation of the technology may include hardware, methods or processes, or a tangible computer medium.

[0026] In a fourth general aspect, a repeater device is provided that may include a processor and a memory, wherein the memory contains instructions executable by the processor, enabling the repeater device to operate to perform a method according to any solution. 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 actions of a method.

[0027] In another general aspect of this disclosure, a non-transitory computer storage medium is provided for storing a computer program, wherein the computer program, when executed by a processor, causes the processor to perform the actions of a method. 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 a method.

[0028] This disclosure implements a local discovery mechanism that allows remote clients to control Matter devices in a local Matter network. By managing transmission reliability on the repeater device, this disclosure also provides a fine-tuning mechanism for retransmission timeouts on remote Matter clients, which improves the effectiveness and efficiency of communication. Furthermore, this disclosure provides a method for demultiplexing data from Matter devices to various remote Matter clients, ensuring that remote Matter clients receive only the packets they are interested in and avoiding unnecessary or redundant data transmission. Attached Figure Description

[0029] In the following, this disclosure will be further explained based on embodiments with reference to the accompanying drawings.

[0030] Figure 1 A schematic diagram of the network structure, including the Matter network, repeater devices, and multiple remote clients, is shown.

[0031] Figure 2 A flowchart of an example process 200 according to the method of this disclosure is shown schematically.

[0032] Figure 3 A flowchart illustrating a specific implementation of the method for remotely controlling a Matter device by a remote client, as provided in this disclosure, is shown schematically.

[0033] Figure 4 Another flowchart illustrating a specific implementation of the retransmission processing method provided in this disclosure is shown schematically.

[0034] Figure 5 A flowchart illustrating an implementation of a method for a Matter device to establish a subscription relationship with a remote client via a repeater device according to the present disclosure is shown schematically. Detailed Implementation

[0035] The method implemented in the Matter network and its system according to the present disclosure will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments shown in the drawings and described below are merely illustrative and are not intended to limit the present disclosure. Furthermore, it should be understood that in this disclosure, ordinal numbers such as "first," "second," and "third," unless expressly 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 these elements.

[0036] Matter is a new smart home standard designed to enable interoperability and compatibility between smart devices from different brands and ecosystems. Figure 1 A network architecture diagram is shown, comprising a Matter network (also known as Matter Fabric), repeater devices, and multiple remote clients. The Matter network consists of multiple Matter devices and local clients. The repeater devices are connected to devices within the Matter network and are also connected to multiple remote clients. According to this disclosure, the repeater device can be a hub, smart speaker, or any other entity located on the same local network as other Matter devices, such as even one of the local Matter devices. Typically, a Matter device can be a headless physical device with connectivity and the ability to provide services. For example, a Matter device can be an end device, such as a light, sensor, speaker, display, or camera, or a router, such as a hub or bridge relaying messages between end devices. Examples of clients include smartphones, tablets, laptops, and smart speakers.

[0037] Currently, multiple Matter devices share the same security domain and can communicate securely with each other. Clients can access, control, and / or monitor Matter devices and services based on the authentication and authorization level of the user logged into the local client. However, how to remotely control Matter devices in a local Matter network using a remote client while ensuring security and reliability remains unresolved.

[0038] This disclosure provides a method for remotely controlling a Matter device implemented by a repeater device. Figure 2 This is a flowchart of an example process 200 according to the method of this disclosure. In some embodiments, Figure 2 One or more process blocks can be executed by the repeater device. Whenever the Matter client initiates communication with a target Matter device that is not currently on the same network (i.e., the Matter client is a remote client), the above process 200 will be triggered to enable the Matter client to remotely control the target Matter device.

[0039] like Figure 2 As shown, process 200 may include step 202: establishing a tunnel between the repeater device and the remote client. In a preferred embodiment, the established tunnel is a secure tunnel built on a cloud platform. The secure tunnel enables end-to-end transmission of Matter data between the remote client and the repeater device without exposing the data to any intermediate nodes or servers. Matter data refers to any message conforming to the Matter protocol. Because the established tunnel is an end-to-end tunnel, this means that even the cloud will not be able to understand the actual data transmitted from the remote client to the Matter device, as the data is cryptographically encrypted according to the Matter protocol.

[0040] For example Figure 2 As shown, process 200 may include step 204: receiving a first message from a remote client via a tunnel by a repeater device, wherein the first message may include a header, and the header may include the device ID of the target Matter device as a destination address.

[0041] In a preferred embodiment, the communication framework between the remote client and the repeater device is based on a command-response architecture. For example, the remote client and the repeater device exchange commands and responses using predefined formats and protocols.

[0042] As an example, this command is used to control data transmission between the client and the repeater, where the command format can be a JSON object with the following fields:

[0043] "cmd": A string that specifies the command type. Possible values ​​for "cmd" include: transmit, transmitResponse, and other custom command types.

[0044] "value": A string containing the data to be transmitted. In this example, the value could be Matter data that a remote client intends to send to a target Matter device on the local network, where the Matter data is encoded using base64 encoding.

[0045] "reliable": A boolean value indicating whether reliability is required for the transmission. This field is optional and defaults to false. This field will be set to true when reliability is required. If reliability is required, retransmission and timeout mechanisms will be enabled in the repeater device according to the Matter specification, which will be described in detail in Example 2 below.

[0046] Below is an example of a command sent from a remote client to a repeater device:

[0047] As another example, when a remote client sends data to a repeater device, it uses the "Transfer" command, where the value field contains the Base64 encoded data and the reliable field indicates whether the client expects acknowledgment from the repeater. The "Transfer Response" command is used to acknowledge receipt of data from the repeater device, where the value field contains the transmission status, and the reliable field is ignored for this command.

[0048] Table 1 provides an example of the first message format sent from a remote client to a repeater device, which is adapted from the standard Matter message format and includes the following fields:

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

[0050] As defined by the Matter protocol, Matter communication requires the use of a private key from the NOC (Node Operational Certificate) to generate messages. As an example, a remote client stores its private key within itself. Whenever a Matter client is on the local network, it obtains the node IDs of all Matter devices on the network. Even when becoming a remote client, the Matter client remembers this information for remote access.

[0051] In a preferred embodiment, the first message also includes an encrypted payload that can be decrypted only by the target Matter device. Specifically, since the data sent from the remote client is encrypted using cryptographic mechanisms according to the Matter protocol, only the target Matter device to which the data is intended can decrypt it. Therefore, even the cloud platform hosting the secure tunnel cannot access or understand the actual data sent through the tunnel. This ensures the privacy and security of Matter data when transmitting data from the remote client to the Matter device.

[0052] like Figure 2 As further shown, process 200 may include step 206: the repeater device queries a discovery table to determine the address corresponding to the device ID of the target Matter device. For example, the repeater device parses the header of the first message to obtain the device ID of the target Matter device without decrypting the encrypted payload of the first message. Instead, the repeater device simply sends the payload of the first message to the target Matter device. In one example, the device ID is a 64-bit number that uniquely identifies each Matter device in the Matterfabric.

[0053] In a preferred embodiment, the repeater device maintains an mDNS cache and identifies the device ID of the target Matter device by looking up information in the mDNS cache. For example, mDNS is a local storage area that temporarily stores and tracks the device IDs and UDP addresses of Matter devices in the Matter network.

[0054] In an alternative embodiment, the repeater device determines the UDP address corresponding to the device ID of the target Matter device by performing mDNS discovery. For example, mDNS discovery could be a process of broadcasting a query message to all Matter devices in the Matter network to identify the target Matter device with the queried device ID. The corresponding target Matter device then responds with a message including its UDP address, which the repeater device can use to forward the first message. The repeater also updates its mDNS cache with the new information. In this way, the repeater can efficiently route packets within the local Matter network.

[0055] For example Figure 2 As shown, process 200 may include step 208: generating a new header by the repeater device, the new header using the address of the repeater device as the source address and the UDP address corresponding to the device ID of the target Matter device as the destination address; and replacing the header of the first message with the new header to obtain the second message.

[0056] Preferably, the header of the first message also includes the remote client's remote ID as the source address.

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

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

[0059] like Figure 2 As further shown, process 200 may include step 210: transmitting the second message to the target Matter device. For example, the repeater device may transmit the second message to the target Matter device based on the IP address of the target Matter device, as described above.

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

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

[0062] Optionally, process 200 may also include step 210(b): in response to not receiving a response message from the target Matter device within a predefined time window, transmitting a notification message to the remote client.

[0063] As an example, when a timeout occurs, the notification message sent from the repeater device to the remote client can take the following format:

[0064] like Figure 2 As shown in the dashed block, process 200 may optionally include step 212: receiving a response message from the target Matter device via the assigned UDP port; and transmitting the response message to the remote client via a tunnel.

[0065] For example, when the target Matter device generates a response message, this response message will be received by the repeater device. Upon receiving the response message, the repeater device will determine the appropriate remote client to which the response message should be forwarded, based on the UDP port through which it received the response message.

[0066] Another important feature of Matter is its ability to send and receive notifications when device settings change. 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 its temperature or switches between heating and cooling modes. These notifications allow other devices to react accordingly, such as displaying the current status on the user interface or triggering automated routines.

[0067] In one example, a remote terminal subscribed to a Matter device will receive an update from the Matter device that notifies the device of a setting change.

[0068] In order for the Matter device to establish a subscription relationship with a remote client via the repeater device, the process 200 implemented by the repeater device may further include: receiving a subscription response message from the Matter device via a UDP port; and transmitting the subscription response message to the remote client, wherein the remote client is determined in response to the UDP port assigned to the remote client's remote ID.

[0069] This means that a subscriber device (e.g., a remote client) sends a request to a publisher device (e.g., a Matter device) indicating which settings it wants to be notified of. The publisher device then accepts or rejects the subscription request and sends a subscription response message to the subscriber device. Once a subscription is established, the publisher will send a notification message to the subscriber device whenever the subscribed settings change. According to embodiments of this disclosure, the response message is transmitted via a repeater device, and the repeater device determines the remote ID of the target remote client by looking up in its cache based on the UDP port through which the response message was received. The repeater device then demultiplexes the response message and sends it to the target remote client.

[0070] Example 1: The repeater device discovers the local Matter device and identifies the destination of the response message.

[0071] Figure 3 A specific implementation of a method for remotely controlling a Matter device by a remote client according to this disclosure is shown. In this example, the remote client wants to communicate with a Matter device located on a local network and connected to a repeater device. The steps are as follows:

[0072] Step 301: Establish a tunnel between the repeater device and the remote client.

[0073] Step 302: The remote client sends a first message to the repeater device via the established tunnel. The first message contains the Matter node ID of the Matter device in its header.

[0074] Step 303: The repeater device queries the discovery table to determine the IP address corresponding to the device ID of the target Matter device. Understandably, the discovery step is performed by the repeater device by looking up the Matter node ID of the target Matter device from the unencrypted portion of the first message generated by the remote client.

[0075] Step 304: The repeater device generates a new header, which includes the repeater device's address as the source address and the IP address corresponding to the device ID of the target Matter device as the destination address. The new header replaces the header of the first message to obtain the second message. Therefore, the header of the second message indicates that the Matter device's IP address is the destination and the repeater device's IP address is the source.

[0076] Step 305: The repeater device transmits the second message to the target Matter device identified in step 304.

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

[0078] Step 307: The repeater device transmits the response message to the remote client via a tunnel, wherein the remote client is determined based on the UDP port on which the repeater device received the response message. As described in the above embodiments, each remote client is assigned a unique remote ID, and the repeater device maintains a set of outbound UDP ports designated for forwarding messages received from remote clients. For example, when the repeater device receives a message from a remote client, it will assign a UDP port for that remote client. The repeater device will maintain a table mapping local UDP ports to remote IDs. In a preferred configuration, the repeater device will flush the mapping table to persistent storage so that the UDP port-ID mapping does not change even after a power reset event. Whenever the repeater device transmits data received from a remote client, it will always use the local UDP port designated for that remote client. This configuration ensures that when the repeater device receives a corresponding response from the target Matter device, the response message will be received on the same UDP port. Thus, the repeater 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.

[0079] Example 2: Retransmission Mechanism

[0080] Figure 4 Another specific embodiment of the method for handling retransmissions between a remote client and a Matter device via a repeater device according to this disclosure is shown. In this example, in particular, a retransmission mechanism is implemented in the repeater device. The steps are as follows:

[0081] Step 401: Establish a tunnel between the repeater device and the remote client.

[0082] Step 402: The remote client sends a first message to the repeater device via the established tunnel. The first message contains the Matter node ID of the Matter device in its payload.

[0083] Step 403: The repeater device queries the discovery table to determine the IP address corresponding to the device ID of the target Matter device. Understandably, the discovery step is performed by the repeater device by looking up the Matter node ID of the target Matter device from the unencrypted portion of the first message generated by the remote client.

[0084] Step 404: The repeater device generates a new header, which includes the repeater device's address as the source address and the IP address corresponding to the device ID of the target Matter device as the destination address. The new header replaces the header of the first message to obtain the second message. Therefore, the header of the second message indicates that the Matter device's IP address is the destination and the repeater device's IP address is the source.

[0085] Step 405: The repeater device transmits the second message to the target Matter device identified in step 304.

[0086] Step 406: The repeater device retransmits the second message to the target Matter device at predefined intervals. Advantageously, the retransmission is handled locally by the repeater device, eliminating the need for the remote client to perform retransmissions over a tunnel. As an example, to enable the retransmission mechanism implemented by the repeater device, the remote client can set the "reliable" field in its sent JSON message to "true". Upon receiving the message, the repeater device will check the "reliable" field and determine whether to perform reliability protocol processing.

[0087] Step 407: If the repeater device does not receive a response message from the target Matter device within a predefined time window, it sends a notification message to the remote client via the tunnel.

[0088] In a preferred embodiment, since data exchange is conducted via a tunnel established in the cloud, remote clients can relax timing requirements to some extent.

[0089] Example 3: Establishing a subscription

[0090] Figure 5 An embodiment of a method for establishing a subscription relationship between a Matter device and a remote client via a repeater device according to this disclosure is illustrated. The process may include the following steps:

[0091] Step 501: The remote client sends a subscription request message to the repeater device via the established tunnel.

[0092] Step 502: The repeater device queries the discovery table to determine the IP address corresponding to the device ID of the target Matter device. Understandably, the discovery step is performed by the repeater device by looking up the Matter node ID of the target Matter device from the unencrypted portion of the first message generated by the remote client.

[0093] Step 503: The repeater device generates a new header, which includes the repeater device's address as the source address and the IP address corresponding to the device ID of the target Matter device as the destination address. The new header replaces the header of the subscription message to obtain the second message. Therefore, the header of the second message indicates that the Matter device's IP address is the destination and the repeater device's IP address is the source.

[0094] Step 504: The repeater device transmits the second message to the target Matter device identified in step 503.

[0095] Step 505: The repeater device receives subscription response messages from the target Matter device via the assigned UDP port within a predefined time window.

[0096] Step 506: The repeater device transmits the subscription response message to the remote client via a tunnel, wherein the remote client is determined based on the UDP port on which the repeater device receives the subscription response message.

[0097] After a subscription is established between the remote client and the Matter device, whenever the subscription settings change, in step 507, the Matter device will send a notification message to the repeater device via the assigned UDP port.

[0098] Step 508: The repeater device then transmits the notification message to the remote client via the tunnel, and similar to step 506, determines the remote client based on the UDP port through which the repeater device received the notification message.

[0099] To achieve secure and reliable communication between Matter devices via repeaters, a CASE (Chip Authentication Session Establishment) session needs to be established. A CASE session is an encryption protocol that allows two Matter devices to authenticate each other and establish a shared key for encrypting and decrypting messages. A CASE session can be initiated by either device and involves the exchange of certificates, signatures, and random numbers. In the case of subscriptions, for example via… Figure 3 As shown in the process, the CASE session between the remote client and the Matter device has already been established through the repeater device. Therefore, the repeater device already has a reverse lookup entry for the UDP port of the remote client's remote ID. The repeater device will demultiplex the subscription response message and send it to the target remote client.

[0100] As another embodiment, this disclosure provides a system including at least one remote client, a repeater device, and at least one Matter device, wherein the repeater device and at least one Matter device are in a local network.

[0101] The repeater device is configured to: establish a tunnel between the repeater device and a remote client; receive a first message from the remote client via the tunnel, wherein the first message may include a header, and the header includes the device ID of the target Matter device as the destination address; query a discovery table to determine the IP address corresponding to the device ID of the target Matter device; generate a new header, which includes the address of the repeater as the source address and the IP address corresponding to the device ID of the target Matter device as the 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.

[0102] In a preferred embodiment, the header of the first message also includes the remote ID of the remote client as the source address, and the repeater device is further configured to: allocate a UDP port for the remote ID of the remote client; and transmit the second message to the target Matter device via the allocated UDP port.

[0103] In a preferred embodiment, the first message also includes an encrypted payload that can be decrypted only by the target Matter device.

[0104] In a preferred embodiment, the tunnel established between the repeater device and the remote client is a secure tunnel built on the cloud.

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

[0106] Preferably, the repeater device is also configured to retransmit the second message to the target Matter device within a predefined time window.

[0107] Preferably, the repeater device is also configured to transmit a notification message to the remote client in response to not receiving a response message from the target Matter device within a predefined time window.

[0108] Preferably, the repeater device is further configured to: receive a subscription response message from the Matter device via a UDP port; and transmit the subscription response message to a remote client, wherein the remote client determines the UDP port in response to assigning a remote ID to the remote client.

[0109] As another embodiment, this disclosure provides a repeater device including a processor and a memory, wherein the memory contains instructions executable by the processor, enabling the repeater device to perform the methods according to any of the above embodiments.

[0110] As another embodiment, this disclosure provides a non-transitory computer-readable storage medium that stores instructions that, when executed by at least one processor, cause the at least one processor to perform a method according to any of the above embodiments.

[0111] This disclosure is designed to enable remote control of a Matter device via one or more remote clients. The solution according to the invention allows a remote Matter client to communicate with a local Matter device located on a local network via a repeater device. By performing end-to-end tunneling of Matter data between the remote client and the repeater device, the data is encrypted using Matter's encryption technology, which only the target Matter device can decrypt. This enhances the security and privacy of the communication. This disclosure also ensures reliable and timely data transmission between the remote Matter client and the Matter device by using a repeater device acting as a proxy, and allows for adjustment of retransmission timeouts based on network conditions and device capabilities. Furthermore, it enables multiple Matter clients to control and monitor the same Matter device using a demultiplexing mechanism in the repeater device, which routes data from the Matter device to the appropriate Matter client based on a mapping of UDP ports to the remote client's remote ID.

[0112] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or limit the embodiments to the exact forms disclosed. Modifications can be made based on the foregoing disclosure, or modifications can be obtained from practice of the implementation. As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. Clearly, the systems and / or methods described herein can be implemented in various forms of hardware, firmware, and / or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, this document describes the operation and behavior of systems and / or methods without reference to specific software code—it should be understood that software and hardware can be used to implement systems and / or methods based on those described herein. As used herein, depending on the context, satisfying a threshold can refer to a value greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, etc., depending on the context. Although specific 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 can be combined in ways not specifically recited in the claims and / or not disclosed in the specification.

[0113] Although each dependent claim listed below may be directly dependent on only one claim, the disclosure of various embodiments includes a combination of each dependent claim with each other claim in the claim set. Unless so explicitly described, no element, action, or instruction used herein should be construed as critical or essential. Furthermore, 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.” Furthermore, as used herein, the article “the” is intended to include one or more items referenced in conjunction with the article “the” and may be used interchangeably with “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, etc.) and may be used interchangeably with “one or more.” In cases referring to only one item, the phrase “only one” or similar language is used. Furthermore, as used herein, the terms “has,” “have,” “having,” etc., are intended to be open-ended terms. Furthermore, unless otherwise expressly stated, the phrase “based on” is intended to mean “at least partially based on”. Additionally, as used herein, the term “or” is intended to be inclusive when used enumeratively and may be used interchangeably with “and / or” unless otherwise expressly stated (e.g., if used in combination with “any” or “only one of”).

[0114] It should be understood that the methods and systems in the Matter network described above are provided as examples only and are not intended to limit this disclosure. Those skilled in the art will understand that the principles of this disclosure can be applied to systems and methods other than shared control in the Matter network described above without departing from the scope of this disclosure. Although various embodiments of various aspects of this disclosure have been described for the purposes of this disclosure, it should not be construed as limiting the teachings of this disclosure to these embodiments. Therefore, features disclosed in a particular embodiment are not limited to that embodiment but can be combined with features disclosed in different embodiments. For example, one or more features and / or operations of a method according to this disclosure described in one embodiment may also be applied individually, in combination, or holistically in another embodiment. The description of the system / device embodiments also applies to the method embodiments, and vice versa. Those skilled in the art will understand that more alternative embodiments and variations are possible without departing from the scope defined by the claims of this disclosure, and various changes and modifications can be made to the above-described system.

Claims

1. A method for remotely controlling a Matter device, the method being implemented by a repeater device, the method comprising: Establish a tunnel between the repeater device and the remote client; A first message is received from the remote client via the tunnel, wherein the first message includes a header, and the header includes the device ID of the target Matter device as the destination address; The table is queried to determine the IP address corresponding to the device ID of the target Matter device; A new header is generated, which includes the address of the repeater device as the source address and the IP address corresponding to the device ID of the target Matter device as the destination address. The header of the first message is replaced with the new header to obtain the second message. and The second message is transmitted to the target Matter device.

2. The method according to claim 1, wherein, The header of the first message also includes the remote ID of the remote client as the source address, and the method further includes: Assign a UDP port to the remote ID of the remote client; and The second message is transmitted to the target Matter device via the assigned UDP port.

3. The method according to claim 1, wherein, The first message also includes an encrypted payload that can be decrypted only by the target Matter device.

4. The method according to claim 1, wherein, The tunnel established between the repeater device and the remote client is a secure tunnel built on the cloud.

5. The method according to claim 2, further comprising: Receive response messages from the target Matter device via the assigned UDP port; and The response message is transmitted to the remote client via the tunnel.

6. The method according to claim 1, further comprising: The repeater device retransmits the second message to the target Matter device within a predefined time window.

7. The method of claim 6, further comprising: If no response message is received from the target Matter device within the predefined time window, a notification message is transmitted to the remote client.

8. The method according to claim 1, further comprising: Receive subscription request messages from remote clients; Based on the destination address in the header of the subscription request message, the subscription request message is forwarded to the target Matter device via the allocated UDP port; Receive subscription response messages from Matter devices via the assigned UDP port; and The subscription response message is transmitted to the remote client, wherein the remote client is determined in response to assigning a UDP port for the remote client's remote ID.

9. A system comprising at least one remote client, a repeater device, and at least one Matter device, wherein, The repeater device and at least one Matter device are in the local network. The repeater device is configured to: - Establish a tunnel between the repeater device and the remote client; - Receive a first message from the remote client via the tunnel, wherein the first message includes a header and the header includes the device ID of the target Matter device as the destination address; - Query the discovery table to determine the IP address corresponding to the device ID of the target Matter device; - Generate a new header, the new header including the address of the repeater device as the source address, the IP address corresponding to the device ID of the target Matter device as the destination address, and replace the header of the first message with the new header to obtain the second message; and - Transmit the second message to the target Matter device.

10. The system according to claim 9, wherein, The header of the first message also includes the remote ID of the remote client as the source address, and the repeater device is further configured to: - Assign a UDP port to the remote ID of the remote client; and - The second message is transmitted to the target Matter device via the assigned UDP port.

11. The system according to claim 9, wherein, The first message also includes an encrypted payload that can be decrypted only by the target Matter device.

12. The system according to claim 9, wherein, The tunnel established between the repeater device and the remote client is a secure tunnel built on the cloud.

13. The system according to claim 10, wherein, The repeater device is also configured to: - Receive response messages from the target Matter device via the assigned UDP port; and - The response message is transmitted to the remote client via the tunnel.

14. The system according to claim 9, wherein, The repeater device is also configured to retransmit the second message to the target Matter device within a predefined time window.

15. The system according to claim 14, wherein, The repeater device is also configured to transmit a notification message to the remote client in response to not receiving a response message from the target Matter device within the predefined time window.

16. The system according to claim 9, wherein, The repeater device is also configured to: - Receive subscription request messages from remote clients; - Based on the destination address in the header of the subscription request message, forward the subscription request message to the target Matter device via the allocated UDP port; - Receive subscription response messages from Matter devices via the assigned UDP port; and - The subscription response message is transmitted to the remote client, wherein the remote client is determined in response to assigning a UDP port for the remote client's remote ID.

17. A repeater device comprising: A processor and a memory, wherein the memory contains instructions executable by the processor, enabling the repeater device to operate to perform the method according to any one of claims 1 to 8.

18. A non-transitory computer-readable storage medium storing instructions that, 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.

Images