Patent Description:
In decentralized Internet of Things (IoT) applications, due to security concerns, connecting and accessing IoT devices located in an internal network from an external network is not allowed. When the IoT devices operate abnormally (but the connection works normally), such restriction hinders the equipment maintenance personnel from performing remote fault analysis and troubleshooting.

In general, the integration solution for accessing IoT devices is implemented through a virtual private network (VPN). When the equipment maintenance personnel attempt to access IoT devices from the external network, both the device used by the maintenance personnel and the IoT device need to be connected to the VPN. Through a VPN server and a VPN client, a reliable and safe transmission channel can be established for access therebetween. However, for decentralized IoT applications, a large number of devices give rise to a large number of device connection management requirements, so that corresponding application logic components are required for integration. In this situation, higher performance requirements are needed for IoT devices, and the used intermediary software (e.g. Open VPN server with additional device management components) may not be widely available due to high cost caused by the high complexity. Document <CIT> (<NUM>-<NUM>-<NUM>) discloses a data transmission method between devices in different networks using MQTT protocol.

Recently, public cloud service providers have provided remote IoT device access solutions for IoT applications, which use non-VPN ways to establish transmission channels. However, a lot of utilization restrictions have been produced due to the business model or other factors of intermediary services and public cloud services. For example, intermediary services generally include channel technology that provides information transmission and management components for managing equipment and information transmission, and the technology is complex and not disclosed. For companies with limited development and maintenance capabilities, the channel technology coupled with complex connection management logic substantially raises the complexity of system design and technical threshold, which result in difficulties to deploy and maintain the system by their own.

Therefore, the present invention is to use the existing IoT message communication protocol of the IoT device and the existing IoT message intermediary service server to establish a reliable, safe and convenient channel for accessing the network service of a remote device without adding additional components. Accordingly, while retaining the low-efficiency requirements of IoT devices, the technical level and maintenance complexity of accessing remote devices are reduced.

This is achieved by a communication method for a user terminal to communicate with a device terminal through a message broker according to the independent claim <NUM>, a communication method for a device terminal to communicate with a user terminal through a message broker according to the independent claim <NUM>, or a communication system according to the independent claim <NUM> here below. The dependent claims pertain to corresponding further developments and improvements.

As will be seen more clearly from the detailed description following below, a communication method for a user terminal to communicate with a device terminal through a message broker is disclosed herein. The communication method comprises wrapping a first packet of a first communication protocol into a second packet with a second communication protocol and sending the second packet to the message broker; or receiving a third packet of the second communication protocol from the message broker and obtaining a fourth packet of the first communication protocol wrapped in the third packet; wherein the first communication protocol is a communication protocol supported by the device terminal, and the second communication protocol is a communication protocol supported by the message broker.

In another aspect of the invention, a communication method for a device terminal to communicate with a user terminal through a message broker is disclosed in the detailed description here below. The communication method comprises receiving a first packet of a first communication protocol from the message broker and obtaining a second packet of a second communication protocol wrapped in the first packet; or wrapping a third packet of the second communication protocol into a fourth packet with the first communication protocol and sending the fourth packet to the message broker; wherein the first communication protocol is a communication protocol supported by the message broker, and the second communication protocol is a communication protocol supported by the device terminal.

In another aspect of the invention, a communication system is disclosed in the detailed description here below. The communication system comprises a user terminal, a device terminal and a message broker. The message broker, coupled to the user terminal and the device terminal, is for exchanging packets between the user terminal and the device terminal, wherein the user terminal and the device terminal perform a communication method through the message broker. The communication method comprises the user terminal wrapping a first packet of a first communication protocol into a second packet with a second communication protocol and sending the second packet to the message broker, and the device terminal receiving the second packet of the second communication protocol from the message broker and obtaining the first packet of the first communication protocol wrapped in the second packet; or the device terminal wrapping a third packet of the first communication protocol into a fourth packet with the second communication protocol and sending the fourth packet to the message broker, and the user terminal receiving the fourth packet of the second communication protocol from the message broker and obtaining the third packet of the first communication protocol wrapped in the fourth packet; wherein the first communication protocol is a communication protocol supported by the device terminal, and the second communication protocol is a communication protocol supported by the message broker.

Certain terms are used throughout the description and following claims to refer to particular components. As one skilled in the art will appreciate, hardware manufacturers may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following description and in the claims, the terms "include" and "comprise" are utilized in an open-ended fashion, and thus should be interpreted to mean "include, but not limited to".

Please refer to <FIG> is a schematic diagram of a network <NUM>, and illustrates the architecture of remote access to an IoT device through a VPN. In <FIG>, the network <NUM> comprises an internal network (intranet) <NUM>, a firewall <NUM> and an external network (internet) <NUM>, and the network <NUM> may be divided into an internal network <NUM> and an external network <NUM> through the firewall <NUM>. When equipment maintenance personnel attempt to access an IoT device <NUM> inside the internal network <NUM> from a user device <NUM> located in the external network <NUM>, a transmission channel needs to be established through an intermediary server <NUM>. Specifically, the IoT device <NUM> and the user device <NUM> need to connect to a VPN server <NUM> of an intermediary server <NUM> through a VPN client <NUM> and a VPN client <NUM> respectively to build a reliable and secure transmission channel, so that the user device <NUM> and the IoT device <NUM> are able to communicate with each other. However, due to application requirements and hardware limitations, different IoT devices provide different types of network application services for access, such as web service, file transfer protocol (FTP), Secure Shell Protocol (SSH), etc. In this situation, a large number of IoT devices lead to a large number of device connection management requirements. In addition to establishing corresponding transmission channels according to different network application services, it is also necessary to consider the security mechanism for establishing transmission channels in the Internet of Things (e.g. distribution of digital certificates and the subsequent management mechanism thereof) and connection status management of transmission channels. Therefore, the intermediary server <NUM> usually needs to configure an application logic management module <NUM> to integrate complex management logic for device connection, which causes difficulties in development and management.

In view of the above problems, the present invention utilizes the existing IoT message brokers and IoT message protocols prepared for the IoT devices, and therefore, additional VPN servers or additional security mechanisms, such as certificate distribution and management, are not necessary to be set up. Accordingly, a simple and secure channel for accessing the network service of a remote device (hereinafter referred to as the service access channel) and a device connection management method may be established without including additional components to reduce the complexity of maintenance and operation. Due to application requirements and hardware limitations, IoT devices generally use built-in and lightweight message protocols with publish-subscribe pattern to transmit data from the internal network to the external network, or receive instructions from the external network. For example, common message protocols for IoT devices include Message Queuing Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (CoAP), and the present invention may establish a service access channel according to such message protocols, so that the IoT device and the user device may use the Transmission Control Protocol (TCP) network communication services (e.g. SSH, HTTP, FTP) and manage IoT device connections through the service access channel. In other words, the present invention utilizes the original secure message transmission mechanism of the IoT device to establish a service access channel for network services, so there is no need to additionally establish corresponding connections and security mechanisms to different network services. Accordingly, the present invention may reduce the complexity of the intermediary server to exactly have the simple capability for message transmission while maintaining low performance requirements for the IoT devices.

Please refer to <FIG> is a schematic diagram of a network <NUM> according to an embodiment of the present invention, and illustrates the architecture of remote access to an IoT device through an IoT message broker. As shown in <FIG>, the network <NUM> comprises an internal network (intranet) <NUM>, a firewall <NUM> and an external network (internet) <NUM>, and the network <NUM> may be divided into an internal network <NUM> and an external network <NUM> through the firewall <NUM>. In detail, the internal network <NUM> may be a private network, which may comprise an IoT device <NUM>, and the IoT device <NUM> may be a device terminal with communication capabilities. The external network <NUM> may be a public network, which may comprise a user device <NUM> and a message broker <NUM>. The user device <NUM> may be a user-terminal communication device used by the maintenance personnel. The message broker <NUM> may be a network device that provides a message exchange service with publish-subscribe pattern. The embodiment of the present invention takes an MQTT message broker as an example, but is not limited thereto. The firewall <NUM> may be a security device in the network <NUM>, which may be used to separate different networks (the internal network <NUM>, the external network <NUM>) and may be used to control the passage of data in the internal network <NUM>, so as to ensure the security of the internal network <NUM>.

In this embodiment, when the user device <NUM> located in the external network <NUM> attempts to remotely access the IoT device <NUM> inside the internal network <NUM>, the message broker <NUM> acts an intermediary. Specifically, the IoT device <NUM> comprises a device agent module <NUM> and an application service module <NUM>. The device agent module <NUM> may be a resident program running on the device terminal, which comprises an MQTT client for exchanging messages with the message broker <NUM>; the application service module <NUM> may provide TCP network services, such as HTTP server, FTP server, SSH server. The user device <NUM> comprises a user agent module <NUM> and an application program module <NUM>. The user agent module <NUM> may be a resident program running on the user terminal, which comprises an MQTT client for exchanging messages with the message broker <NUM>; the application program module <NUM> may provide TCP network service, such as HTTP client (browser), FTP client, SSH client. When the maintenance personnel access the network service provided by the application service module <NUM> of the IoT device <NUM> from the user device <NUM> through the application program module <NUM>, the messages are actually transmitted from the user agent module <NUM>, to the message broker <NUM>, and then to the device agent module <NUM> through a message protocol (such as MQTT) supported by the message broker <NUM>. Similarly, When the application service module <NUM> of the IoT device <NUM> returns a response message to the application program module <NUM> of the user device <NUM>, the response message is also transmitted from the device agent module <NUM>, to the message broker <NUM>, and then to the user agent module <NUM> through the message protocol supported by the message broker <NUM>.

As to the operating principle of the network <NUM>, please continue to refer to <FIG> is a schematic diagram of a process <NUM> according to an embodiment of the present invention, which illustrates the operating method of establishing the service access channel between the user device <NUM> and the IoT device <NUM> through the IoT message broker. The process <NUM> comprises the following steps:.

According to the process <NUM>, the device agent module <NUM> has to register device identification (ID) to the message broker <NUM> and publish a connection status such as online or offline according to the registered device ID (Step <NUM>). Next, the user agent module <NUM> may obtain a device list and device connection status from the message broker <NUM> (Step <NUM>), and accordingly, the maintenance personnel may specify the IoT device to be connected according to the device list and the device connection status. By specifying the device ID of the IoT device and a user ID of the user terminal, the user agent module <NUM> may be bound with the device agent module <NUM> (for example, log in, log out), so that the initialization related to the network service may be performed and an entrance channel for the maintenance personnel to access the network service may be established (step <NUM>). When the maintenance personnel attempt to access the network services provided by the application service module <NUM>, such as HTTP, FTP, SSH, a session is triggered and then a session channel is established for transmitting messages (Step <NUM>). Finally, after the access to the network service provided by the application service module <NUM> finishes, the session is closed and related resources are released (Step <NUM>).

In the process <NUM>, the data handshake between the device agent module <NUM> and the user agent module <NUM> may be implemented through the topic of publish-subscribe pattern and the message transmission therein. In general, the topic name is a UTF-<NUM> string and may be determined according to the system or design requirements. In addition, the topic name also supports a hierarchical structure with a forward slash to separate the levels of the hierarchy, which may be used for category management. In the publish-subscribe pattern, messages are published to a topic by a publisher, and a subscriber will receive all the messages published on the topic subscribed by the subscriber. Moreover, through specific wildcards such as "+" or "#", subscribers may set topic filtering conditions for topic filtering, and the message broker will deliver messages to subscribers based on topic names and topic filtering conditions.

In detail, in Step <NUM>, the device agent module <NUM> has to register device identification (ID) to the message broker <NUM> and publish a connection status. First, the step proceeds to create a first topic with a topic name comprising the device ID, and according to the device ID contained in the topic name of the first topic, the device may be registered to the message broker <NUM>. The topic name of the first topic may be in the form of "smtunnel/groupID/deviceID/state", wherein the deviceID may be a device ID, and the groupID may be a group ID of a group to which the device belongs. The topic name of the first topic is only used to illustrate the embodiment of the present invention, and the number of levels and the content may be adjusted according to actual needs, and is not limited thereto. Then, the device agent module <NUM> may publish related connection status such as online or offline to the first topic. The device agent module <NUM> may publish online or offline messages through the function of retained messages, so that subscribers who subscribe to the first topic later may also obtain the correct connection status of the device. Moreover, the device agent module <NUM> may set an LWT (Last Will and Testament) message, and thereby an offline message may be published to the first topic after the device agent module <NUM> disconnects unexpectedly. Accordingly, the device agent module <NUM> may correctly publish the connection status to the subscribers of the first topic.

In Step <NUM>, the user agent module <NUM> may obtain a device list and device connection status from the message broker <NUM>. Specifically, the user agent module <NUM> may filter topics by setting the topic filtering conditions, and the message broker <NUM> sends messages of topics that meet the topic filtering conditions to the user agent module <NUM> according to the topic name and the topic filtering conditions. Accordingly, the user agent module <NUM> may obtain the required device list, and further obtain the device connection status according to the message of the topic that meets the topic filtering conditions. For example, the user agent module <NUM> may use the wildcard "+" to set a topic filtering condition such as "smtunnel/group_1/+/state", so as to subscribe to the first topics of all devices belonging to the group group_1 (group ID). According to the retained message (online or offline message) published by the device agent module <NUM> in Step <NUM>, the user agent module <NUM> may receive the correct device connection status of all devices belonging to the group group _1. The user agent module <NUM> may obtain the device list and the device connection status as shown in Table <NUM> below. It should be noted that the group IDs and device IDs shown in Table <NUM> are merely for illustration purposes, and may have different forms according to actual situations.

After the user agent module <NUM> obtains the device list and the device connection status as shown in Table <NUM> above, the device agent module <NUM> of the designated device may be bound for performing initialization and establishing an entrance channel in Step <NUM>. The user agent module <NUM> may have a Universally Unique Identifier (UUID) as a user ID of the user terminal. The user agent module <NUM> may create a second topic and a third topic with topic names comprising the device ID of the designated device and the user ID so as to associate or disassociate with the device agent module <NUM>. After the association between the user agent module <NUM> and the device agent module <NUM> is established, the user agent module <NUM> may create an entrance channel for the application program module <NUM> to connect to. While attempting to access the IoT device <NUM>, the maintenance personnel may carry out the access through the entrance channel in a normal way.

In detail, the topic name of the second topic may be and not limited to the form of "smtunnel/groupID/deviceID/clientID/login", wherein the deviceID may be a device ID, the groupID may be a group ID of a group to which the device belongs, and the clientID may be a user ID. Through the second topic, the user agent module <NUM> may send a request message for logging in to the designated device to establish association. In practice, the user agent module <NUM> may publish a login message to the second topic, and the content of the message may comprise related information of the network service to be accessed. On the other hand, by subscribing the second topic, the device agent module <NUM> may obtain the user ID of the login user and the related information of the network service to be accessed. For example, if the maintenance personnel with user ID client_1 wants to start an SSH connection with the IoT device having a group ID of group_1 and a device ID of device_1, then the user agent module <NUM> may publish a login message with the content "localhost:<NUM>" to the topic "smtunnel/group_1/device_1/client_1/login". By setting the topic filtering condition such as "smtunnel/group_1/device_1/+/login", the IoT device <NUM> is able to subscribe to the topic "smtunnel/group_1/device_1/client_1/login", and thereby obtain the user ID of the login user (client_1) and receive message with the content "localhost:<NUM>". Accordingly, the association between the user agent module <NUM> and the device agent module <NUM> may be established.

On the other hand, the topic name of the third topic may be and not limited to the form of "smtunnel/groupID/deviceID/clientID/logout". The deviceID may be a device ID, the groupID may be a group ID of a group to which the device belongs, and the clientID may be a user ID. Through the third topic, the user agent module <NUM> may send a request message for logging out of the designated device to cancel the association. Similarly, by subscribing to the third topic, the device agent module <NUM> may obtain the user id of the logout user. For example, if the maintenance personnel with user ID client_1 intend to log out of the IoT device with a group ID of group_1 and a device ID of device _1, then the user agent module <NUM> may publish a logout message to the topic "smtunnel/group_1/device_1/client_1/logout". Accordingly, the association between the user agent module <NUM> and the device agent module <NUM> may be canceled.

After the association between the user agent module <NUM> and the device agent module <NUM> is established, a session and a session channel may be established to start message transmission in Step <NUM>. Specifically, the entrance channel created by the user agent module <NUM> comprises a TCP listener service. When the TCP listener service receives an access to the network service provided by the access application service module <NUM> of the IoT device <NUM> from the application program module <NUM> by the maintenance personnel, an establishment of the session is triggered.

In detail, when the session is established, the embodiment of the present invention generates a session ID and accordingly establishes the session channel. Specifically, the session channel comprises an input channel from the application program module <NUM>, the user agent module <NUM>, the message broker <NUM>, the device agent module <NUM> to the application service module <NUM>, and an output channel from the application service module <NUM>, the device agent module <NUM>, the message broker <NUM>, the user agent module <NUM> to the application program module <NUM>. In practice, for the user device <NUM>, the data transmission between the application program module <NUM> and the user agent module <NUM> may be realized through network I/O. Similarly, for the IoT device <NUM>, the data transmission between the application service module <NUM> and the device agent module <NUM> may be also realized through network I/O. The input channel from the user agent module <NUM>, the message broker <NUM> to the device agent module <NUM> is realized by publishing and subscribing to a fourth topic. Similarly, the output channel from the device agent module <NUM>, the message broker <NUM> to the user agent modules <NUM> is realized by publishing and subscribe to a fifth topic.

The topic name of the fourth topic may be and not limited to the form of "smtunnel/groupID/deviceID/clientID/sessionID/in". The deviceID may be a device ID, the groupID may be a group ID of a group to which the device belongs, the clientID may be a user ID, and the sessionID may be the session ID of the session triggered in Step <NUM>. The user agent module <NUM> publishes messages to the fourth topic, and then the device agent module <NUM> may receive the messages published by the user agent module <NUM> through subscribing to the fourth topic. That is to say, through the fourth topic, the device agent module <NUM> is able to receive the message sent by the user agent module <NUM>. Similarly, the topic name of the fifth topic may be and not limited to the form of "smtunnel/groupID/deviceID/clientID/sessionID/out". The device agent module <NUM> publishes messages to the fifth topic, and then the user agent module <NUM> may receive the messages published by the device agent module <NUM> through subscribing to the fifth topic. That is to say, through the fifth topic, the user agent module <NUM> is able to receive the message sent by the device agent module <NUM>. Accordingly, the connection between the user agent module <NUM> and the device agent module <NUM> is established.

Please continue to refer to <FIG>, which is a schematic diagram of a session channel and message transmission of the network <NUM>. Through the input channel, the application program module <NUM> may send messages to the application service module <NUM>; through the output channel, the application service module <NUM> may send messages to the application program module <NUM>. Accordingly, the network <NUM> may realize two-way communication between the user device <NUM> and the IoT device <NUM> through the message broker <NUM>.

Specifically, regarding the input channel, the maintenance personnel may send a packet P1 for accessing the IoT device <NUM> through the application program module <NUM>. The packet P1 may be a packet using any communication protocol A supported by the network service of the IoT device <NUM>, such as HTTP, SSH, FTP, and is not limited thereto. Next, the user agent module <NUM> wraps the packet P1 into a packet P2 of a communication protocol B through the network I/O, and publishes the packet P2 to the fourth topic. The communication protocol B may be a communication protocol supported by the message broker <NUM>, such as MQTT, AMQP, CoAP, etc., and is not limited thereto. Then, the message broker <NUM> dispatches the packet P2 to the device agent module <NUM> that subscribed to the fourth topic, and the device agent module <NUM> similarly takes out the packet P1 wrapped in the packet P2 through the network I/O and transmits the packet P1 to the application service module <NUM>. Accordingly, the maintenance personnel may use the communication protocol supported by the IoT device <NUM> to communicate with the IoT device <NUM> through the application program module <NUM>. It should be noted that parsing or analyzing the content of the packet P1 is not necessary in the embodiment of the present invention, and wrapping the packet P1 into the packet P2 with the communication protocol B is sufficient to perform transmission. Preferably, the method of wrapping the packet P1 into the packet P2 of the communication protocol B is to put the packet P1 in the payload of the packet P2, but not limited thereto; correspondingly, the method for the device agent module <NUM> to take out the packet P1 wrapped in the packet P2 is to extract the packet P1 from the payload of the packet P2.

On the other hand, the application service module <NUM> of the IoT device <NUM> sends a packet P3 in response to the user device <NUM> through the output channel, wherein the packet P3 may be a packet using the communication protocol A. The device agent module <NUM> wraps the packet P3 into a packet P4 of the communication protocol B through the network I/O, and then publishes the packet P4 to the fifth topic. The message broker <NUM> dispatches the packet P4 to the user agent module <NUM> that subscribed to the fifth topic, and then the user agent module <NUM> similarly takes out the packet P3 wrapped in the packet P4 through the Network I/O and transmits the packet P3 to the application program module <NUM>. Accordingly, the IoT device <NUM> may use the communication protocol supported by the application service module <NUM> to communicate with the user device <NUM>. As mentioned above, parsing or analyzing the content of the packet P3 is not necessary in the embodiment of the present invention, and wrapping the packet P3 into the packet P4 with the communication protocol B is sufficient to perform transmission. Preferably, the method of wrapping the packet P3 into the packet P4 of the communication protocol B is to put the packet P3 in the payload of the packet P4, but not limited thereto; correspondingly, the method for the user agent module <NUM> to take out the packet P3 wrapped in the packet P4 is to extract the packet P3 from the payload of the packet P4.

The communication method about the user device <NUM> (user terminal) mentioned above may be summarized into a process <NUM> as shown in <FIG>, which is for communicating with the IoT device <NUM> (device terminal) through the message broker <NUM>. The process <NUM> comprises the following steps:.

The communication method about the IoT device <NUM> (device terminal) mentioned above may be summarized into a process <NUM> as shown in <FIG>, which is for communicating with the user device <NUM> (user terminal) through the message broker <NUM>. The process <NUM> comprises the following steps:.

After the message transmission between the user device <NUM> and the IoT device <NUM> is completed, the session should be closed and related resources should be released in Step <NUM>. In detail, in the embodiment of the present invention, the session ID is generated when the session is created in Step <NUM>, and the message handshake for closing the session may be performed through a sixth topic with a topic name comprising the device ID, the user ID, and the session ID. The topic name of the sixth topic may be and not limited to the form of "smtunnel/groupID/deviceID/clientID/sessionID/close", wherein the deviceID may be the device ID, the groupID may be the group ID of a group to which the device belongs, the clientID may be a user ID, and the sessionID may be the session ID of the session triggered in Step <NUM>. When the access to the network service finishes, for example, when the TCP listening service of the user agent module <NUM> reads End of File (EOF), the user agent module <NUM> may publish a message for session close to the sixth topic, so as to notify the device agent module <NUM> and release related resources. Similarly, the device agent module <NUM> also comprises a TCP listening service. When the access to the network service finishes (e.g. the TCP listening service reads EOF), the device agent module <NUM> may publish a message for session close to the sixth topic so as to notify the user agent module <NUM> and release related resources. It should be noted that the establishment of the session is triggered when the TCP listening service of the entrance channel of the user agent module <NUM> receives the application program module <NUM> accessing the network service provided by the application service module <NUM> of the IoT device <NUM>, and the closing of the session is triggered when the user agent module <NUM> or the device agent module <NUM> detects the end of the access to the network service. During the process, maintenance personnel do not need to deal with cumbersome session and channel establishment issues, and the process is automatically triggered.

Note that, in the embodiment of the present invention, in Step <NUM> to Step <NUM> of the process <NUM>, all of the message handshakes between the user agent module <NUM> and the device agent module <NUM> are handled through the communication protocol B supported by the message broker <NUM>, such as device registration, obtaining the device list, obtaining the deviceID, session establishment and message transmission (i.e., wrapping the packet of communication protocol A). On the other hand, the handshakes between the application program module <NUM> and the user agent module <NUM> and between the application service module <NUM> and the device agent module <NUM> are completed through the communication protocol A. The maintenance personnel do not need to additionally process the message handshake between the user agent module <NUM> and the device agent module <NUM> (i.e., using communication protocol B), and only need to carry out the access to the network services provided by the application service module <NUM> through the entrance channel provided by the user agent module <NUM>(i.e., using communication protocol A).

Furthermore, please refer to <FIG>, which is a schematic diagram of a network device <NUM> according to the embodiment of the present invention. The network device <NUM> may implement the IoT device <NUM>, the user device <NUM> and the message broker <NUM> in the embodiment of the present invention. The network device <NUM> may be a low-cost device such as machine type communication (MTC), a device-to-device (D2D) communication device, a narrow-band IoT (NB-IoT) device, an electric device, a server, a mobile phone, various types of computers such (e.g., desktops, laptops, tablets), an portable computer system, or combination thereof, but is not limited herein. As shown in <FIG>, the network device <NUM> may comprise a processing unit <NUM> and a storage unit <NUM>. The processing unit <NUM> may be a general-purpose processor, a microprocessor an application-specific integrated circuit (ASIC), or combination thereof. The storage unit <NUM> is coupled to the processing unit <NUM> and may be any type of data storage devices for storing a program code <NUM>, and the program code <NUM> is read and executed by the processing unit <NUM>. For example, the storage unit <NUM> may be a read-only memory (ROM), a flash memory, a random-access memory (RAM), a hard disk, an optical data storage device, a non-volatile storage unit, etc., and is not limited thereto.

The network device <NUM> is used to represent the necessary components required to implement the embodiments of the present invention, and those skilled in the art may make various modifications and adjustments accordingly, and is not limited to this. For example, when the network device <NUM> is applied to implement the user device or the IoT device, the process <NUM> or the process <NUM> may be combined with the process <NUM> and complied into the program code <NUM>, stored in the storage unit <NUM>, and executed by the processing unit <NUM>. Moreover, the storage unit <NUM> is also used for storing the data required for running the method of the embodiment of the present invention, and is not limited thereto. When the network device <NUM> is applied to implement the message broker, the message service applicable to the Internet of Things (MQTT, AMQP, CoAP, etc.) may be compiled into the program code <NUM> and stored in the storage unit <NUM>, and the processing unit <NUM> executes the intermediary services for message forwarding, but not limited to.

Claim 1:
A communication method for a user terminal (<NUM>) to communicate with a device terminal (<NUM>) through a message broker (<NUM>), characterized by comprising:
wrapping a first packet (P1) of a first communication protocol into a second packet (P2) with a second communication protocol and sending the second packet (P2) to the message broker (<NUM>); or
receiving a third packet (P4) of the second communication protocol from the message broker (<NUM>) and extracting a fourth packet (P3) of the first communication protocol from the third packet (P4);
wherein the first communication protocol is a communication protocol supported by the device terminal (<NUM>), and the second communication protocol is a communication protocol supported by the message broker (<NUM>);
wherein the second communication protocol is a communication protocol for Internet of Things, called IoT hereinafter, messages with a publish-subscribe pattern, and the communication method further comprises:
registering, by the device terminal (<NUM>), to the message broker (<NUM>) through a first topic with a topic name comprising a device identification, called ID hereinafter; and
obtaining, by the user terminal (<NUM>), the first topic comprising the device ID of the device terminal (<NUM>) through topic filtering.