Patent Description:
Additionally, some wireless mesh network devices may sleep periodically to reduce power consumption and are not in constant radio contact with the mesh network to receive data packets. Sleeping mesh network devices may periodically wake-up and poll a parent mesh network device to determine if data is queued for delivery to the sleeping mesh network device. As the density of wireless mesh network devices in an area increases, increasing polling traffic can cause network congestion and increase communication latency.

For a battery-powered, sleeping mesh network device, relying on polling to check for pending data requires the use of limited battery power to transmit polling requests, even if there is no pending data for the sleeping mesh network device. When an application in the sleeping end device requires low communication latency, battery power is consumed at a greater rate by transmitting polling messages more frequently.

<CIT> relates to controlled synchronizing of sensor devices in a wireless sensor network based on received drift information. <CIT> relates to clock synchronization and centralized guard time provisioning. <CIT> relates to wireless sensor time synchronization. <CIT> relates to managing synchronization between a first network and a second network.

This summary is provided to introduce simplified concepts of synchronized reception in mesh networks, generally related to synchronizing reception of data from a parent device by an end device in a wireless mesh network. The simplified concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

In aspects, methods, devices, systems, and means for synchronized reception in mesh networks according to the appended claims are provided.

The details of one or more implementations are set forth in the accompanying drawings and the following description. This summary is provided to introduce subject matter that is further described in the Detailed Description and Drawings. Accordingly, this summary should not be considered to describe essential features nor used to limit the scope of the claimed subject matter.

A method of synchronizing reception of communications by an end device that operates in a receiver-off-when-idle mode in a wireless mesh network according to claim <NUM> is provided.

A mesh network device configured as an end device according to independent claim <NUM> is also provided.

A mesh network system according to independent claim <NUM> is also provided. Further aspects are provided by the dependent claims.

Aspects of synchronized reception in mesh networks are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:.

This document describes techniques and devices to synchronize communications between devices in a wireless mesh network. Based on the requirements of an end device that sleeps (e.g., is out of communication with the wireless mesh network) for periods of time, the end device indicates to a parent wireless mesh network device that the end device wants to configure operations in a synchronized-reception mode, which causes the parent device to reply with an indication of the clock accuracy of the parent device. The end device uses the clock accuracy of the parent device to determine parameters for synchronized-reception and transmits the parameters to the parent device. The end device activates its receiver based on the parameters to receive data from the parent device.

Wireless mesh networks are communication networks having wireless nodes connected in a mesh topology that provides reliable and redundant communication paths for data traffic within the mesh network. Wireless mesh networks use multiple radio links, or hops, to forward data traffic between devices within the mesh network. This provides coverage for areas larger than the area covered by a single radio link.

Wireless mesh networks can be based on proprietary technologies, or standards-based technologies. For example, wireless mesh networks may be based on the IEEE <NUM>. <NUM> standard, which defines physical (PHY) layer and Media Access Control (MAC) layer features and services for use by applications at higher layers of a mesh networking stack. Upper-layer applications rely on these standards-defined services to support addressing and routing of packet data to support application-level communication across a mesh network and between the mesh network and external networks. Similarly, other wireless mesh network technologies, such as Bluetooth®, Thread®, ZigBee®, Z-Wave®, Bluetooth® Low Energy (BLE), Bluetooth Smart, and Bluetooth Mesh have similar layered networking stacks.

Applications at a cloud-based service transmit packets to and receive packets from mesh network devices. These packets traverse a number of networks that use varying technologies. To facilitate low power operation, the mesh network uses low-power radio techniques that may use low data rates to conserve energy. Further, the network connection from a mesh network to the cloud-based service may include cellular wireless systems with bandwidth and cost constraints for transmitting data.

Many devices for mesh networks, such as sensors, are designed for low-power, battery operation over long periods of time, such as months or years. To achieve long service life, a battery-powered mesh device may turn off, or sleep, many of the device functions, such as radio and network interfaces, for periods of time. During sleep periods, the mesh device is not available on the mesh network to receive packets addressed to it. These sleeping mesh devices connect to a parent device that is capable of responding on behalf of the sleeping mesh device when it is not awake and active on the mesh network. The parent device buffers packets destined for the child device and responds, on behalf of the child device.

In aspects, the cloud-based service and various mesh network devices may participate in distributed applications or use cases. The requirements of each use case may require differing levels of communication latency or availability on the mesh network or between the cloud-based service and the mesh network devices. For example, the cloud-based service and/or a mesh network device may determine a mode or state for a smart-home or building automation application related to a structure where the mesh network devices are installed. Example modes or states may include an occupancy state of the structure, an alarm state within the structure, a user interaction related to the structure or a mesh network device within the structure, an environmental condition at the structure, a schedule related to the structure, or the like.

In response to a condition in an end device, such as a sensor reading crossing a threshold, an interaction with the end device, or the like, or during certain states or modes, an end device may determine to operate in a synchronized-reception mode with a parent device to reduce communication latency, reduce power consumption, and/or improve network utilization. The end device may determine to operate in the synchronized-reception mode for a period of time or while a certain state or mode exists and then return to polling for data (e.g., indirect transmission) after the period of time expires.

While features and concepts of the described devices, systems, and methods for synchronized reception in mesh networks can be implemented in any number of different environments, systems, devices, and/or various configurations, aspects of synchronized reception in mesh networks are described in the context of the following example devices, systems, and configurations.

<FIG> illustrates an example system as a mesh network <NUM> in which various aspects of synchronized reception in mesh networks can be implemented. The mesh network <NUM> is a wireless mesh network that includes routers <NUM>, a router-eligible end device <NUM>, and end devices <NUM>. The routers <NUM>, the router-eligible end device <NUM>, and the end devices <NUM>, each include a mesh network interface for communication over the mesh network. The routers <NUM> receive and transmit packet data over the respective mesh network interfaces. The routers <NUM> also route traffic across the mesh network <NUM>.

The router-eligible end device <NUM> is representative of router-eligible end devices that are located at leaf nodes of the mesh network topology and are not actively routing traffic to other nodes in the mesh network <NUM>. The router-eligible device <NUM> is capable of becoming a router <NUM> when the router-eligible device <NUM> is connected to additional mesh network devices. The end devices <NUM> are devices that can communicate using the mesh network <NUM>, but lack the capability, beyond simply forwarding packets to its parent router <NUM>, to route traffic in the mesh network <NUM>. For example, a battery-powered sensor is one type of end device <NUM>.

Some end devices <NUM> may power down (i.e., sleep) some operations or hardware for a portion of the time the end device <NUM> is operational. For example, the end device <NUM> may power down radios or network interfaces, to conserve power between operations that require a connection to the mesh network <NUM>. For example, a battery-powered temperature sensor may only be awake periodically to transmit a report of temperature, and then the temperature sensor sleeps until the next time the temperature sensor reports. When the end devices <NUM> sleep, the end devices <NUM> are not actively connected to the mesh network <NUM> to respond to address queries or to receive data packets over the mesh network <NUM>.

<FIG> illustrates an example environment <NUM> in which various aspects and techniques of synchronized reception in mesh networks can be implemented. The environment <NUM> includes the mesh network <NUM>, in which some routers <NUM> are performing specific roles in the mesh network <NUM>.

A border router <NUM> (also known as a gateway and/or an edge router) is one of the routers <NUM>. The border router <NUM> includes the mesh network interface, as well as a second interface for communication with an external network, outside the mesh network <NUM>. The border router <NUM> connects to an access point <NUM> over the external network. For example, the access point <NUM> may be an Ethernet router, a Wi-Fi access point, a cellular base station, or any other suitable device for bridging different types of networks. Although a single border router <NUM> is shown in <FIG>, for the sake of clarity, the mesh network <NUM> may have any number of border routers <NUM>, which may connect to any number of external networks. In another implementation, an end device <NUM> may operate as a border router <NUM>. In this case the end device operating as the border router <NUM> is routing traffic between the mesh network <NUM> and an external network, but not routing traffic between other mesh network devices.

The access point <NUM> connects to a communication network <NUM>, such as the Internet. A cloud service <NUM>, which is connected via the communication network <NUM>, provides services related to and/or using the devices within the mesh network <NUM>. By way of example, and not limitation, the cloud service <NUM> provides applications that include connecting end user devices, such as smart phones, tablets, and the like, to devices in the mesh network <NUM>, processing and presenting data acquired in the mesh network <NUM> to end users, linking devices in one or more mesh networks <NUM> to user accounts of the cloud service <NUM>, provisioning and updating devices in the mesh network <NUM>, and so forth. Alternatively or optionally, services described in relation to the cloud service <NUM> may be distributed completely or partially between the cloud service <NUM> and a hub device (e.g., the border router <NUM>, a security hub, or the like) that is installed at the structure where the mesh network devices are installed. The storage location of traits, resources, and interfaces of mesh network devices or structure-related information may be dynamically distributed in any suitable fashion between the cloud service <NUM> and the hub device.

One of the routers <NUM> performs the role of a leader <NUM> for the mesh network <NUM>. The leader <NUM> manages router identifier assignment, is the central arbiter of network configuration information, and propagates network data, which includes the network configuration information, for the mesh network <NUM>.

As discussed in detail below, an end device decides to, or is configured to, operate in a synchronized-reception mode, which may be established when the end device attaches to a parent device, or at a later point in time. <FIG> illustrates an example of transmitter and receiver synchronization <NUM> between a parent device <NUM> (e.g., a router <NUM> or router-eligible end device <NUM>) and an end device <NUM> (e.g., end device <NUM>). As discussed in detail with respect to <FIG> below, the end device <NUM> establishes a schedule for synchronized reception that is transmitted to the parent device <NUM>, for example using IEEE <NUM>. <NUM> Coordinated Sampled Listening (CSL). The end device <NUM> periodically activates its receiver, shown at <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, at a time interval <NUM> and for a receive window <NUM>.

When the parent device <NUM> has data to transmit to the end device <NUM>, the parent transmits the data as shown at <NUM> and <NUM>. The end device <NUM> activates its receiver for the receive window <NUM>, which is selected to be longer than a transmit time <NUM> of expected or maximum data packet lengths in the wireless mesh network <NUM>. As illustrated at <NUM>, by activating the receiver of the end device <NUM> for a window that is longer than the transmit expected transmit time <NUM>, the clocks of the parent device <NUM> and end device <NUM> may each drift and communications will be successful in spite of the clock drifts.

<FIG> illustrates another example of transmitter and receiver synchronization <NUM> generally related to clock drift over time for wireless communications between the parent device <NUM> and the end device <NUM>. Initially after establishing synchronized reception between the parent device <NUM> and the end device <NUM>, a transmission from the parent device <NUM> is centered within the receive window <NUM> as shown at <NUM>. After a period of time, the clocks of the parent device <NUM> and the end device <NUM> may drift apart. As shown at <NUM>, the transmission from the parent device <NUM> is no longer centered in the receive window <NUM>. At <NUM> the parent device <NUM> transmission is illustrated as occurring earlier in the receive window <NUM>, such as when the clock of the parent device is faster (drifts higher in frequency) relative to the clock of the end device <NUM>. Alternatively, the parent device <NUM> transmission may occur later in the receive window <NUM>, when the clock of the parent device is slower (drifts lower in frequency) relative to the clock of the end device <NUM>.

At <NUM>, the clocks of the clocks of the parent device <NUM> and the end device <NUM> may drift far enough apart that part or all of the transmission from the parent device <NUM> falls outside the receive window <NUM>. At this point, the end device <NUM> can no longer receive transmissions from the parent device in the synchronized reception mode. To continue using synchronized reception, the parent device <NUM> and end device <NUM> need to resynchronize or the end device <NUM> can fall back to indirect transmission by polling the parent device <NUM> for queued data stored by the parent device <NUM>.

illustrates example data and control transactions between the parent device <NUM> and the end device <NUM> engaged in communication in accordance with various aspects of synchronized reception in mesh networks. At <NUM> the end device <NUM> transmits a Mesh Link Establishment (MLE) Parent Request message using multicast addressing to devices in the mesh network <NUM> including the parent device <NUM>. The MLE Parent Request message includes an indication that the end device <NUM> is configured to operate in a receiver-off-when-idle (e.g., rx-off-when-idle) mode and/or the synchronized-reception mode. The indication may be a bit in the value of a Mode Type-Length-Value (TLV) that is set to indicate Wake-on-Radio operation, a bit in the value of the Mode Type-Length-Value (TLV) that is set to indicate the end device <NUM> operates in the rx-off-when-idle mode, or the like.

At <NUM> the parent device <NUM> responds to the Parent Request message with an MLE Parent Response message that includes a CSL Accuracy TLV. The CSL Accuracy TLV includes an indication of the clock accuracy of the parent device <NUM>. For example, the CSL Accuracy TLV includes a <NUM>-bit, CslAccuracy value in units of parts-per-million (ppm) of the clock used by the parent device <NUM> for synchronized reception timings.

At <NUM> the end device <NUM>, uses the received CslAccuracy value to determine parameters for communication using synchronized reception with the parent device <NUM>. The parameters include a CSL Synchronized Timeout value. For example, the end device <NUM> uses the CslAccuracy value, and other information such as the clock accuracy of the end device <NUM>, the maximum length of a Media Access (MAC) layer protocol data unit (PDU), or the like to determine the CSL Synchronized Timeout value that indicates when the parent device <NUM> transmitter and end device <NUM> receiver will be considered to be no longer synchronized. The CSL Synchronized Timeout value may be a <NUM>-bit unsigned integer value in units of seconds.

At <NUM> the end device <NUM> sends an MLE Child ID Request to the parent device <NUM> that includes parameters for establishing the parent-child relationship with the parent device <NUM>. The MLE Child ID request may include a CSL Channel TLV indicating one or more channels for CSL communications, and/or the CSL Synchronized Timeout TLV, to establish synchronized reception at <NUM>. Alternatively, if including the CSL Channel TLV and/or the CSL Synchronized Timeout TLV causes the MLE Child ID Request to exceed the maximum size of the MAC PDU (MPDU), the end device <NUM> includes the CSL Channel TLV and/or the CSL Synchronized Timeout TLV in an MLE Child Update Request message, to the parent device <NUM>, to establish synchronized reception.

Additionally or optionally, the end device <NUM> may still use indirect transmission (polling the parent device <NUM>) while synchronized reception is established. When receiving a data packet from the parent device <NUM> that includes an indication that additional data packets for the end device <NUM> are queued on the parent device <NUM>, the end device <NUM> may use indirect transmission to retrieve the queued data packets. In another aspect, the end device <NUM> may indicate to the parent device <NUM> that the end device <NUM> will leave its receiver on when there is queued data so that the parent device <NUM> will continue to transmit the queued data after a successful reception of a data packet by the end device <NUM>.

Alternatively, the end device <NUM> may establish a parent-child relationship without configuring synchronized reception with the parent device <NUM>. At a later time, the end device <NUM> sends the MLE Child Update Request to the parent device <NUM> that includes the CSL Channel TLV indicating channels for CSL communications, and/or the CSL Synchronized Timeout TLV, to establish synchronized reception at <NUM>.

The parent device <NUM> and the end device <NUM> may communicate using synchronized reception, as described in <FIG>, after synchronization is established and until the CSL Synchronized Timeout expires indicating that the synchronization error is above a threshold for successful operation of synchronized reception or that the synchronization error is unknown. The parent device <NUM> and the end device <NUM> determine if the CSL Timeout has expired, at <NUM> and <NUM> respectively. When the parent device <NUM> determines that the CSL Timeout has expired, the parent device <NUM> suspends CSL Transmissions at <NUM>.

When the end device <NUM> determines that the CSL Timeout has expired, the end device <NUM> determines, at <NUM>, whether to revert to indirect transmission (polling the parent device <NUM> for queued data packets addressed to the end device <NUM>) to receive data at <NUM> or to resynchronize with the parent device <NUM>. For example, an application in the end device <NUM> may determine that synchronized reception should be reestablished, or not, based on an application state, a sensor reading, or the like, as discussed below.

To reestablish synchronized reception, the end device <NUM> includes CSL Information Elements (IEs) in a resynchronization message to the parent device <NUM> at <NUM> which reestablishes synchronized reception at <NUM>. For example, the end device <NUM> includes the CSL IEs in a mesh-link-reestablishment message or data packet to the parent device <NUM> to resynchronize synchronized reception. Including the CSL IEs in a message to the parent device <NUM> resets the CSL Timeout in the parent device <NUM> and the end device <NUM>. Although <FIG> illustrates resynchronization after the CSL Timeout expires, the end device <NUM> may send the CSL IEs at any time while synchronized reception is established which will resynchronize the parent device <NUM> and the end device <NUM> for continued operation using synchronized reception.

In aspects, one or more cloud-based services and various mesh network devices may participate in distributed applications or use cases. The requirements of each use case may require differing levels of communication latency or availability between mesh network devices or between the cloud-based service and the mesh network devices. The applications and use cases below are presented by way of example and not limitation.

A cloud-based service and/or a mesh network device may determine a mode or state related to a smart-home or building automation application for a structure where the mesh network devices are installed. For example, an occupancy state for the structure may indicate that the structure is occupied or that the structure is unoccupied when the occupants are away. When the structure is occupied or transitioning from unoccupied to occupied, it may be desirable for various mesh network devices, such as a thermostat and temperature sensors, to operate using synchronized-reception to provide lower communication latencies and faster response times for closed-loop HVAC control.

Mesh network devices may transition to synchronized reception based on an alarm condition. For example, a mesh network end device may receive an indication of an alarm condition from another mesh network device, may receive an indication of an alarm condition forwarded by another mesh network device, or the mesh network end device itself may determine that an alarm condition exists, such as a sensor reading in the mesh network end device exceeding a threshold value. In response to the alarm condition, the end device may establish (or reestablish) synchronized reception to operate with a lower communication latency to be more responsive while the alarm condition exists. The end device may establish (or reestablish) synchronized reception to suspend polling for data while the alarm condition exists with the effect of reducing potential interference and/or increasing network availability and capacity for other mesh network devices and services communicating in response to the alarm.

Mesh network devices may transition to synchronized reception to increase data reception throughput. For example, a mesh network end device may establish (or reestablish) synchronized reception to increase network throughput for a larger than normal data download, such as receiving a software update. By using synchronized reception, the end device can increase throughput while using less power than would be consumed if the end device used polling to retrieve the software update from a parent device. In a further example, the mesh network end device may periodically check-in with the cloud-based service for queued data packets. The mesh network end device may establish (or reestablish) synchronized reception to increase network throughput to download the queued data packets.

Mesh network devices may transition to synchronized reception based on a schedule. Schedules may be used for states or modes related to a smart-home or building automation applications for the structure where the mesh network devices are installed. A mesh network end device may establish (or reestablish) synchronized reception based on a schedule for a mode or state. For example, an occupancy state for the structure, such as an office building, may be used to indicate periods of occupancy (e.g., normal business hours). During periods of occupancy, end devices may operate using synchronized reception for lower communication latencies to be more responsive to inputs from users occupying the offices.

Mesh network devices may use synchronized reception to increase mesh network capacity. A large number of mesh network devices may be deployed in a commercial building automation system or a homeowner may increase the size of a smart-home network over time. As the scale of the mesh network increases, network traffic may increase interference and collisions that may in turn affect the responsiveness a user experiences when interacting with mesh network devices and applications. For example, based on an assessment of channel conditions, network statistics, a number of devices in the mesh network, a configuration parameter, or the like, an end device may establish (or reestablish) synchronized reception to reduce polling and acknowledgement transmissions on the operating channel of the mesh network to increase overall mesh network capacity and availability.

Mesh network devices may have different communication latency requirements based on an environment state. For example, a solar-powered device, such as a solar-powered sunshade, may establish (or reestablish) synchronized reception to provide low-latency operation during sunny or hot environmental conditions when the sunshade may be able to draw power from solar energy. When the environmental condition changes, such as night time, the sunshade may operate using indirect transmission with a longer communication latency when the need to quickly respond to user interactions in not required.

A mesh network device may transition to synchronized reception based on an interaction with the mesh network device or another mesh network device. For example, a mesh network device may receive an interaction, such as button press by a user, detecting motion or proximity, sensing a contact closure, or the like. In response to the interaction, the mesh network device may establish (or reestablish) synchronized reception to improve response time to commands that may be received in response to the interaction. In another example, another device such as a camera may capture an image or video of an interaction and based on the captured image, video or subsequent facial or image recognition applied to the captured image or video, the mesh network devices may establish (or reestablish) synchronized reception to improve responsiveness to commands resulting from the interaction or subsequent interactions or commands.

Example method <NUM> is described with reference to <FIG> in accordance with one or more aspects of synchronized reception in mesh networks. Generally, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods may be described in the general context of executable instructions stored on computer-readable storage memory that is local and/or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

<FIG> illustrates example method(s) <NUM> of synchronized reception in mesh networks as generally related to establishing synchronized reception between a parent device and an end device in a mesh network. The order in which the method blocks are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order or skipped to implement a method, or an alternate method.

At block <NUM>, an end device (e.g., end device <NUM>) transmits a parent request message (e.g., an MLE Parent Request message) to a parent device (e.g., the parent device <NUM>).

At block <NUM>, in response to the parent request message, the end device receives, from the parent device, a parent response (e.g., an MLE Parent Response message) including an indication of a clock accuracy (e.g., a CSL accuracy TLV) of the parent device.

At block <NUM>, the end device determines, based in part on the received indication of the clock accuracy of the parent device, parameters for synchronized reception of communications from the parent device.

At block <NUM>, the end device transmits, a child request message (e.g., an MLE Child ID Request message or an MLE Child Update Request message) including the parameters (e.g., the CSL Channel TLV, and/or the CSL Synchronized Timeout TLV) for synchronized reception of communications from the parent device, which causes the parent device to transmit communications to the end device based on the parameters.

At block <NUM>, the end device determines whether a timer indicates that the CSL Synchronized Timeout has expired. If the CSL Synchronized Timeout has expired the end device determines, at block <NUM>, whether to resynchronize the reception of communications with the parent device. If the end device determines to resynchronize the reception of communications with the parent device, the end device transmits a resynchronization message to the parent device at <NUM>, otherwise the end device reverts to indirect transmission to receive queued data packets from the parent device at <NUM>.

<FIG> illustrates an example environment <NUM> in which the mesh network <NUM> (as described with reference to <FIG>), and aspects of synchronized reception in mesh networks can be implemented. Generally, the environment <NUM> includes the mesh network <NUM> implemented as part of a smart-home or other type of structure with any number of mesh network devices that are configured for communication in a mesh network. For example, the mesh network devices can include a thermostat <NUM>, hazard detectors <NUM> (e.g., for smoke and/or carbon monoxide), cameras <NUM> (e.g., indoor and outdoor), lighting units <NUM> (e.g., indoor and outdoor), and any other types of mesh network devices <NUM> that are implemented inside and/or outside of a structure <NUM> (e.g., in a smart-home environment). In this example, the mesh network devices can also include any of the previously described devices, such as a border router <NUM>, as well as any of the devices implemented as a router device <NUM>, and/or as an end device <NUM>.

In the environment <NUM>, any number of the mesh network devices can be implemented for wireless interconnection to wirelessly communicate and interact with each other. The mesh network devices are modular, intelligent, multi-sensing, network-connected devices that can integrate seamlessly with each other and/or with a central server or a cloud-computing system to provide any of a variety of useful smart-home objectives and implementations. An example of a mesh network device that can be implemented as any of the devices described herein is shown and described with reference to <FIG>.

In implementations, the thermostat <NUM> may include a Nest® Learning Thermostat that detects ambient climate characteristics (e.g., temperature and/or humidity) and controls a HVAC system <NUM> in the smart-home environment. The learning thermostat <NUM> and other smart devices "learn" by capturing occupant settings to the devices. For example, the thermostat learns preferred temperature set-points for mornings and evenings, and when the occupants of the structure are asleep or awake, as well as when the occupants are typically away or at home.

A hazard detector <NUM> can be implemented to detect the presence of a hazardous substance or a substance indicative of a hazardous substance (e.g., smoke, fire, or carbon monoxide). In examples of wireless interconnection, a hazard detector <NUM> may detect the presence of smoke, indicating a fire in the structure, in which case the hazard detector that first detects the smoke can broadcast a low-power wake-up signal to all of the connected mesh network devices. The other hazard detectors <NUM> can then receive the broadcast wake-up signal and initiate a high-power state for hazard detection and to receive wireless communications of alert messages. Further, the lighting units <NUM> can receive the broadcast wake-up signal and activate in the region of the detected hazard to illuminate and identify the problem area. In another example, the lighting units <NUM> may activate in one illumination color to indicate a problem area or region in the structure, such as for a detected fire or break-in, and activate in a different illumination color to indicate safe regions and/or escape routes out of the structure.

In various configurations, the mesh network devices <NUM> can include an entryway interface device <NUM> that functions in coordination with a network-connected door lock system <NUM>, and that detects and responds to a person's approach to or departure from a location, such as an outer door of the structure <NUM>. The entryway interface device <NUM> can interact with the other mesh network devices based on whether someone has approached or entered the smart-home environment. An entryway interface device <NUM> can control doorbell functionality, announce the approach or departure of a person via audio or visual means, and control settings on a security system, such as to activate or deactivate the security system when occupants come and go. The mesh network devices <NUM> can also include other sensors and detectors, such as to detect ambient lighting conditions, detect room-occupancy states (e.g., with an occupancy sensor <NUM>), and control a power and/or dim state of one or more lights. In some instances, the sensors and/or detectors may also control a power state or speed of a fan, such as a ceiling fan <NUM>. Further, the sensors and/or detectors may detect occupancy in a room or enclosure and control the supply of power to electrical outlets or devices <NUM>, such as if a room or the structure is unoccupied.

The mesh network devices <NUM> may also include connected appliances and/or controlled systems <NUM>, such as refrigerators, stoves and ovens, washers, dryers, air conditioners, pool heaters <NUM>, irrigation systems <NUM>, security systems <NUM>, and so forth, as well as other electronic and computing devices, such as televisions, entertainment systems, computers, intercom systems, garage-door openers <NUM>, ceiling fans <NUM>, control panels <NUM>, and the like. When plugged in, an appliance, device, or system can announce itself to the mesh network as described above and can be automatically integrated with the controls and devices of the mesh network, such as in the smart-home. It should be noted that the mesh network devices <NUM> may include devices physically located outside of the structure, but within wireless communication range, such as a device controlling a swimming pool heater <NUM> or an irrigation system <NUM>.

As described above, the mesh network <NUM> includes a border router <NUM> that interfaces for communication with an external network, outside the mesh network <NUM>. The border router <NUM> connects to an access point <NUM>, which connects to the communication network <NUM>, such as the Internet. A cloud service <NUM>, which is connected via the communication network <NUM>, provides services related to and/or using the devices within the mesh network <NUM>. By way of example, the cloud service <NUM> can include applications for connecting end user devices <NUM>, such as smart phones, tablets, and the like, to devices in the mesh network, processing and presenting data acquired in the mesh network <NUM> to end users, linking devices in one or more mesh networks <NUM> to user accounts of the cloud service <NUM>, provisioning and updating devices in the mesh network <NUM>, and so forth. For example, a user can control the thermostat <NUM> and other mesh network devices in the smart-home environment using a network-connected computer or portable device, such as a mobile phone or tablet device. Further, the mesh network devices can communicate information to any central server or cloud-computing system via the border router <NUM> and the access point <NUM>. The data communications can be carried out using any of a variety of custom or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6LoWPAN, Thread, etc.) and/or by using any of a variety of custom or standard wired protocols (CAT6 Ethernet, HomePlug, etc.).

Any of the mesh network devices in the mesh network <NUM> can serve as low-power and communication nodes to create the mesh network <NUM> in the smart-home environment. Individual low-power nodes of the network can regularly send out messages regarding what they are sensing, and the other low-powered nodes in the environment - in addition to sending out their own messages - can repeat the messages, thereby communicating the messages from node to node (i.e., from device to device) throughout the mesh network. The mesh network devices can be implemented to conserve power, particularly when battery-powered, utilizing low-powered communication protocols to receive the messages, translate the messages to other communication protocols, and send the translated messages to other nodes and/or to a central server or cloud-computing system. For example, an occupancy and/or ambient light sensor can detect an occupant in a room as well as measure the ambient light, and activate the light source when the ambient light sensor <NUM> detects that the room is dark and when the occupancy sensor <NUM> detects that someone is in the room. Further, the sensor can include a low-power wireless communication chip (e.g., a ZigBee chip) that regularly sends out messages regarding the occupancy of the room and the amount of light in the room, including instantaneous messages coincident with the occupancy sensor detecting the presence of a person in the room. As mentioned above, these messages may be sent wirelessly, using the mesh network, from node to node (i.e., smart device to smart device) within the smart-home environment as well as over the Internet to a central server or cloud-computing system.

In other configurations, various ones of the mesh network devices can function as "tripwires" for an alarm system in the smart-home environment. For example, in the event a perpetrator circumvents detection by alarm sensors located at windows, doors, and other entry points of the structure or environment, the alarm could still be triggered by receiving an occupancy, motion, heat, sound, etc. message from one or more of the low-powered mesh nodes in the mesh network. In other implementations, the mesh network can be used to automatically turn on and off the lighting units <NUM> as a person transitions from room to room in the structure. For example, the mesh network devices can detect the person's movement through the structure and communicate corresponding messages via the nodes of the mesh network. Using the messages that indicate which rooms are occupied, other mesh network devices that receive the messages can activate and/or deactivate accordingly. As referred to above, the mesh network can also be utilized to provide exit lighting in the event of an emergency, such as by turning on the appropriate lighting units <NUM> that lead to a safe exit. The light units <NUM> may also be turned-on to indicate the direction along an exit route that a person should travel to safely exit the structure.

The various mesh network devices may also be implemented to integrate and communicate with wearable computing devices <NUM>, such as may be used to identify and locate an occupant of the structure, and adjust the temperature, lighting, sound system, and the like accordingly. In other implementations, RFID sensing (e.g., a person having an RFID bracelet, necklace, or key fob), synthetic vision techniques (e.g., video cameras and face recognition processors), audio techniques (e.g., voice, sound pattern, vibration pattern recognition), ultrasound sensing/imaging techniques, and infrared or near-field communication (NFC) techniques (e.g., a person wearing an infrared or NFC-capable smartphone), along with rules-based inference engines or artificial intelligence techniques that draw useful conclusions from the sensed information as to the location of an occupant in the structure or environment.

In other implementations, personal comfort-area networks, personal health-area networks, personal safety-area networks, and/or other such human-facing functionalities of service robots can be enhanced by logical integration with other mesh network devices and sensors in the environment according to rules-based inferencing techniques or artificial intelligence techniques for achieving better performance of these functionalities. In an example relating to a personal health-area, the system can detect whether a household pet is moving toward the current location of an occupant (e.g., using any of the mesh network devices and sensors), along with rules-based inferencing and artificial intelligence techniques. Similarly, a hazard detector service robot can be notified that the temperature and humidity levels are rising in a kitchen, and temporarily raise a hazard detection threshold, such as a smoke detection threshold, under an inference that any small increases in ambient smoke levels will most likely be due to cooking activity and not due to a genuinely hazardous condition. Any service robot that is configured for any type of monitoring, detecting, and/or servicing can be implemented as a mesh node device on the mesh network, conforming to the wireless interconnection protocols for communicating on the mesh network.

The mesh network devices <NUM> may also include a smart alarm clock <NUM> for each of the individual occupants of the structure in the smart-home environment. For example, an occupant can customize and set an alarm device for a wake time, such as for the next day or week. Artificial intelligence can be used to consider occupant responses to the alarms when they go off and make inferences about preferred sleep patterns over time. An individual occupant can then be tracked in the mesh network based on a unique signature of the person, which is determined based on data obtained from sensors located in the mesh network devices, such as sensors that include ultrasonic sensors, passive IR sensors, and the like. The unique signature of an occupant can be based on a combination of patterns of movement, voice, height, size, etc., as well as using facial recognition techniques.

In an example of wireless interconnection, the wake time for an individual can be associated with the thermostat <NUM> to control the HVAC system in an efficient manner so as to pre-heat or cool the structure to desired sleeping and awake temperature settings. The preferred settings can be learned over time, such as by capturing the temperatures set in the thermostat before the person goes to sleep and upon waking up. Collected data may also include biometric indications of a person, such as breathing patterns, heart rate, movement, etc., from which inferences are made based on this data in combination with data that indicates when the person actually wakes up. Other mesh network devices can use the data to provide other smart-home objectives, such as adjusting the thermostat <NUM> so as to pre-heat or cool the environment to a desired setting, and turning-on or turning-off the lights <NUM>.

In implementations, the mesh network devices can also be utilized for sound, vibration, and/or motion sensing such as to detect running water and determine inferences about water usage in a smart-home environment based on algorithms and mapping of the water usage and consumption. This can be used to determine a signature or fingerprint of each water source in the home, and is also referred to as "audio fingerprinting water usage. " Similarly, the mesh network devices can be utilized to detect the subtle sound, vibration, and/or motion of unwanted pests, such as mice and other rodents, as well as by termites, cockroaches, and other insects. The system can then notify an occupant of the suspected pests in the environment, such as with warning messages to help facilitate early detection and prevention.

The environment <NUM> may include one or more mesh network devices <NUM> that function as a hub <NUM>. The hub <NUM> may be a general-purpose home automation hub, or an application-specific hub, such as a security hub, an energy management hub, an HVAC hub, and so forth. The functionality of a hub <NUM> may also be integrated into any mesh network device <NUM>, such as a smart thermostat device or the border router <NUM>. Hosting functionality on the hub <NUM> in the structure <NUM> can improve reliability when the user's internet connection is unreliable, can reduce latency of operations that would normally have to connect to the cloud service <NUM>, and can satisfy system and regulatory constraints around local access between mesh network devices <NUM>.

Additionally, the example environment <NUM> includes a smart-speaker <NUM>. The smart-speaker <NUM> provides voice assistant services that include providing voice control of smart-home devices. The functions of the hub <NUM> may be hosted in the smart-speaker <NUM>. The smart-speaker <NUM> can be configured to communicate via the mesh network, Wi-Fi, or both.

<FIG> illustrates an example mesh network device <NUM> that can be implemented as any of the mesh network devices in a mesh network in accordance with one or more aspects of synchronized reception in mesh networks as described herein. The device <NUM> can be integrated with electronic circuitry, microprocessors, memory, input output (I/O) logic control, communication interfaces and components, as well as other hardware, firmware, and/or software to implement the device in a mesh network. Further, the mesh network device <NUM> can be implemented with various components, such as with any number and combination of different components as further described with reference to the example device shown in <FIG>.

In this example, the mesh network device <NUM> includes a low-power microprocessor <NUM> and a high-power microprocessor <NUM> (e.g., microcontrollers or digital signal processors) that process executable instructions. The device also includes an input-output (I/O) logic control <NUM> (e.g., to include electronic circuitry). The microprocessors can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented with processing and control circuits. The low-power microprocessor <NUM> and the high-power microprocessor <NUM> can also support one or more different device functionalities of the device. For example, the high-power microprocessor <NUM> may execute computationally intensive operations, whereas the low-power microprocessor <NUM> may manage less complex processes such as detecting a hazard or temperature from one or more sensors <NUM>. The low-power processor <NUM> may also wake or initialize the high-power processor <NUM> for computationally intensive processes.

The one or more sensors <NUM> can be implemented to detect various properties such as acceleration, temperature, humidity, water, supplied power, proximity, external motion, device motion, sound signals, ultrasound signals, light signals, fire, smoke, carbon monoxide, global-positioning-satellite (GPS) signals, radio-frequency (RF), other electromagnetic signals or fields, or the like. As such, the sensors <NUM> may include any one or a combination of temperature sensors, humidity sensors, hazard-related sensors, other environmental sensors, accelerometers, microphones, optical sensors up to and including cameras (e.g., charged coupled-device or video cameras, active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the mesh network device <NUM> may include one or more primary sensors, as well as one or more secondary sensors, such as primary sensors that sense data central to the core operation of the device (e.g., sensing a temperature in a thermostat or sensing smoke in a smoke detector), while the secondary sensors may sense other types of data (e.g., motion, light or sound), which can be used for energy-efficiency objectives or smart-operation objectives.

The mesh network device <NUM> includes a memory device controller <NUM> and a memory device <NUM>, such as any type of a nonvolatile memory and/or other suitable electronic data storage device. The mesh network device <NUM> can also include various firmware and/or software, such as an operating system <NUM> that is maintained as computer executable instructions by the memory and executed by a microprocessor. The device software may also include a reception manager application <NUM> that implements aspects of synchronized reception in mesh networks. The mesh network device <NUM> also includes a device interface <NUM> to interface with another device or peripheral component, and includes an integrated data bus <NUM> that couples the various components of the mesh network device for data communication between the components. The data bus in the mesh network device may also be implemented as any one or a combination of different bus structures and/or bus architectures.

The device interface <NUM> may receive input from a user and/or provide information to the user (e.g., as a user interface), and a received input can be used to determine a setting. The device interface <NUM> may also include mechanical or virtual components that respond to a user input. For example, the user can mechanically move a sliding or rotatable component, or the motion along a touchpad may be detected, and such motions may correspond to a setting adjustment of the device. Physical and virtual movable user-interface components can allow the user to set a setting along a portion of an apparent continuum. The device interface <NUM> may also receive inputs from any number of peripherals, such as buttons, a keypad, a switch, a microphone, and an imager (e.g., a camera device).

The mesh network device <NUM> can include network interfaces <NUM>, such as a mesh network interface for communication with other mesh network devices in a mesh network, and an external network interface for network communication, such as via the Internet. The mesh network device <NUM> also includes wireless radio systems <NUM> for wireless communication with other mesh network devices via the mesh network interface and for multiple, different wireless communications systems. The wireless radio systems <NUM> may include Wi-Fi, Bluetooth™, Mobile Broadband, BLE, and/or point-to-point IEEE <NUM>. Each of the different radio systems can include a radio device, antenna, and chipset that is implemented for a particular wireless communications technology. The mesh network device <NUM> also includes a power source <NUM>, such as a battery and/or to connect the device to line voltage. An AC power source may also be used to charge the battery of the device.

<FIG> illustrates an example system <NUM> that includes an example device <NUM>, which can be implemented as any of the mesh network devices that implement aspects of synchronized reception in mesh networks as described with reference to the previous <FIG>. The example device <NUM> may be any type of computing device, client device, mobile phone, tablet, communication, entertainment, gaming, media playback, and/or other type of device. Further, the example device <NUM> may be implemented as any other type of mesh network device that is configured for communication on a mesh network, such as a thermostat, hazard detector, camera, light unit, commissioning device, router, border router, joiner router, joining device, end device, leader, access point, and/or other mesh network devices.

The device <NUM> includes communication devices <NUM> that enable wired and/or wireless communication of device data <NUM>, such as data that is communicated between the devices in a mesh network, data that is being received, data scheduled for broadcast, data packets of the data, data that is synched between the devices, etc. The device data can include any type of communication data, as well as audio, video, and/or image data that is generated by applications executing on the device. The communication devices <NUM> can also include transceivers for cellular phone communication and/or for network data communication.

The device <NUM> also includes input / output (I/O) interfaces <NUM>, such as data network interfaces that provide connection and/or communication links between the device, data networks (e.g., a mesh network, external network, etc.), and other devices. The I/O interfaces can be used to couple the device to any type of components, peripherals, and/or accessory devices. The I/O interfaces also include data input ports via which any type of data, media content, and/or inputs can be received, such as user inputs to the device, as well as any type of communication data, as well as audio, video, and/or image data received from any content and/or data source.

The device <NUM> includes a processing system <NUM> that may be implemented at least partially in hardware, such as with any type of microprocessors, controllers, and the like that process executable instructions. The processing system can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented with processing and control circuits. The device <NUM> may further include any type of a system bus or other data and command transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures and architectures, as well as control and data lines.

The device <NUM> also includes computer-readable storage memory <NUM>, such as data storage devices that can be accessed by a computing device, and that provide persistent storage of data and executable instructions (e.g., software applications, modules, programs, functions, and the like). The computer-readable storage memory described herein excludes propagating signals. Examples of computer-readable storage memory include volatile memory and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that maintains data for computing device access. The computer-readable storage memory can include various implementations of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage memory in various memory device configurations.

The computer-readable storage memory <NUM> provides storage of the device data <NUM> and various device applications <NUM>, such as an operating system that is maintained as a software application with the computer-readable storage memory and executed by the processing system <NUM>. The device applications may also include a device manager, such as any form of a control application, software application, signal processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, and so on. In this example, the device applications also include a reception manager application <NUM> that implements aspects of synchronized reception in mesh networks, such as when the example device <NUM> is implemented as any of the mesh network devices described herein.

The device <NUM> also includes an audio and/or video system <NUM> that generates audio data for an audio device <NUM> and/or generates display data for a display device <NUM>. The audio device and/or the display device include any devices that process, display, and/or otherwise render audio, video, display, and/or image data, such as the image content of a digital photo. In implementations, the audio device and/or the display device are integrated components of the example device <NUM>. Alternatively, the audio device and/or the display device are external, peripheral components to the example device. In aspects, at least part of the techniques described for synchronized reception in mesh networks may be implemented in a distributed system, such as over a "cloud" <NUM> in a platform <NUM>. The cloud <NUM> includes and/or is representative of the platform <NUM> for services <NUM> and/or resources <NUM>.

Claim 1:
A method (<NUM>) of synchronizing reception of communications by an end device (<NUM>, <NUM>) that operates in a receiver-off-when-idle mode in a wireless mesh network (<NUM>), the method comprising:
transmitting (<NUM>), by the end device (<NUM>, <NUM>), a parent request message (<NUM>) to a parent device (<NUM>, <NUM>);
in response to the parent request message (<NUM>), receiving (<NUM>), from the parent device (<NUM>, <NUM>), a parent response message (<NUM>) including an indication of a clock accuracy of the parent device (<NUM>, <NUM>);
determining (<NUM>), by the end device and based in part on the received indication of the clock accuracy of the parent device (<NUM>, <NUM>), parameters for synchronized reception of communications from the parent device (<NUM>, <NUM>);
transmitting (<NUM>), by the end device (<NUM>, <NUM>), a child request message (<NUM>) including the parameters for synchronized reception of communications from the parent device (<NUM>, <NUM>), the transmitting being effective to cause the parent device (<NUM>, <NUM>) to transmit communications to the end device (<NUM>, <NUM>) based on the parameters,
based at least in part on the received indication of the clock accuracy of the parent device (<NUM>, <NUM>), determining (<NUM>), by the end device (<NUM>, <NUM>), that the reception of communications from the parent device (<NUM>, <NUM>) is no longer synchronized; and
based on the determining the reception of communication is no longer synchronized:
transmitting (<NUM>), by the end device (<NUM>, <NUM>), a resynchronization message (<NUM>) to the parent device (<NUM>, <NUM>) that is effective to resynchronize the reception of communications from the parent device (<NUM>, <NUM>).