Patent Description:
In order to receive a DTIM beacon, a network-connected device powers up wireless communication circuitry when the DTIM beacon is expected to be received. For intervals during which DTIM beacons are not expected to be received, and during which no data is being transferred between the access point and a network-connected device, the network-connected device may enter a low power mode (e.g., a sleep mode), during which the communication circuitry may be powered down or kept in a low-power state.

In some scenarios, a network-connected device (especially one powered by batteries) may be configured to conserve even more power by periodically skipping DTIM beacons and remaining in the low power mode. Such a device may keep its wireless communication circuitry powered down while skipping DTIM beacons, thereby conserving power. However, the power savings achieved by skipping the reception of DTIM beacons comes at the cost of added latency, since the communication circuitry wakes less frequently to check for traffic.

In <CIT> a listen interval of a WLAN client is selected to have one of a plurality of values, including a start listen interval (SLI) and one or more longer listen intervals (e.g., transient listen interval (TLI), maximum listen interval (MLI)). The listen interval is set to SLI in response to (<NUM>) detecting that an applications processor of the WLAN client is in an awake state, (<NUM>) detecting transmit/receive activity on the wireless link, and (<NUM>) failing to detect an expected beacon signal on the wireless link. If the listen interval is set to MLI (or TLI) and the WLAN client fails to detect an expected beacon signal (beacon miss), the listen interval is temporarily set to SLI. If the WLAN client then detects an expected beacon signal before detecting a predetermined number of consecutive beacon misses, the listen interval is immediately returned to the original listen interval MLI (or TLI).

This disclosure describes systems and methods for adaptively skipping the reception of DTIM beacons in order to more effectively balance power conservation with latency. Such systems and methods adaptively adjust the rate at which a battery-powered, network-connected device powers on communication circuitry in order to receive a DTIM beacon. Further, these rate adjustments may be based on anticipated interactions with the battery-powered device. When such an interaction is anticipated (e.g., a user accesses an application associated with the battery-powered device), the battery-powered device receives DTIM beacons at an increased rate. As a result, when the anticipated interaction is subsequently performed (e.g., the user requests, using the accessed application, access to a video stream provided at the battery-powered device), the battery-powered device can respond to the interaction (e.g., provide the requested video data) more quickly.

The proposed solution relates to a method of independent claim <NUM>, a method of independent claim <NUM>, and a Wi-Fi integrated circuit of independent claim <NUM>.

Thus, systems, methods and devices are provided for adaptively adjusting the rate at which battery-powered devices skip DTIM beacons, thereby enabling increased power savings and decreased latency.

For a better understanding of the various described implementations, reference should be made to the Detailed Description below, in conjunction with the following drawings in which like reference numerals refer to corresponding parts throughout the figures.

Battery-powered devices may conserve energy by entering a low-power state during which various components are powered down or left in a low-power state. While in such a low-power state (also referred to as power saving Wi-Fi mode or sleep mode herein), wireless communication circuitry may be powered down as well, causing beacons (including DTIM beacons) transmitted by a wireless local area network (WLAN, Wi-Fi) access point (AP) to be ignored. A battery-powered device may be configured to wake from the low-power state to periodically receive DTIM beacons. DTIM beacons that were transmitted by the access point while a battery-powered device is in a low-power state can be referred to as having been skipped. The following disclosure describes systems and methods for adaptively adjusting the rate at which battery-powered devices, with power-saving modes wake to receive, and/or stay asleep to skip reception of, DTIM beacons.

<FIG> is a diagram of a network environment <NUM> in accordance with some implementations. The network environment <NUM> includes a battery-powered device <NUM>, one or more communication networks <NUM>, an access point (AP) <NUM>, a server system <NUM>, and a client device <NUM>.

The battery-powered device <NUM> may be any electronic device configured for wireless network communication and powered by one or more batteries <NUM>. An example battery-powered device <NUM> is a camera device (e.g., a security camera, a doorbell camera, a light, or any other battery-powered device including a camera configured to record and/or stream video and/or audio data). The battery-powered device <NUM> includes memory <NUM> storing programs that, when executed by processor(s) <NUM>, perform one or more of the functions described below with reference to <FIG> and <FIG>. In some implementations, the memory <NUM> is a non-transitory computer-readable storage medium. The processor(s) <NUM> are configured to execute the programs stored in the memory <NUM>. The battery-powered device <NUM> includes communication circuitry <NUM>. For example, the communication circuitry <NUM> can be a Wi-Fi chip (also referred to as a Wi-Fi transceiver, a Wi-Fi system-on-chip, a Wi-Fi module, or a wireless communication module) including one or more radios, a controller, and other circuitry configured to provide network connectivity for the battery-powered device <NUM> (e.g., transmit and receive wireless communications to and from communication network(s) <NUM>). The communication circuitry <NUM> is configured to send and receive communications <NUM> (e.g., <NUM>, <NUM>, and <NUM> as described in more detail below) to and from other network devices via the communication network(s) <NUM>. In some implementations, the battery-powered device <NUM> includes one or more sensors <NUM>. For implementations in which the battery-powered device <NUM> is a camera device, the sensor(s) <NUM> include an image sensor, and the processor(s) <NUM> are configured to process (e.g., record and compress) image data recorded by the image sensor.

The communication network(s) <NUM> comprise one or more wide area networks such as the Internet. The communication network(s) <NUM> are in communication with a wireless access point <NUM> (e.g., a WLAN router) configured to route communications to and from the battery-powered device <NUM> via a wireless local area network such as a network implementing the IEEE <NUM> standard (a Wi-Fi network), in particular the IEEE <NUM> standard of <NUM> and any later version such as <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11ac, <NUM>. 11ax, and <NUM>. The communication network(s) <NUM> and access point <NUM> facilitate transmissions of data packets between the battery-powered device <NUM> and other devices connected to the network, such as a server system <NUM> and a client device <NUM>. In some implementations, the access point <NUM> is communicatively coupled to the battery-powered device <NUM>, and the access point <NUM> is configured to buffer data addressed to the battery-powered device <NUM> while the battery-powered device <NUM> is in a low power state. In some implementations, the access point <NUM> is configured to synchronize the local network including the battery-powered device <NUM> by transmitting beacons (including DTIM beacons <NUM>) to network-connected devices according to the IEEE <NUM> standard.

The server system <NUM> comprises one or more servers in communication with the communication network(s) <NUM>. In some implementations, the server system <NUM> receives messages, commands, and other types of data from a client device <NUM>, processes the received data, and transmits messages, commands, and other types of data to the battery-powered device <NUM> via the communication network(s) <NUM>. The server system <NUM> may also receive data (e.g., video and/or audio data) from the battery-powered device <NUM>, process and/or store the received data, and transmit the received data to a client device <NUM> via the communication network(s) <NUM>. In some implementations, the server system <NUM> executes an Internet service that enables users of client devices <NUM> to program, interact with, and review information from network-connected, battery-powered devices <NUM>.

The client device <NUM> may be an electronic device configured for wired or wireless network communication via communication network(s) <NUM>. For example, the client devices <NUM> may be a mobile device (smartphone), a laptop/desktop/tablet computer, an electronic assistant device (speaker assistant, display assistant), or any other device used by a user to interact with other devices connected to communication network(s) <NUM>. The client device <NUM> includes a processor <NUM> and memory <NUM> storing programs that, when executed by the processor <NUM>, perform one or more of the functions described below with reference to <FIG> and <FIG>. The client device <NUM> includes communication circuitry <NUM> for transmitting and receiving communications <NUM> (e.g., <NUM>, <NUM>, and <NUM> as described in more detail below) to and from other network devices via the communication network(s) <NUM>. In some implementations, the client device <NUM> includes a user interface (UI) module <NUM> configured to accept user inputs (e.g., a touch screen or a microphone) and display outputs (e.g., a display or a speaker).

In some implementations, the UI module <NUM> displays one or more affordances 142a-i, each of which is associated with a respective application App1-N stored in the memory <NUM> and executable by the processor <NUM>. Alternatively, the UI module <NUM> does not display the affordances 142a-i, but accepts vocal commands for executing or otherwise interacting with the applications APP1-N. An example application (App6, accessed by selection of affordance <NUM>-f or by voice command) is associated with the battery-powered device <NUM>. Specifically, the application associated with the battery-powered device <NUM> is configured to facilitate user interactions with the battery-powered device <NUM>. For example, if the battery-powered device <NUM> is a camera device, the application (App6) displays (or otherwise makes available to a user) controls for interacting with the camera device, such as controls for requesting a live video stream, interacting with camera-based functions (e.g., recording and playback), and so forth. In some implementations, the application associated with the battery-powered device <NUM> (App6) is associated with a plurality of network-connected devices, and a user interface of the application (e.g., displayed or otherwise made available to a user via UI module <NUM>) provides affordances or other kinds of UI elements for interacting with respective network-connected devices. For example, element C may be associated with the battery-powered device <NUM>, while elements A, B, D, E, and F may be associated with other network-connected devices. Continuing with this example, elements A-C may be associated with devices in one room of a home, element D may be associated with a device in another room of the home, and elements E and F may be associated with devices in yet another room of the home. Upon selection of element C, the application (App6) displays (or otherwise makes available) UI elements for interacting with the battery-powered device <NUM>.

<FIG> are diagrams depicting DTIM beacon skipping scenarios, including various standby modes, in accordance with some implementations. As described above, a battery-powered device <NUM> may conserve battery power by skipping DTIM beacons in order to leave communication circuitry <NUM> disabled for longer periods of time (e.g., in a low-power state or completely powered down). However, while the communication circuitry <NUM> is disabled, the battery-powered device <NUM> cannot receive communications from other network-connected devices, thereby adding latency. As such, there is a tradeoff between the power savings afforded by skipping DTIM beacons and the latency added due to the communication circuitry <NUM> being disabled.

The Wi-Fi operations described in <FIG> are implemented by communication circuitry <NUM> (e.g., a Wi-Fi chip) of the battery-powered device <NUM>. For example, in a low-power mode/power saving Wi-Fi mode <NUM>, the battery-powered device <NUM> may be in a sleep state, during which the communication circuitry <NUM> is powered on to received DTIM beacons and is otherwise disabled to conserve power. Independently of the communication circuitry <NUM>, other components of the battery-powered device <NUM> may be powered off (or in a low-power state) to conserve power. In fact, the communication circuitry <NUM> may perform DTIM beacon checking operations independently of other components of the battery-powered device <NUM> (e.g., processor(s) <NUM> and sensor(s) <NUM>), and as a result, such components may remain powered down even while the communication circuitry <NUM> powers up to check for DTIM beacons. In <FIG>, received DTIM beacons are depicted by solid lines, while skipped DTIM beacons are depicted by dotted lines.

The Wi-Fi operations described in <FIG> may be programmed into the communication circuitry <NUM> (e.g., programmed into the Wi-Fi chip) and executed in response to receipt of a particular standby command or message (<NUM>, <FIG>) sent by an Internet service provided by the server system <NUM> (as described in more detail below). Specifically, the operations that are performed by the communication circuitry <NUM> (e.g., the Wi-Fi chip) include DTIM beacon checking operations, operations that are in response to receipt of a standby command or message (described in more detail below), operations causing the communication circuitry <NUM> to revert to a low-power mode (if no buffered data is available at the access point), and operations causing other components of the battery-powered device <NUM> to transition to a full power state (if buffered data is available at the access point).

<FIG> depicts a scenario <NUM> in which a battery-powered device <NUM> periodically receives DTIM beacons <NUM> (e.g., at times A and D) while skipping other DTIM beacons (e.g., at times B and C) while in a low-power mode <NUM>. Stated another way, communication circuitry <NUM> of the battery-powered device <NUM> wakes up to receive DTIM beacons at regular intervals, i.e., first time intervals. The intervals at which the battery-powered device <NUM> receives DTIM beacons may be an integer multiple of the DTIM beacon period (the period at which an access point emits DTIM beacons). For example, an access point may be configured to emit DTIM beacons every <NUM> milliseconds (the time period between A and B in <FIG>, also referred to as second time interval herein). However, a battery-powered device <NUM>, while in a low-power mode <NUM>, may be configured to receive every third DTIM beacon (receiving DTIM beacons every <NUM> milliseconds, the time period between A and D in <FIG>) while skipping two out of every three DTIM beacons emitted by the access point. The DTIM beacon receiving intervals and skipping rates described in these examples are for illustrative purposes and are not meant to be limiting. For example, communication circuitry <NUM> of a battery-powered device <NUM> may be configured to wake up and receive every second, third, fourth, fifth (and so forth) DTIM beacon emitted by an access point while in a low-power mode. For example, if a battery-powered device <NUM> is configured to receive every fifth DTIM beacon emitted by an access point with a DTIM beacon rate of <NUM> milliseconds, then the battery-powered device <NUM> would receive DTIM beacons once per second.

If the access point receives (and buffers) data addressed to the battery-powered device <NUM> at time <NUM>, the battery-powered device <NUM> does not receive any indications of the availability of that data until the next DTIM beacon is received at time <NUM>. This delay, between (i) the time data is available at the access point for transfer to the battery-powered device <NUM> (time <NUM>), and (ii) the time the battery-powered device <NUM> receives an indication that the buffered data is available (time <NUM>) is referred to as Delay A. Once the battery-powered device <NUM> receives the DTIM beacon indicating availability of data at time <NUM>, the battery-powered device <NUM> fetches the buffered data from the access point and enters a high-power usage mode <NUM>, defined as a state in which components (e.g., processor(s) <NUM>, communication circuitry <NUM>, and sensor(s) <NUM>) of the battery-powered device <NUM> are powered up in order to perform operations. For example, data received by the access point at time <NUM> includes a request by a client device <NUM> to access a live video and/or audio feed from the battery-powered device <NUM> (in this case, a battery-powered camera device). The battery-powered device <NUM> receives this request after time <NUM> (after fetching the buffered data indicated by the DTIM beacon received at time <NUM> as being available). In response to the request, the battery-powered device <NUM> powers on its camera and streaming circuitry (e.g., enters high-power usage mode <NUM>), obtains the requested video and/or audio data, and streams the data to the client device <NUM> via communication network(s) <NUM>.

<FIG> depicts a scenario <NUM> in which a battery-powered device <NUM> periodically receives DTIM beacons <NUM> while skipping other DTIM beacons as described above with reference to the low-power mode <NUM> of scenario <NUM>. However, in scenario <NUM>, the access point receives a standby message/command (<NUM> in <FIG>) addressed to the battery-powered device <NUM> at time <NUM>. Availability of this standby command is signaled to the battery-powered device <NUM> (via the access point) when the battery-powered device <NUM> receives the next DTIM beacon at time <NUM>. In response to receiving the standby command, the battery-powered device <NUM> enters a standby mode <NUM>, during which the battery-powered device <NUM> ceases skipping DTIM beacons (or skips them at a lower frequency). Accordingly, the battery-powered device <NUM> is operated - for a predefined (standby) time interval - in a standby mode in which the battery-powered device <NUM> checks at a third time interval periodic DTIM beacons transmitted by the wireless access point, the third time interval being shorter than the first time interval. As a result, when data addressed to the battery-powered device <NUM> is received at the access point at time <NUM>, availability of this data is signaled to the battery-powered device <NUM> upon receiving the next DTIM beacon at time <NUM>. The delay between (i) the time (the buffered) data is available at the access point for transfer to the battery-powered device <NUM> (time <NUM>), and (ii) the time the battery-powered device <NUM> receives an indication that the data is available (time <NUM>) is referred to as Delay B. Compared to Delay A in scenario <NUM>, Delay B is lower. This lower delay enables the battery-powered device <NUM> to receive messages, and as an extension, to respond to any requests in the received messages, with lower latency. To be clear, time <NUM> in scenario <NUM> is the same as time <NUM> in scenario <NUM>, but a DTIM beacon signaling the availability of buffered data at the access point can be received at an earlier time in scenario <NUM> (time <NUM>) than in scenario <NUM> (time <NUM>) due to the standby mode <NUM> causing the communication circuitry <NUM> of the battery-powered device <NUM> to receive DTIM beacons at an increased frequency.

Continuing the example described with reference to scenario <NUM> above, in which the battery-powered device <NUM> is a camera device, and the message received by the access point includes a request for live video and/or audio data, the battery-powered device <NUM> receives the request at an earlier time <NUM> (vs. <NUM> in scenario <NUM>). As a result, the battery-powered device <NUM> can enter the high-power usage mode <NUM> and provide the requested video and/or audio data to the client device <NUM> with lower latency as compared to scenario <NUM>.

In scenario <NUM>, the access point receives the standby command while the battery-powered device <NUM> is still in a low-power mode <NUM>. As such, there is a delay between (i) the time the standby command is received at the access point (time <NUM>), and (ii) the time the battery-powered device <NUM> receives the standby command (time <NUM>). This delay is referred to as Delay C. As a result of this delay, the earlier the standby command is received at the access point, the more likely the battery-powered device <NUM> will enter the standby mode <NUM> in time for subsequent messages to be signaled to the battery-powered device <NUM> with the lower Delay B (compared to Delay A).

The examples described above refer to the battery-powered device <NUM> as being a camera device, and the message received at the access point at time <NUM> as a request to obtain video and/or audio data. These examples are for illustrative purposes and are not meant to be limiting. For example, any network-connected, battery-powered device <NUM> may implement the low-power mode <NUM> and standby mode <NUM> (as well as standby modes <NUM> and <NUM> described below) upon receipt of a standby command. Specifically, a battery-powered device <NUM> may be in a power-saving sleep state during low-power mode <NUM>, and the message received at time <NUM> may be any command requiring the battery-powered device <NUM> to wake from the sleep state.

<FIG> depict additional scenarios for implementing a standby mode during which DTIM beacons are received at a higher frequency (or in other words, are skipped less frequently). Features shared with <FIG> are similarly numbered, and some are not further discussed for purposes of brevity. In addition, skipped DTIM beacons are no longer depicted in these scenarios in order to shift focus to other aspects of each scenario (nevertheless, DTIM beacons still regularly emanate from the access point as described above).

<FIG> depicts a scenario <NUM> in which a battery-powered device <NUM> periodically receives DTIM beacons <NUM> in a low-power mode <NUM>. The access point receives a standby command at time <NUM> and the battery-powered device <NUM> enters a standby mode <NUM> as described with reference to scenario <NUM> (<FIG>) above. However, in this scenario, a subsequent message is not received at the access point. Therefore, in some implementations, the standby mode <NUM> expires (at time <NUM>) and the battery-powered device <NUM> reverts to the low-power mode <NUM> in order to conserve power. The standby mode <NUM> expires at the end of a timeout period, which may be specified by the standby command itself, or may be predetermined independently of the standby command. Stated another way, the duration of the standby mode may be a predefined value associated with a timeout period of the particular standby mode (e.g., <NUM>, <NUM>, or <NUM> as described in more detail below). The timeout period may be programmed into the communication circuitry <NUM> (e.g., programmed into a Wi-Fi chip of the battery-powered device <NUM>). The timeout period may be a fixed or variable period of time chosen to balance (i) the need for a particular standby mode to be long enough to accommodate subsequent messages that are expected to be received at the access point, with (ii) the need for the particular standby mode to be short enough to not significantly impact battery life of the one or more batteries <NUM> of the battery-powered device <NUM>. The standby mode may last <NUM> seconds. Other durations may be implemented (e.g., any duration as short as <NUM> second (or shorter) or as long as <NUM> seconds (or longer).

<FIG> depicts a scenario <NUM> in which a battery-powered device <NUM> periodically receives DTIM beacons <NUM> in a low-power mode <NUM>. The access point receives a standby command at time <NUM> and the battery-powered device <NUM> enters a standby mode <NUM> comprising two phases. During a first phase, <NUM>-<NUM>, the battery-powered device <NUM> powers on additional components (e.g., wakes up or comes out of a sleep state) such that messages received at the access point may be fetched by the battery-powered device <NUM> without having to wait for a DTIM beacon (without the data being buffered by the access point). For example, the battery-powered device <NUM> may fetch data buffered at the access point and signaled by beacons transmitted between DTIM beacons, which has the potential to reduce latency even more than the reduced latency potential of standby mode <NUM> in scenarios <NUM> and <NUM> (<FIG> and <FIG>). Since the first phase <NUM>-<NUM> of standby mode <NUM> requires additional power consumption (due to, for example, the communication circuitry <NUM> being constantly powered on), this phase may expire before the overall standby mode expires. For example, the first phase <NUM>-<NUM> expires at time <NUM>, and the battery-powered device <NUM> may enter a second phase <NUM>-<NUM> of the standby mode during which DTIM beacons are checked at an increased frequency (corresponding to standby mode <NUM> described above), yet the communication circuitry <NUM> may be powered down between DTIM beacons, thereby providing reduced delays (Delay B as described above) while not causing power to be drained at a level required by keeping the communication circuitry <NUM> powered on during the first phase <NUM>-<NUM> of standby mode <NUM>. The second phase <NUM>-<NUM> ends at the expiration of the timeout period at time <NUM>. The first phase <NUM>-<NUM> may last for the first <NUM> seconds of a <NUM> second standby mode, and the second phase <NUM>-<NUM> may last for the final <NUM> seconds of a <NUM> second standby mode. Other durations may be implemented (e.g., a first duration <NUM>-<NUM> lasting as short as <NUM> second (or shorter) or as long as <NUM> seconds (or longer), and/or a second duration <NUM>-<NUM> lasting as short as <NUM> second (or shorter) or as long as <NUM> seconds (or longer)).

<FIG> depicts a scenario <NUM> in which a battery-powered device <NUM> periodically receives DTIM beacons <NUM> in a low-power mode <NUM>. The access point receives a standby command at time <NUM> and the battery-powered device <NUM> enters a standby mode <NUM>, during which the battery-powered device <NUM> operates as described with reference to the first phase <NUM>-<NUM> of the standby mode <NUM> described above until the expiration of the timeout period at time <NUM>. Compared to the other standby modes described above, standby mode <NUM> causes the highest power consumption but results in the lowest latencies.

For each of the scenario described in <FIG>, if a subsequent message addressed to the battery-powered device <NUM> is received at the access point during the standby mode, the battery-powered device <NUM> enters a high-power usage state <NUM>, as described with reference to scenarios <NUM> and <NUM> (<FIG>), in order to process any commands included in the message.

Even though the standby modes (<NUM>, <NUM>, <NUM>) described above may cause communication circuitry <NUM> of the battery-powered device <NUM> to be powered on more frequently, the standby modes do not necessarily require the battery-powered device <NUM> to power on other non-communication components (such as image processing components for a camera device). Therefore, even when a battery-powered device <NUM> is in a standby mode, the battery-powered device <NUM> may still conserve power by remaining in a power-saving mode (a sleep state), even if communication circuitry <NUM> periodically awakes to receive DTIM beacons.

As described above with reference to Delay C (<FIG>), the earlier the standby command is received at the access point, the more likely the battery-powered device <NUM> will enter the standby mode (<NUM>, <NUM>, or <NUM>) in time to receive a DTIM beacon signaling a subsequent message with reduced delay (Delay B). In some implementations, the standby command is triggered by a preliminary user interaction with a client device <NUM>.

Referring to <FIG>, for example, a user may open an application (App6) associated with the battery-powered device <NUM> (and, optionally, associated with other battery-powered devices connected to the network). While selecting affordance <NUM>-f causes the application to open (or otherwise display UI options or make UI options available for facilitating interactions between the user and the application), the application may not yet be in a state that allows the user to directly interact with the battery-powered device <NUM>. Even so, it can be inferred that since the user opened the application App6, there is a likelihood that the user may subsequently wish to interact with the battery-powered device <NUM> (e.g., by selecting affordance C). As such, the opening of the application triggers a hint message <NUM> to be sent form the client device <NUM> to the server system <NUM>. The hint message can be sent by the application (App6) or by system software of the client device <NUM>. Alternatively, the server system <NUM> can detect the opening of the app and send the standby command without receiving a hint message before.

In response to receiving the hint message, the server system <NUM> sends the standby command <NUM> to the battery-powered device <NUM> (and, optionally, to other devices connected to the same network as well). When the user proceeds to interact with the device (e.g., by selecting affordance C in a UI of the application), the client device <NUM> transmits a request message <NUM> to the server system <NUM>, which causes a corresponding request message <NUM>, to be transmitted to the battery-powered device <NUM>. In response to the request message <NUM> being received by the battery-powered device <NUM> (after having been signaled by a DTIM beacon and fetched by the battery-powered device <NUM>), the battery-powered device <NUM> may respond by transmitting requested data <NUM> to the server system <NUM>, which forwards the data <NUM> corresponding to the requested data <NUM>, to the client device <NUM>. The standby command <NUM> in this example corresponds to the standby command received at time <NUM> in <FIG>, the request <NUM> corresponds to the subsequent message received at the access point at time <NUM> in <FIG>, and the data <NUM> corresponds to data transmitted by the battery-powered device <NUM> while in the high-power usage mode <NUM> in <FIG>. The request <NUM>/<NUM> may be a message requesting video and/or audio data (e.g., a live video stream), and the data <NUM>/<NUM> may include the requested data (e.g., the requested live video stream).

In the example described above with reference to <FIG>, the hint message <NUM> is triggered when a user opens an application that includes options for interacting with the battery-powered device <NUM>. This example is for illustrative purposes and is not meant to be limiting. In general, the hint message <NUM> may be triggered by any user interaction with the client device <NUM> that implies subsequent interactions with the client device <NUM> may cause the client device <NUM> to request that the battery-powered device <NUM> perform an operation requiring the battery-powered device <NUM> to come out of a power-saving mode (e.g., to wake from a sleep mode). Stated another way, the hint message <NUM> may be triggered by a user interaction that is an intermediate step in requesting data from the battery-powered device <NUM> (e.g., video and/or audio data), the intermediate step not including the actual request for the data. The detected user interaction (the intermediate step) is an indication that a user command for interacting with the battery-powered device <NUM> is imminent (likely to happen within a relatively small amount of time; e.g., <NUM> seconds). Example hint triggers include opening the application App6 (by selecting affordance <NUM>-f), unlocking or turning on the client device <NUM> in response to a notification associated with the battery-powered device <NUM>, or performing any other interactions involving the application App6 that do not necessarily cause data (messages or commands) to be sent to the battery-powered device <NUM> but are usually precursors to such data being transmitted.

In some implementations, the hint message <NUM> may be triggered by network-connected devices other than the client device <NUM>. For example, if the battery-powered device <NUM> is a security camera, the hint message <NUM> may be triggered by a network-connected security device detecting a security event (e.g., unauthorized motion or access to a restricted area). In such cases, the security event triggers the hint message <NUM>, which causes the battery-powered device <NUM> (the security camera) to enter a standby mode, so that subsequent requests for live video from the battery-powered device <NUM> may be received with reduced latency. As another example, the hint message <NUM> may be triggered by a network-connected hazard detection device, such as a smoke detector, detecting a hazard event (e.g., smoke or another hazardous substance above a threshold). In such cases, the hazard event triggers the hint message <NUM>, which causes the battery-powered device <NUM> to enter a standby mode, so that subsequent requests for live video from the battery-powered device <NUM> may be received with reduced latency. In general, the hint message <NUM> may be triggered by any network-connected device upon an event is likely to cause a client device <NUM> to request that the battery-powered device <NUM> perform an operation requiring the battery-powered device <NUM> to come out of a power-saving mode (e.g., to wake from a sleep mode).

<FIG> is a flow diagram illustrating an example process <NUM> for adaptively adjusting the rate at which DTIM beacons are skipped in accordance with some implementations. The process <NUM> is, optionally, governed by instructions that are stored in a computer memory or non-transitory computer readable storage medium of each of a client device <NUM>, server system <NUM>, and battery-powered device <NUM>, and that are executed by one or more processors of the client device <NUM>, server system <NUM>, and battery-powered device <NUM>. Each respective computer readable storage medium may include a magnetic or optical disk storage device, solid state storage devices such as Flash memory, or other non-volatile memory device or devices. The respective instructions stored on each computer readable storage medium may include one or more of: source code, assembly language code, object code, or other instruction format that is interpreted by one or more processors. Some operations in process <NUM> may be combined, skipped, and/or the order of some operations may be changed.

A client device <NUM> detects (<NUM>) a user input indicating subsequent interaction with a battery-powered device <NUM> is likely (e.g., a user opens or otherwise interacts with an application as described above with reference to App6 in <FIG>). As a result of the detected user input, the client device <NUM> transmits (<NUM>) a message (e.g., hint message <NUM>, <FIG>) that indicates one or more interactions with the battery-powered device <NUM> are likely. The server system <NUM> receives (<NUM>) the message and transmits a standby command to the battery-powered device <NUM> via an access point (as described above with reference to <FIG> and <FIG>). The battery-powered device <NUM> receives (<NUM>) the standby command (upon fetching the message from the access point in response to a DTIM beacon being received), and either increases the rate at which it checks DTIM beacons (as described above with reference to standby modes <NUM> and <NUM>-<NUM> in <FIG>), or enters a temporary high-power communication mode (as described above with reference to standby modes <NUM>-<NUM> and <NUM> in <FIG>). Regardless of the action taken at operation <NUM> (regardless of the standby mode timing parameters), other components of the battery-powered device <NUM> may remain in a low-power state (in a sleep mode). Subsequent to the user input detected at operation <NUM>, the client device <NUM> receives (<NUM>) a user request requiring the client device <NUM> to interact with the battery-powered device <NUM> (e.g., a request for video and/or audio data), as described above with reference to request <NUM>/<NUM> in <FIG>. The client device <NUM> transmits (<NUM>) the user request to the server system <NUM>, which forwards (<NUM>) the user request to the battery-powered device <NUM>. The battery-powered device <NUM> receives.

(<NUM>) the user request (while in the standby mode) upon receiving the next DTIM beacon (as described above with reference to <FIG>), and enters (<NUM>) a high-power usage state in order to act on the user request, which may involve transmitting requested data (e.g., data <NUM>, <FIG>) to the client device <NUM> via the server system <NUM>. The server system <NUM> receives (<NUM>) the requested data and forwards it to the client device <NUM>. The client device <NUM> receives (<NUM>) the data and optionally causes the data to be displayed (e.g., displays a live video stream provided by the battery-powered device <NUM>).

The terminology used in the description of the various described implementations herein is for the purpose of describing particular implementations only and is not intended to be limiting. As used in the description of the various described implementations and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Additionally, it will be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms.

It is to be appreciated that "smart home environments" may refer to smart environments for homes such as a single-family house, but the scope of the present teachings is not so limited. The present teachings are also applicable, without limitation, to duplexes, townhomes, multi-unit apartment buildings, hotels, retail stores, office buildings, industrial buildings, and more generally any living space or workspace.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the claims to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain principles of operation and practical applications, to thereby enable others skilled in the art.

Although various drawings illustrate a number of logical stages in a particular order, stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art, so the ordering and groupings presented herein are not an exhaustive list of alternatives. Moreover, it should be recognized that the stages can be implemented in hardware, firmware, software, or any combination thereof.

Claim 1:
A method, comprising:
operating a first device (<NUM>) having at least one Wi-Fi transceiver in a power saving Wi-Fi mode in which the first device (<NUM>) repeatedly checks, at a first time interval, periodic delivery traffic indication message, DTIM, beacons (<NUM>) transmitted at a second time interval by a wireless access point (<NUM>) of a Wi-Fi network, the first time interval being longer than the second time interval;
receiving at the first device (<NUM>), during the power saving Wi-Fi mode, a standby message (<NUM>);
in response to receiving the standby message (<NUM>) operating the first device (<NUM>), during a first predefined time interval, in a standby mode in which the first device (<NUM>) checks at a third time interval periodic DTIM beacons (<NUM>) transmitted by the wireless access point (<NUM>), the third time interval being shorter than the first time interval;
when the first device (<NUM>) is operating in the standby mode and when the DTIM beacon includes an identifier of the first device (<NUM>), downloading by the first device (<NUM>) and from an access point (<NUM>) of the Wi-Fi network, buffered information, buffered at the access point (<NUM>), and directed to the first device (<NUM>); and
exiting the standby mode and operating the first device (<NUM>) in a non-power saving mode, for directly receiving information directed to the first device (<NUM>) from an access point of the Wi-Fi network, without the information being buffered at the access point.