Wireless communication system and method of managing energy consumption of a wireless device

A wireless communication system includes gateway, a server, and a wireless device. The server is configured to send a heartbeat of a plurality of heartbeats to the wireless device upon expiration of a respective heartbeat interval of a plurality of heartbeat intervals. The wireless device is configured to send a plurality of Power Save polls to the Access Point device, wherein each Power Save poll of the plurality of Power Save polls retrieves a respective heartbeat of the plurality of heartbeats.

BACKGROUND

The present disclosure relates to a communication system and, more particularly, to a wireless communication system and method of reducing energy consumption of wireless devices of the system.

Wireless communication systems may include a wireless device, such as an Internet of Things (IoT) device that may be smart and is powered by batteries. Such wireless devices may operate in different energy modes, such as sleep and awake modes to, at least in part, preserve battery life. The wakeup frequency and duration of the wireless device in the different energy modes may not always be optimal in terms of preserving battery life, and may be dependent upon other parameters and/or characteristics of the communication system.

Wi-Fi Power Saving Mode (PSM) is one example of a communication technology utilized by battery powered IoT devices to establish and maintain a Wi-Fi link with an Access Point (AP) device. With Wi-Fi PSM, IoT devices may enter into a sleep state for a predetermined amount of time to save energy after providing notification to the AP device of the IoT device's change in state (i.e., from awake to sleep states). When notified, the AP device may start buffering packets for the sleeping IoT device. The IoT device must awake periodically to check beacons from the AP device that indicate if a buffered packet exists for the IoT device. If a buffered packet does exist, the IoT device retrieves the packet via a Power Save (PS) Poll message.

Unfortunately, IoT devices must awake frequently to monitor the beacons for buffered packages thus expending energy from IoT device batteries. Moreover, the duration that an AP device will buffer a packet (i.e., time before the AP device drops the packet) for an IoT device is limited and manufacturer dependent, thus may be different from one AP device to the next. Therefore, awake periods of the IoT device are typically, conservatively, extended to reduce any chance of a buffered packet being dropped. Yet further, communications with the cloud may introduce unknown latencies, leading to less than optimal system performance. System improvements that preserve the battery life of IoT devices, and/or manage idle time of AP devices are desirable.

SUMMARY

A method of operating a wireless communication system according to one, non-limiting, embodiment of the present disclosure includes sending a first heartbeat from a server, through a gateway, and to a wireless device, wherein the first heartbeat includes at least a heartbeat interval; sending a first heartbeat response from the wireless device, through the gateway, and to the server for synchronizing the wireless device with the server; and changing from a first awake state to a first sleep state, wherein the first sleep state extends for a duration associated with the heartbeat interval.

Additionally to the foregoing embodiment, the method includes sending a Wi-Fi Enable Power Save Mode (PSM) signal from the wireless device to the gateway when in the awake state, wherein the gateway is an Access Point (AP) device and the wireless device is a PSM device.

In the alternative or additionally thereto, in the foregoing embodiment, the server is part of a cloud.

In the alternative or additionally thereto, in the foregoing embodiment, the first heartbeat is buffered by the gateway and the wireless device is a PSM device.

In the alternative or additionally thereto, in the foregoing embodiment, the method includes broadcasting an acknowledgement signal from the gateway to the PSM device in response to the Wi-Fi Enable PSM signal, and when in the awake state.

In the alternative or additionally thereto, in the foregoing embodiment, the heartbeat interval is about equal to combined durations of the first awake state and the first sleep state.

In the alternative or additionally thereto, in the foregoing embodiment, the method includes sending an application command to the server; buffering the application command by the server; and sending a second heartbeat that includes the application command from the server to the wireless device, upon expiration of the time interval.

In the alternative or additionally thereto, in the foregoing embodiment, the method includes buffering the application command by the gateway; entering a second awake state from the first sleep state approximately upon expiration of the heartbeat time interval; sending a Power Save (PS) poll from the wireless device to the gateway; and broadcasting the second heartbeat from the gateway and to the wireless device.

In the alternative or additionally thereto, in the foregoing embodiment, the application command is sent to the server by a mobile application.

In the alternative or additionally thereto, in the foregoing embodiment, the method includes sending a second heartbeat response from the wireless device, through the gateway, through the server, and to the mobile application; and entering a second sleep state from the second awake state.

In the alternative or additionally thereto, in the foregoing embodiment, the wireless device is configured to ignore any beacons broadcasted by the gateway.

A wireless communication system according to another, non-limiting, embodiment includes a gateway; a server configured to send a heartbeat of a plurality of heartbeats to the gateway upon expiration of a respective heartbeat interval of a plurality of heartbeat intervals; and a wireless device configured to retrieve a heartbeat of the plurality of heartbeats.

Additionally to the foregoing embodiment, the wireless device is a Power Save Mode (PSM) device configured to send a plurality of PS polls to the gateway, wherein each PS poll of the plurality of PS polls retrieves a respective heartbeat of the plurality of heartbeats.

In the alternative or additionally thereto, in the foregoing embodiment, each heartbeat interval of the plurality of heartbeat intervals equals the combined duration of an awake state and a sleep state.

In the alternative or additionally thereto, in the foregoing embodiment, the method includes a mobile application configured to send a mobile command to the server, wherein the server is configured to buffer the mobile command until the next heartbeat of the plurality of heartbeats is sent to the wireless device and buffered by the gateway, whereupon the mobile command becomes part of the next heartbeat.

In the alternative or additionally thereto, in the foregoing embodiment, the server is part of a cloud.

In the alternative or additionally thereto, in the foregoing embodiment, each PS poll of the plurality of PS polls is sent to the gateway approximately upon expiration of a respective heartbeat time duration of the plurality of heartbeat time durations.

In the alternative or additionally thereto, in the foregoing embodiment, the gateway is an Access Point (AP) device.

DETAILED DESCRIPTION

Referring toFIG. 1, an exemplary embodiment of a wireless communication system20is illustrated. The wireless communication system20may include a wireless device22, a gateway24(e.g., an Access Point (AP) device indicative of Wi-Fi), an application26that may be a user application, and a controller28that may be, or is part of, a cloud30. The controller28may be a server that includes a computing processor32and a storage medium34that may be computer writeable and readable. The wireless device22may be configured to communicate with the AP device24over a wireless pathway (see arrow36). The AP device24may be configured to communicate with the wireless device22, the controller28, and/or the application26over respective pathways (see arrows38,40,42) that may be wireless pathways. The cloud30, and/or controller28, may be configured to communicate with the AP device24over a pathway (see arrow44) that may be wireless, and the application26over a pathway (see arrow45) that may be wireless. The application26may be configured to communicate with the wireless device22over a pathway46that may be wireless, communicate with the AP device24over a wireless pathway (see arrow47), and/or communicate with the controller28over a pathway (see arrow49) that may be wireless. In one example, the mobile application26may directly connect to the cloud30via a third generation of mobile telecommunications technology (i.e., 3G), or indirectly through the AP device24(i.e., Home Wi-Fi). In some embodiments, the application26, as a user application, may be a mobile application. In other embodiments, the application26may be another wireless device such as a Wi-Fi PSM device, and/or the wireless device may include the application26. It is understood that the term “gateway” is treated broadly and is indicative of more than just Wi-Fi communications. For example, the gateway may support ZWave.

The AP device24may be a router having firmware that supports Wi-Fi Power Save Mode (PSM). The mobile application26may be a smart phone, a digital media player, a tablet computer, and other applications. Examples of a wireless device22may include smart home sensors or intrusion sensors of a security system configured to detect the opening of windows or doors, Passive Infrared (PR) sensors, image sensors (i.e., PIR sensor with camera), thermal sensors of a heating system configured to measure the temperature of ambient air, gas sensors configured to detect the presence of gases, smoke detectors as part of a safety system, and many other types of devices utilizing batteries and communicating wirelessly.

The wireless device22may further be a smart device, an Internet of Things (IoT) device, and/or a Wi-Fi PSM device configured to communicate with the cloud30through the AP device24. The wireless device22may include a power management module48(i.e., battery and a means of managing battery power), a sensor and/or actuator50, a computing processor52(e.g., microcontroller), and a wireless transceiver54. As a PSM device, the wireless device22is configured to enter into sleep and awake states at a pre-determined frequency and duration of time.

In one embodiment and when in a sleep state, internal timer(s) or counter(s)55of the processor52of the wireless device22may remain powered, but all other components of the wireless device22are generally turned off. The wireless device22may awake from the sleep state when a pre-specified awake time occurs, or when an enabled interrupt is triggered (i.e., an event sensed by the sensor50occurs). Generally, maximizing the sleep state durations and/or reducing or eliminating the need to track AP beacons, optimizes battery life. In one example, the preferred life for a battery of a low power IoT device is about four to five years.

The wireless communication system20eliminates the need for more traditional tracking of beacons broadcasted by the AP device24at the wireless device22, and thereby may maximize the standby time (i.e., sleep state duration) of the wireless device22. Beacons do not need to be tracked fir receiving a buffered packet from the AP device24, since a Power Save (PS) poll (i.e., PS poll signal) may be sent straight away from the wireless device22to the AP device24. The AP device24may reply to the PS poll with an Acknowledgement (ACK), (i.e., acknowledgement signal) followed by a buffered packet if a signal or data has been buffered by the AP device24for retrieval by the wireless device22, or directly with the buffered packets. If there is no packet buffered, the response is a no-data packet, or the ACK followed by the no-data packet. In the event that a no-data packet is received by the wireless device22, the wireless device22may return to a sleep state. If no packet is received by the wireless device22, the wireless device may return to a sleep state after a pre-specified duration of the awake state has expired (i.e., timed-out). After another pre-specified duration in a sleep state, the wireless device22will wake up again and send a PS poll to retrieve the buffered packet as previously described. The process will repeat until a data packet is received, or a pre-specified counter reaches its limit.

Referring toFIG. 2, a schematic generally outlining communications between the wireless device22, the AP device24, the server28(i.e., and/or cloud30), and the mobile application26along a timeline (see arrow56) is illustrated. This particular string of communications generally depicts a process wherein the wireless device22initiates Wi-Fi PSM without requiring the wireless device22to track beacons sent by the AP device24. That is, the wireless device22is configured to ignore the beacons broadcasted by the AP device24.

More specifically, the wireless device22of the communication system20may send a first request58(i.e., heartbeat or request signal) through the AP device24and to the server28when in a first awake state60(i.e., the PSM). Upon receiving the first request58, the AP device24may send an acknowledgement (ACK)62to the wireless device22. The ACK62may be a Wi-Fi ACK at a MAC level. After receiving the ACK62, the wireless device22may enter into a minor sleep state64. The minor sleep state64has a conservative duration that is longer than an uplink latency (see arrow68), but may be shorter than the summation of the uplink latency68plus a buffer timeout duration. In one embodiment, the minor sleep state64duration may be shorter than the buffer timeout duration.

In one embodiment, and generally while the wireless device22is in the minor sleep state64, the server28may receive the first request58from the AP device24and, send a first response66to the AP device24. In general, the uplink latency68may be measured from the time that the AP device24receives the first request58to the time that the AP device24receives the first response66. It is understood that the first response66may not contain any command language, or command data, and may instead be an empty packet, a registration request, information on status, and/or other related responses. In one embodiment, the uplink latency68may be less than the duration of the summation of the first awake state60plus the duration of the minor sleep state64.

The first response66may be buffered by the AP device24, and thus awaits retrieval by the wireless device22as a data packet70(i.e., buffered packet). Because the minor sleep state64duration is generally less than the summation of the uplink latency68and the AP buffer timeout duration, the data packet70will not be dropped by the AP device24. Unlike other data packets to be described below, data packet70may not contain a command from the mobile device26, and instead may contain information such as registration information, status information, and the like.

From the minor sleep state64, the wireless device22may enter into a second awake state72. When in the second awake state72, the wireless device22may send a first Power Save (PS) poll74to the AP device24. In response to the first PS poll74, the AP device24may send the buffered data packet70to the wireless device22. After receiving the data packet70, the wireless device22may send an ACK76to the AP device24, and then enter into a major sleep state78.

The major sleep state78duration may be as long as reasonably possible, but shorter than an idle time of the AP device24to prevent disassociation of the AP device24from the wireless device22. The duration of the major sleep state78is considerably longer than the duration of the minor sleep state64, and thus facilitates a reduction in energy consumption of the wireless device22. In one embodiment, the duration of the minor sleep state64may be about one (1) second, and the duration of the major sleep state78may be about fifty (50) seconds. Moreover, the major sleep state78may be more energy efficient than the minor sleep state64because in the minor sleep state64only the transceiver54and some addition hardware may be switched off. In the major sleep state78, the transceiver54, various hardware, the processor52(e.g., CPU), and some voltage regulators may be switched off. That is, for the major sleep state78, only the real time counter55or oscillator may remain on to trigger an interrupt on the processor to awake the processor.

In one embodiment, receipt of the first data packet70enables the wireless device22to determine if further actions need to be performed, for example, a command to take a picture. More specifically, the data packet70may contain a command that requires processing by the wireless device22, and execution of the command that may entail sending a command response (not shown), from the wireless device, through the AP device24, and to the server28. It is further understood that the ACK76(i.e., or the ACK part of the data packet70) functions to indicate if there are multiple packets to be retrieved. If there are multiple packets, multiple PS polls would be sent until all of the buffered packets are retrieved.

It is contemplated and understood that prior to receipt and buffering of the data packet70by the AP device24, and thus prior to the second awake state72, the wireless device22may awake and send at least one PS poll (not shown inFIG. 2) that is acknowledged by the AP device24, and wherein the AP device24then sends a no-data packet (not shown) to the wireless device24. The no-data packet is originated by the AP device24as a result of the associated PS poll and not having any buffered packet for the wireless device22, and is therefore not buffered by the AP device. Upon receipt of the no-data packet by the wireless device22, the wireless device may return to a sleep state until the next PS poll.

The server28may be configured to receive command signals80(e.g., command request) from the mobile application26. In one example, the command signal80may be associated with a learned buffer timeout duration to be discussed further below. Once received, the server28may buffer the command signal80, while awaiting retrieval by the wireless device22through the AP device24. Generally, it is understood that the buffer timeout duration of a cloud server may be substantially longer than the buffer timeout duration of the AP device24which may be manufacturer dependent.

While the command signal80is buffered by the server28, the wireless device22may enter into a third awake state82from the major sleep state78. While in the third awake state82, the wireless device22may send a second request84(i.e., retrieval request), through the AP device24, and to the server28. After sending the second request84, the wireless device22may enter into a second minor sleep state86. The second request84may generally be an inquiry for data or commands from the cloud. In the present example, the second request84enacts retrieval of the command signal80from the server28for buffering at the AP device24. That is, in response to the second request84, the server28forwards the command signal80to the AP device24, where the command signal80is, again, buffered as a data, or command, packet.

While the command signal80may be buffered by the AP device24, the wireless device22may enter into a fourth awake state88from the second minor sleep state86. While in the fourth awake state88, the wireless device22may send a second PS poll90to the AP device24. In response to the second PS poll90, the AP device24may send the data packet associated with the command signal80to the wireless device22. Upon receipt of the data packet, the wireless device22may send an ACK92to the AP device24, may perform an action in accordance with the data packet, and may then enter into a second major sleep state94. It is understood that the process of retrieving data packets from the cloud30via cloud requests and AP polling of the AP device24may generally repeat itself during normal operation. Such requests and polling may eliminate any need for more traditional tracking of beacons, thus enhancing operation of the power management module48and preserving battery life.

Advantages and benefits of the non-beacon-tracking, wireless, communication system20includes a reduction in the energy consumption of wireless devices22by avoiding the need to track AP beacons by the wireless device22, and maximizing the time the wireless device22may stay in a sleep mode without losing packets at the AP device24. The method of operating the system20may be applied to legacy AP devices, and may be more efficient than legacy Wi-Fi PSM protocol when the wireless device22is certain that the AP device24is buffering a packet for the wireless device. This may be true for wireless devices that stay in a sleep state for most of the time, since periodic heartbeats may be exchanged between the cloud30and the devices. The following method may assist the wireless device22in optimizing the minor sleep state duration according to buffer capability of the AP device24, which may make the device more energy efficient when requesting data from the cloud server(s)28since the cloud latencies have a lower or null impact on it.

Measuring Buffer Timeout Duration

The buffer timeout duration of the AP device22is generally a manufacturer trait or parameter of the device itself, and may not be typically known by the end user. The buffer timeout duration is generally that duration (i.e., interval of time) that the AP device24will hold onto a packet awaiting retrieval by the wireless device22. If the wireless device22does not retrieve the packet before expiration of the buffer timeout duration, the AP device24will drop the packet. Once the packet is dropped, the packet is not retrievable by the wireless device22.

Referring toFIG. 3, a schematic generally outlining communications between the wireless device22, the AP device24, the cloud30, and the mobile application26along a timeline (see arrow100) is illustrated. This particular string of communications generally depicts a learning process wherein a buffer timeout duration (see arrow102) of the AP device24is determined. That is, the wireless communication system20may be configured to measure at least a duration102of a buffer timeout that generally represents the maximum amount of time that the AP device24will hold a package before dropping the package (i.e., deleting the package). Once learned, a signal (see arrow104) associated with the buffer timeout duration102may be sent from the mobile application26, through the cloud30, and to the wireless device22to facilitate maximizing the sleep state.

Referring toFIGS. 3 and 4, the method may begin with block200wherein the mobile application26sends a Wi-Fi Enable PSM106(i.e., signal) to the AP device24. At block202, the AP device24sends an acknowledgement (ACK)108to the mobile application26indicating to the mobile application26that the Wi-Fi enable PSM106was received. In one embodiment, the ACK108may be a Wi-Fi MAC ACK. At block204, the AP device24may begin to broadcast periodic beacons110(e.g., Wi-Fi beacons) at a pre-determined time interval (see arrows112) that are received by the mobile application26. The information bits contained in the beacons110may indicate the lack of a buffered packet at the AP device24for the mobile application26. In one example, the time interval may be about one-hundred milliseconds (100 ms).

At block206, the mobile application sends a heartbeat114(i.e., cloud request) just prior to, or during, the sending of the plurality of beacons110, through the AP device24and to the cloud30. At block208, the cloud30sends a response116associated with the cloud request114to the AP device24. A server or cloud latency duration (see arrow118) may be determined and may be measured from the time the AP device24sends the request114to the cloud30and the time that the AP device24receives the response116.

At block210, the AP device24buffers the response116for the duration102of the buffer timeout. At block212, during the buffering time interval, periodic beacons120are broadcasted from the AP device24at the pre-determined time interval112and received by the mobile application26. The information bits in the beacons120are updated compared to the previous beacons110to indicate the presence of the buffered packets (i.e., associated with the response116) at the AP device24for the mobile application26. At block214, the buffered packet is dropped by the AP device24indicating the end of the buffer timeout duration102.

At block216, at least one beacon110(i.e., indicative of no buffered package) is broadcasted by the AP device24and received by the mobile application26. At block218, the mobile application calculates the buffer time out duration at a function of the time interval112times the number of beacons120received. At block220, the mobile application26sends the buffer timeout duration signal104, through the AP device24, through the cloud30, and to the wireless device22for maximizing the sleep state to preserve battery energy. It is understood that to avoid dropping buffered packets, the duration of each sleep state is less than the summation of the uplink latency68(i.e., cloud latency duration) and the buffer timeout duration102.

Advantages and benefits of learning the AP buffer timeout duration as described herein includes a method that is non-intrusive, and the facilitation of power save methods to maximize the wireless device sleep interval without dropping packets.

Measuring AP Idle Time

The AP idle time is another trait of the AP device22and may be configured by the end user. The AP idle time is generally that amount of time allotted before the AP device24disassociates the wireless device22from the network. More specifically, if the wireless device22remains silent (i.e., no heartbeats, no Wi-Fi Power Save (PS) polls, and/or no acknowledgements) for the duration of the AP idle time, the wireless device22may be disassociated from the AP device24. In such an example, a re-association process may then be performed. Because the re-association process expends energy from the wireless device22, avoidance of disassociation is desirable. Typically, the AP idle time is much longer than the buffer timeout duration. For example, an AP idle time may be about five (5) minutes, and a buffer timeout duration may be about one (1) to five (5) seconds.

Referring toFIG. 5, a schematic generally outlining communications between the wireless device22, the AP device24, and the server28(e.g., cloud30), along a timeline (see arrow122) is illustrated. This particular string of communications generally depicts a learning process wherein the AP idle time (see arrow124) of the AP device24is determined or measured. That is, the wireless communication system20may be configured to measure at least a duration of the AP idle time124that generally represents the period of time before the AP device24disassociates the wireless device22due to inactivity. Once the AP idle time124is known, the time interval between heartbeats128,170initiated by the wireless device22may be maximized, but not so long that disassociation occurs. In one example, the AP idle time124may be about four hundred (400) seconds. It is contemplated and understood that the wireless device22may not be a PSM device, or may not be operating in a PSM when the AP idle time is being learned/calculated.

It is further understood that the wireless device22may not initiate the AP idle time learning process, instead, the idle time learn command may be sent without a preceding heartbeat from the wireless device22. That is, the command may initiate from the cloud30, and through the AP device24, or the command may initiate from the mobile application26(i.e., the method is executed by the mobile application26and the command is input directly by the user through a screen of the user application).

Referring toFIGS. 5 and 6, one example of a method of learning the AP idle time124(i.e., idle timeout) of the AP device24is generally illustrated. Once learned, the AP idle time124may be applied as part of a PSM strategy that avoids disassociation while applying any number of other strategies and learning processes that take into account at least one of the buffer timeout duration and uplink latency68, and to enhance communication efficiency (e.g., preserve battery life of the wireless device22).

In one embodiment of a method, and at block300(seeFIG. 6), the heartbeat126is sent from the wireless device22, through the AP device24, and to the server28when the wireless device22is in an awake state130. At block302and while the wireless device remains in the awake state130, the AP device24may send an ACK131to the wireless device22in response to receipt of the heartbeat26. At block304and as a result of receiving the heartbeat126, the server28may send a learn idle time command132through the AP device24, and to the wireless device22. As part of this learn idle time command132, a default value of about five (5) minutes may be assigned as the AP idle time.

It is contemplated and understood that the wireless device22as described and illustrated inFIG. 5, is operating in a PSM during the awake state130. However, in another embodiment, the wireless device22may not be operating in the PSM during the awake state130. Similarly, and as illustrated inFIG. 5, the AP device24may disassociate from the PSM device22as part of the idle time learning process. Alternatively, disassociation between devices22,24may not occur. Instead, the AP device may send a forewarning of disassociation, and with a proper response from the PSM device22, actual disassociation may be prevented. It is further understood that the awake state130is a dedicated state used to generally perform the measurement task of learning the AP idle time. That is, during this time, the wireless device22is generally inactive and may not send out messages.

At block306and while the wireless device remains in the awake state130, the wireless device22may send a Wi-Fi Enable PSM signal134in response to the learn idle time command132to the AP device24. At block308and while the wireless device22remains in the awake state130, the AP device24may send an ACK136to the wireless device22in response to receipt of the Wi-Fi Enable PSM signal134. At block310, the counter55(seeFIG. 1) of the wireless device22may be started when the Wi-Fi Enable PSM signal134is sent. At block312, the AP device may begin to broadcast a plurality of no-data beacons138to the wireless device22at prescribed time intervals (see arrow140) and while the wireless device22remains in the awake state130tracking those beacons.

At block314, the AP device24may buffer an inactivity message142that may be a disassociation message (i.e., packet). At block316, the AP device24broadcasts a data beacon144to the wireless device22while the wireless device is in the awake state130. At block318and in response to the data beacon144, the wireless device22sends a PS poll146to the AP device24to retrieve the inactivity message142. At block320, the AP device24sends the inactivity message142to the wireless device22in response to the PS poll146. At block322, the wireless device22may send an ACK148to the AP device24in response to receipt of the inactivity message142. It is understood and contemplated that if the wireless device22is not in the PSM, the inactivity message142may not be buffered, and instead, may be sent directly to the wireless device22.

At block324, the counter55may be stopped when the wireless device22receives the data beacon144, thereby facilitating measurement of the AP idle time124. It is contemplated and understood that the AP idle time124may be measured by the start and stop points of the counter itself. That is, the counter55may be a count-up timer. Alternatively, the counter55may function as an event counter capable of counting the number of no-data beacons138and multiplying this number by the prescribed time interval140. At block326, the wireless device22may send a re-association signal150to the AP device24. At block328, the AP device24may send an ACK152to the wireless device22in response to receipt of the re-association signal150.

At block330, the wireless device22may send a Wi-Fi Enable PSM signal154to the AP device24. At block332, the AP device24may send an ACK156to the wireless device22in response to receipt of the Wi-Fi Enable PSM signal154. At block334and upon receipt of the ACK156, the wireless device22may enter into a first sleep state158from the awake state130. At block336, the wireless device22enters a second awake state160from the first sleep state158. At block338and during the second awake state160, the wireless device22sends the second heartbeat128that contains data relative to the measured/learned AP idle time124, through the AP device24, and to the server28. It is contemplated and understood that the sleep state158may not be needed, or may not occur. Instead, heartbeat128may be sent when the wireless device22is still in the awake state130.

At block340, the wireless device22enters a second sleep state162from the second awake state160, and after the heartbeat128is sent. At block342, the server stores the learned AP idle time124and associates the parameter to the specific AP device24. Because the learned AP idle time124is stored by the server28(i.e., data table), the server28may forward the learned AP idle time to other wireless devices utilizing the same AP device24. At block344, the server28sends a response164that may be a no-command response to the AP device24. The term “no-command” in this context means that the response164may not contain a command from the mobile device26. At block346, the response164may be buffered by the AP device24. At block348, the system20may generally depart from the learn AP idle time process and begin normal operation.

In the present example and referring further toFIG. 5, normal operation may entail first entering a third awake state166from the second sleep state162for the purpose of sending a PS poll168to the AP device24while the response164is being buffered by the AP device24. Once polled, the AP device24sends the response164to the wireless device22, and the wireless device22responds with an ACK170before returning to a sleep state172. The wireless device22may then awake again to send yet another heartbeat174as part of a normal operation.

Advantages and benefits of learning the AP idle time as described herein includes a method that is non-intrusive, and the facilitation of power save methods to maximize the wireless device sleep interval without losing association and authentication with the AP. The present method is non-intrusive because if a user sends commands to the wireless device22while executing the discovery, the cloud30may stop the method or process, forward client commands, and re-start the idle time learning process at a later time.

Typically, the uplink latency68, which may be measured in milliseconds, is much shorter than the buffer timeout duration that may be measured in seconds. Moreover, the uplink latency68(seeFIG. 2) may be dependent upon the speed of, for example, the server28in any given moment in time, and thus may change. Therefore, measurement of the uplink latency68may be an average over several periods measured. Traditionally, measuring uplink latency68was difficult and intrusive because battery life is consumed, and the period in which a cloud response was buffered in the AP device24was unknown.

Referring toFIG. 7, a method of measuring uplink latency (see arrow68) is illustrated, and is applicable with wireless communication systems having low power IoT devices22that periodically send heartbeats (i.e., requests) to a server28(as examples, see heartbeat58inFIG. 2, heartbeat114inFIG. 3, and heartbeats126,128,174inFIG. 5). With continued reference toFIG. 7, the mobile application26may send a query176, through the AP device24, and to the server28. The server28may then send a query response178, through the AP device24, and to the mobile application26. The time expended, and measured by the mobile application26from the instant the mobile application sends the query176to the instant the mobile application26receives the query response178is the uplink latency68.

Once the uplink latency68is measured, the mobile application26may send this information, as an uplink latency signal180, to the server28. The server28may then store and/or buffer the measured uplink latency68until the server sends the next heartbeat response182to the wireless device22in response to a heartbeat184from the wireless device22that is sent after cloud latency signal180. That is, the uplink latency68may be included as part of the data contained in the heartbeat response182. The wireless device22may then, in-part, adjust sleep state(s) in accordance with the measured uplink latency68to, for example, conserve energy expended by the wireless device22. Because the speed of the server28may vary over time, the mobile application26may send multiple queries176, receive multiple query responses178, and may average the multiple, measured, uplink latencies to achieve an averaged uplink latency value.

It is contemplated and understood that this technique may also be applied to detect the “Buffer Overflow Duration.” It may not only detect the predefined buffer timeout duration, but also the time it takes a buffer to get full and start discarding packets due to network congestion.

Advantage and benefits of the present method of measuring uplink latency includes a non-intrusive technique that may be applied to low power, wireless, devices22that utilize heartbeats. Other advantages include the acquisition of the uplink latency information without expending additional energy by the wireless device22, because additional messages are not exchanged with the server28to obtain the measurement.

Referring toFIG. 8, a schematic generally outlining another embodiment of communications between the wireless device22, the AP device24, the server28(i.e., and/or cloud30), and the mobile application26along a timeline (see arrow56) is provided. This particular string of communications generally depicts a process wherein energy consumption in Wi-Fi PSM devices22may be reduced by eliminating the need of sending heartbeats from the PSM devices22, and eliminating the tracking of AP beacons, by synchronizing the waking (i.e., entering of the awake state) of the PSM device22with cloud30initiated requests.

To ensure packets are buffered at the AP device24, the server28may generate a server heartbeat. Attached to the server heartbeat may be a heartbeat interval and any variety of commands for the PSM device22. In operation, the PSM device22will wake up, receive the server heartbeat(s), respond to any commands/requests as part of the heartbeat, and return to a sleep state until expiration of the heartbeat interval402as part of the previously sent heartbeat. In case synchronization with the server28is lost, the PSM device22may remain awake until the next heartbeat (i.e., a full server heartbeat interval) to re-synchronize with the server28.

More specifically, a wireless communication process may begin with a registration and synchronization phase (see arrow399) while in an initial awake state400, wherein the wireless device22sends a registration message401to the server28. A registration response402containing synchronization information is sent from the server28to the wireless device22through the AP device24. The wireless device22may then send a synchronizing heartbeat response404, through the AP device24, and to the server28. Also during the synchronization phase399and while in the initial awake state400, the wireless device22may send a Wi-Fi enable PSM signal406to the AP device24, and may receive an ACK408from the AP device24in response. Upon receiving the ACK408, the wireless device22may enter a sleep state410. The heartbeat402may contain information relative to a heartbeat interval (see arrow412) that represents a duration measured from the instant the wireless device22enters an awake state and to the end of the next sleep state. It is understood that in this embodiment, heartbeats are used to synchronize and no difference may exist from one heartbeat to the next.

Referring toFIGS. 8, 9A and 9B, a method of operating the “cloud initiated, non-beacon-tracking, wireless, communication system”20is generally illustrated. At block500, the heartbeat402may be sent from the server28, through the AP device24, and to the wireless device22(e.g., PSM device). The heartbeat402includes information relative to the heartbeat interval412and thus instructs the wireless device22when to awake. At block502, the first heartbeat response404is sent from the PSM device22, through the AP device24, and to the server28for synchronizing the PSM device22with the server28.

At block504, the Wi-Fi Enable PSM signal406is sent from the PSM device22to the AP device24when in the awake state400. At block506, the ACK signal408is sent from the AP device24to the PSM device22in response to the Wi-Fi Enable PSM signal406. At block508, the PSM device22enters a first sleep state410from the first awake state400. The summation of the durations of first awake state400and the first sleep state410is about equal to the heartbeat interval412.

At block510and during normal operation, an application command414is sent from the mobile application26to the server28. At block512, the application command414may be buffered by the server28until the coinciding heartbeat interval412has expired. At block514and upon expiration of relevant heartbeat interval412, the buffered application command414is advance to the AP device24via a second heartbeat416sent upon expiration of the coinciding heartbeat interval412and initialization of the next interval. At block516, the second heartbeat416, and thus the application command414, may be buffered by the AP device24. It is contemplated and understood that AP buffering of the heartbeat416may not occur, or may be generally short. However, this AP buffering capability provides a degree of system tolerance if the wireless device22is not exactly synchronized to the server28, or to some degree becomes un-synchronized.

At block518, the wireless device22may enter into a second awake state418from a previous sleep state, and approximately upon expiration of the coinciding/associated heartbeat time interval412. At block520, a Power Save (PS) poll420may be sent from the PSM device22to the AP device24. At block522, the second heartbeat416may be sent from the AP device24to the PSM device22. At block524, an ACK422may be sent from the PSM device22to the AP device24. At block526, a second heartbeat response424may be sent from the PSM device22, through the AP device24, through the server28, and to the mobile application26. At block528, the PSM device22enters a second sleep state426from the second awake state418. At block530, the PSM device22enters a third awake state428from the second sleep state426approximately upon expiration of the associated heartbeat interval412, and the PS poll process generally repeats itself.

Advantages and benefits of the “cloud initiated, non-beacon-tracking, wireless, communication system” may include the ability of PSM devices22to ignore the AP device24beacons, and the extension of time that PSM devices may stay in the sleep state without dropping packets. Other advantages include a non-beacon-tracking method of operation that is more efficient than tradition Wi-Fi PSM because the PSM device22does not need to wake up to track beacons, thus the PSM device may sleep for longer time intervals (i.e., up to AP disassociation time). Server synchronization may permit message exchange to start on the server28side, reducing the time the device22must be active due to the heartbeat generation and uplink latency68. Moreover, the implementation of this method in a multicore system (i.e., one processor for Wi-Fi communications and another for the application), may become even more efficient since the application core does not need to be woken up if commands are not received by the Wi-Fi core.

The various functions described above may be implemented or supported by a computer program that is formed from computer readable program codes and that is embodied in a computer readable medium. Computer readable program codes may include source codes, object codes, executable codes, and others. Computer readable mediums may be any type of media capable of being accessed by a computer, and may include Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or other forms.

Terms used herein such as component, module, system, and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software execution. By way of example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. It is understood that an application running on a server and the server may be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

While the present disclosure is described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the spirit and scope of the present disclosure. In addition, various modifications may be applied to adapt the teachings of the present disclosure to particular situations, applications, and/or materials, without departing from the essential scope thereof. The present disclosure is thus not limited to the particular examples disclosed herein, but includes all embodiments falling within the scope of the appended claims.