Methods support a sleep mode for an embedded device. Embedded devices like sensors and actuators used in wireless sensor networks have a limited power supply. To conserve energy and thus increase the lifetime of these devices, the devices should be put into a stand-by mode (also called sleep-mode) when they are not used. These methods support the sleep mode at a higher level than the MAC layer, thus avoiding the problems of prior art approaches. Methods are exemplarily described for the case of the message queuing telemetry transport protocol for sensor networks. They can easily be adapted to other protocols.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to support of sleeping devices on wireless sensor networks, and more particularly, to methods for using message queuing telemetry transport for sensor networks (MQTT-S) to support sleeping devices.
2. Description of Background
Wireless sensor networks (WSNs) are gaining increased attention because of their potential for enabling novel and attractive solutions in areas such as industrial automation, asset management, environmental monitoring, and transportation. In many of these applications, sensors remain idle for long periods of time if no sensing event occurs. In the context of WSNs, these sensors include transmitters capable of transmitting sensed information using radio frequency (RF) energy. To save as much energy as possible, it would be desirable for sensors to turn off their transmitters and sleep during idle times. Sensors would need to wake up only when they have acquired new information to send.
Message queuing telemetry transport (MQTT) is a published protocol designed for use with simple devices such as sensors and actuators (SAs). MQTT-S is an extension of MQTT to sensor networks. MQTT-S is designed to operate in conjunction with low-cost, low-power SA devices running over bandwidth constrained WSNs such as Zigbee-based networks. Zigbee is an open, global standard for WSNs based on the IEEE 802.15.4 standard. Essentially, Zigbee adds networking, security, and application support functionalities to IEEE 802.15.4, with the aim of providing interoperability between products from different vendors. Zigbee and IEEE 802.15.4 are designed such that implementation on the client side (i.e., the SA side) is comparatively simple relative to implementation on the broker side.
MQTT and MQTT-S support basic end-to-end Quality of Service (QoS). Depending upon how reliably messages should be delivered to their receivers, they distinguish between three QoS levels. QoS level 0 is the simplest level. It offers a best effort delivery service, in which messages are delivered either once, or not at all, to a destination. No retransmission or acknowledgement is defined. Thus, QoS level 0 is appropriate for applications which can tolerate loss of a few messages. QoS level 1 provides a more reliable transport: messages with QoS level 1 are retransmitted until they are acknowledged by a receiver at the destination. Consequently, QoS level 1 messages are certain to arrive, but they may arrive multiple times at the destination because of the retransmissions. The highest QoS level, level 2, ensures not only the reception of messages, but also that they are delivered only once to the destination. It is up to an application to select an appropriate QoS level for its publications and subscriptions. For example, a temperature-monitoring application could decide to use QoS level 0 for the publication of normal and regular measurement reports, but QoS level 1 for transferring alarm messages when the temperature exceeds a certain threshold.
MQTT and MQTT-S are connection-oriented protocols in the sense that they require a client to set up a connection with the broker before the client can exchange publications and subscriptions with the broker. To this end, a CONNECT message is defined which contains a Client ID. The Client ID enables the broker to identify the connected client, and also to ensure that QoS level 1 and level 2 publications are delivered correctly even when the client reconnects after a network failure. The broker supervises the level of activity of the client connection using a keep-alive timer that defines the maximum allowable time interval that may elapse between two messages received from that client. If, during this time interval, the client has no data-related messages to be transmitted, the client has to send a PINGREQ message to the broker which is then acknowledged by the broker. Thus, the keep-alive timer enables the broker to detect a failure of either the client or a network link. A related feature is the support of the so-called Will concept. At connection time, the client may ask the broker to store a Will message together with a Will topic. The broker sends this Will message as a publication to subscribers when the broker loses its connection with the client by the keep-alive timer timing out. Applications could use this feature to detect persistent failures of links and devices.
There is a very important feature that is not supported by the current MQTT/MQTT-S protocol, namely the handling of duty cycles of the client devices. In many sensor applications, the sensor devices are idle for a long time if no sensing event occurs. To save as much energy as possible, it would be desirable for the client devices to enter a sleep mode when they are not used. The clients can wake up and publish data whenever the clients acquire new data. However, existing publish/subscribe protocols do not support sleeping devices. In the context of WSNs, support for sleeping devices has heretofore only been provided at the media access control (MAC) layer. Thus, prior art methods place a device into a sleep-mode state using protocols at a very low level. This causes problems as the upper protocol levels are unaware of these state changes.
It is difficult or impossible to utilize MAC-based sleep control mechanisms in networks where the broker is not connected directly to a wireless network, but instead connected through a gateway or router. Although a router could be used to buffer messages until a client device wakes up, the sleeping time could be quite long, on the order of several minutes to several hours. Since the router may serve a large number of clients, the number of messages to be buffered could easily exceed the storage capacity of the router. Moreover, as mentioned previously, in the case of QoS levels 1 and 2, the broker or gateway needs to receive an acknowledgment from the client to be sure that the client has correctly received a published message. It would not be possible to support QoS levels 1 and 2 if the published messages were to be stored for a long time at a router. In view of the foregoing shortcomings, what is needed is an improved technique for supporting sleeping devices on a WSN.
SUMMARY OF THE INVENTION
Methods for using message queuing telemetry transport for sensor networks (MQTT-S) to support a sleeping client device on a wireless sensor network operatively coupled to a broker through a gateway, the methods comprising the broker receiving a CONNECT message from the client device, the CONNECT message specifying a client identifier and a keep-alive duration; monitoring the client device using a keep-alive timer set to the keep-alive duration wherein, if the broker does not receive a message from the client device for a period longer than the keep-alive duration, the broker associates the client device with a lost status and activates a will feature for that client device; the broker receiving a DISCONNECT message from the client device, the DISCONNECT message specifying a sleep duration; the broker acknowledging receipt of the DISCONNECT message to the client device; the broker associating the client device with an asleep status wherein, if the broker does not receive any message from the client device for a period longer than the sleep duration, the broker associates the client device with a lost status and activates the will feature and wherein, during the asleep status, the broker stores any messages for the client device as buffered messages; the broker receiving a PINGREQ message from the client device, the PINGREQ message specifying the client identifier, and in response to receipt of the PINGREQ message, associating the client device with an awake status; wherein, if the broker has no buffered messages for the client, the broker sends a PINGRESP message to the client device and associates the client device with the asleep status; wherein, if the broker has one or more buffered messages for the client device, the broker sends the one or more buffered messages to the client device upon receipt of the PINGREQ message by the broker; and wherein, after the one or more buffered messages are sent to the client device, the broker sends a PINGRESP message to the client device and associates the client device with the asleep status.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram setting forth an illustrative wireless sensor network (WSN) for use with the methods of the present invention. A traditional network 100, such as a local area network (LAN), wide area network (WAN), Ethernet, or wireless network, includes a broker 130 to which a plurality of applications 121, 122, 123 are connected. The broker 130 is operatively coupled to a first WSN 101 via a first gateway 140. The broker130 is operatively coupled to a second WSN 102 via a second gateway 150. The first WSN 101 includes a plurality of sensors 181, 182, 183, 184,185 operatively coupled to the first gateway 140 over one or more wireless links. First WSN 101 also includes an actuator 161. The sensors 181,182, 183, 184, 185 and the actuator 161 each represent client devices. Similarly, the second WSN 102 includes a plurality of sensors 171, 172,173, 174, 175 operatively coupled to the second gateway 150 over one or more wireless links. The second WSN 102 also includes an actuator 162. The sensors 171, 172, 173, 174, 175 and the actuator 162 each represent client devices.
Due to the fact that the broker 130 is not connected directly to the first WSN 101 or the second WSN 102, prior art techniques for supporting sleeping devices cannot be used. If the first and second WSNs 101, 102 were based upon the IEEE 802.15.4 or Zigbee standard, the first gateway140 or the second gateway 150 could be used to buffer messages until a client device to which the message is directed wakes up. However, as the sleeping times of client devices could be very large (on the order of several minutes to several hours) and a gateway 140, 150 may serve a large number of clients, problems will result. As time goes by, the number of messages to be stored may exceed the capacity of the gateway 140, 150. Moreover, as mentioned previously, QoS levels 1 and 2 require the gateway 140, 150 or the broker 130 to receive an acknowledgment from the client device to be sure that the client has correctly received the published message. It would not be possible to support QoS levels 1 and 2 if the published messages were to be stored for a long time on the gateway 140, 150. Accordingly, pursuant to an illustrative embodiment disclosed herein, at least one of the gateway 140, the gateway 150, or the broker 130 are made aware of one or more sleeping times of a client device, and to store messages for the client device during the one or more sleeping times.
FIG. 2 illustrates an exemplary message flow between a client 201 and a gateway/broker 203 for implementing the methods of the present invention, and FIG. 6 is a state diagram describing the manner in which a broker sees the state of a client. Client 201 may represent any of sensors 171, 172,173, 174, 175, 181, 182, 183, 184, 185, or actuators 161, 162 (FIG. 1). Likewise, gateway/broker 203 (FIG. 2) may represent any of the broker 130, the first gateway 140, or the second gateway 150 (FIG. 1). From the perspective of the gateway/broker 203 (FIG. 2), a client 201 may be in one of the following states: client active 205 (FIGS. 2 and 6), client asleep 207, client awake 209, client lost 211, or client disconnected 213. A client 201 is in the active 205 state when the gateway/broker 203 receives a first message from that client 201, illustratively in the form of a CONNECT 215message. As with the current MQTT/MQTT-S protocol specification, the active 205 state is supervised by the gateway/broker 203 using a keep-alive timer, also referred to as a sleep timer. If the gateway/broker 203 does not receive any message from the client 201 for a period longer than a keep-alive time duration determined by the keep-alive timer (as indicated in the CONNECT 215 message), the gateway/broker 203 will consider that client 201 as being in the client lost 211 state and, for example, activates the will feature for that client 201.
A client 201 goes to the client disconnected 213 state when the gateway/broker 203 receives a second message from that client 201, illustratively in the form of a DISCONNECT 217 message without a sleep duration indication. The disconnected 213 state is not time-supervised by the gateway/broker 203. If a client 201 wants to sleep, the client 201 sends a DISCONNECT 217 message which contains a sleep duration. The gateway/broker 203 acknowledges that message with a DISCONNECT 217 message and considers the client 201 for being in the asleep 207 state. The asleep 207 state is supervised by the gateway/broker 203 with the aforementioned sleep duration. If the gateway/broker 203 does not receive any message from the client 201 for a period longer than the sleep duration, the gateway/broker 203 will consider that client 201 as being in the lost211 state. Accordingly, as with the keep-alive procedure discussed previously, the gateway/broker 203 may activate the will feature for the lost client 201. During the asleep 207 state, all messages that need to be sent to the client are buffered at the broker/gateway.
The time "tolerance" of the sleep supervision at the gateway/broker 203 depends upon the value of the sleep duration. For example, the current MQTT implementation has a tolerance of 10% of the time for durations larger than one minute, and 50% if less.
The keep-alive timer is restarted when the gateway/broker 203 receives a third message, such as a PINGREQ 219 message, from the client 201. Like the CONNECT 215 message, the PINGREQ 219 message contains a client identifier (i.e., a client ID) identifying the client 201. The client 201is then in the awake 209 state. If the gateway/broker 203 does not have any messages buffered for the client 201, the gateway/broker 203 answers the PINGREQ 219 message with a fourth message, such as a PINGRESP 221 message, and returns the client 201 to the asleep 207 state. If the gateway/broker 203 has one or more messages for the client 201, then the broker/gateway 203 sends these one or more messages to the client201 when the gateway/broker 203 receives the PINGREQ 219 message. The transfer of messages is closed by the gateway/broker 203 by means of the PINGRESP 221 message. In other words, the gateway/broker 203 will consider the client 201 as being in the asleep 207 state after having sent the PINGRESP 221 message.
After having sent the PINGREQ 219 message to the gateway/broker 203, the client 201 uses a Tretry timer to supervise the arrival of messages sent by the gateway/broker 203. Essentially, the client 201 starts the Tretry timer when the client 201 receives any message other than a PINGRESP 221message, and stops the Tretry timer when it receives the PINGRESP 221 message. The PINGREQ 219 message is retransmitted and the Tretry timer is started when the Tretry timer times out. To avoid unnecessary current drain in situations where the client 201 is powered by a battery, the client201 may limit the retransmission of the PINGREQ 219 message. One illustrative method for limiting retransmission of the PINGREQ 219 message is by using a retry counter that initiates putting the client 201 back to sleep when a retry limit count of the retry counter is reached and the client still does not receive the PINGRESP 221 message.
From the asleep 207 state or the awake 209 state, a client 201 can return either to the active 205 state by sending a CONNECT 215 message, or to the disconnected 213 state by sending a DISCONNECT 217 message with no duration field included. The client 201 can also modify its sleep duration by sending a DISCONNECT 217 message with a duration field that specifies a new value of the sleep duration.
FIG. 3 describes the meanings of several symbols used in the flowchart of FIGS. 4-5. A first symbol 10 is used to represent a program state. A second symbol 20 is used to represent internal processing. A third symbol 30 is used to represent a timeout or an internal event. A fourth symbol 40is used to represent a sending of a message. A fifth symbol 50 is used to represent a receiving of a message. A sixth symbol 60 is used to represent a decision.
FIGS. 4-5 together comprise a flowchart setting forth an illustrative operational sequence performed by a sleeping client 201 (FIG. 2) where the client first connects to a broker (such as gateway/broker 203) and then initiates a sleep state. Essentially, FIGS. 4-5 depict a state diagram for the client 201 (FIG. 2) in the context of the sleeping methodology previously described with reference to FIGS. 2 and 6. While in the sleep state, the client interacts periodically with the broker to tell the broker that the client is still available, and possibly to receive updates from the broker.
Referring to block 401 of FIG. 4, the client first connects to a gateway/broker 203 (FIG. 2), waits to receive an acknowledgment of the connection from the gateway/broker (FIG. 4, block 403), and either times out (block 407) while waiting for the acknowledgment, or receives the acknowledgment (block 405). If the time out occurs (block 407), a decision is made at block 409 to either try again by looping back to block 401, or to not try again by advancing ahead to block 423 where the gateway/broker is considered to be lost.
If the acknowledgment is received (block 405), the procedure advances to block 411 where the client goes into the active state. The client sends a DISCONNECT message that includes a sleep duration to the broker (block 413). The procedure temporarily remains in a wait DISCONNECT state (block 415), and either times out (block 419) or receives a DISCONNECT message (block 417). If the time out occurs (block 419), a decision is made at block 421 to either try again by looping back to block 413, or to not try again by advancing ahead to block 423 where the gateway/broker is considered to be lost. If the DISCONNECT message is received (block 417), the client enters the asleep state, also referred to as "sleeping mode" (block 425).
Referring now to block 501 (FIG. 5), the client enters the asleep state (i.e., sleep mode). At block 503, a transponder or transceiver (i.e., a radio) of the client is turned off. The client sleeps at block 505. A timeout occurs at block 507. The radio is turned on at block 509. A PINGREQ message is sent at block 511. At block 513, the client waits for a PINGRESP message. A timeout may occur (block 517), or a PINGRESP message may be received by the client (block 519), or another message may be received by the client (block 521). If the time out occurs (block 517), a decision is made at block 523 to either try again by looping back to block 511, or to not try again by advancing ahead to block 527 where the gateway/broker is considered to be lost. If the PINGRESP message is received (block 519), the procedure loops back to block 501. If another message is received by the client (block 521), then the client deals with this message (block 525), and the procedure loops back to block 513.
The procedures described with reference to FIGS. 2-6 permit one or more clients (such as client 201) to be easily implemented by low cost sensor devices. These procedures release gateways 140, 150 (FIG. 1), which are illustratively implemented using wireless routers, from buffering messages for the sleeping devices, thus allowing the routers to serve large numbers of sensor devices which may have relatively lengthy sleeping periods. The gateway/broker 203 (FIG. 2) is able to detect the loss of a client device (e.g., a persistent failure) not only while the client device is actively communicating, but also while the client device is sleeping.