Patent ID: 12213162

DETAILED DESCRIPTION

In many personal, industrial, scientific, and medical applications, time synchronization of separate devices may provide significant benefits. Under dynamic conditions, when a state of a system supported by a wireless network varies with time, there may be an advantage to performing a measurement or initiating some other action by multiple devices simultaneously. For example, performance of electric vehicles may depend on uniformity of charging and discharging of multiple high-voltage battery cells. Accurate simultaneous (synchronous) measurements of the state of each cell may provide data that can be used to optimize battery utilization during acceleration, cruising, braking, and various other maneuvers of the vehicle, as well as data during charging. Similarly, medical devices may be configured to collect simultaneous data from multiple parts of the patient's body. Industrial testing (e.g., crash testing of a car or any other safety-sensitive equipment) may rely on synchronization of measurements performed by multiple sensors. Such a synchronization is typically achieved through a wired connection, which can be used to ensure that all signals are generated, sent and/or, received simultaneously. Wired connections, however, may be cumbersome to install and maintain, especially where a large number of miniature devices are integrated and used as a part of a larger system. In some instances, wired connections to a large number of peripheral devices may not only be inconvenient but may be impractical or even unsafe. Therefore, it may be advantageous to deploy wireless sensors/devices that are easier to install, maintain, or replace than wired devices.

Wireless devices, being largely independent from each other, may have clocks that run with somewhat different speeds compared with other clocks; e.g., different clocks may have a slightly different drift, jitter, etc. It is thus beneficial to synchronize all or at least some of the wireless devices. For example, devices operated using a BT, BLE, or some other wireless network technology, could be synchronized by a suitably prepared signal exchanged between a central device (also referred to herein as a parent device) and various peripheral devices (referred to herein as child devices).

Wireless devices in a testing and control system may be organized into hierarchical wireless networks with multiple layers of nodes. More specifically, the wireless devices (nodes) of the lowest layer may collect sensing data and relay the collected data to the nodes of the next layer, and so on. Each node of a given layer may collect data from multiple nodes of the previous layer, as well as add a data collected by that node, and pass the aggregated data further up the network of nodes, until all data is collected by a root node (a top node, a senior node, a central node, etc.). Additionally, the root node may propagate instructions to the lower nodes in the reverse direction. In some networks, the root note may propagate data (e.g., audio data) that is to be delivered synchronously to multiple users or user devices (e.g., to multiple speakers). In such complex scatternet topologies of wireless nodes, a single device may act as both a parent device (e.g., the device that dictates parameters of a connection with one or more child devices) and a child device (e.g., the device that follows the instructions of a parent device for communication with the parent device). Similarly, in a wireless mesh network, the flow of data is not rigidly defined and may take many paths through different sets of nodes to reach a destination device.

Efficient operations of such wireless networks present a number of technological challenges. In addition to time synchronization, for concurrent measurements or data delivery, a wireless network may have to be optimized for increased throughput, e.g., to ensure that the collected data (or instructions) is delivered to (or from) the root node as quickly as possible. A parent device needs to collect data from multiple child devices before the parent device can upload the data to its own parent device. A delay in collecting data may cause the parent device to miss the communication window allocated for the data upload and idle until its own parent device opens up the next communication window. Such delays may be aggravated with each subsequent layer of nodes. As a result, the data from various sensors may reach the destination device (e.g., the root node) at a variety of different times, and in some instances too late for useful processing by the destination device.

Additionally, multiple parent devices (nodes) of each layer may be receiving data from their child devices at the same time. In compact systems (e.g., electric batteries), the distance between various communicating devices may be relatively small, causing a substantial radio interference to occur between different communication links. Consequently, data packets may be lost on some occasions thus further exacerbating the data delivery problems.

Aspects and implementations of the present disclosure address at least some of these and other limitations of the existing technology by enabling systems and methods of accurate clock synchronization in wireless networks, efficient staging of time-multiplexed communication windows to minimize time delays, and frequency multiplexing of simultaneous communications that use different wireless links. For example, techniques of cascade time synchronization are disclosed, where a given node synchronizes/adjusts its clock based on a periodic (with known period) sequence of communications received from the node's parent device and communicates with the node's child devices at times that are determined using the synchronized/adjusted clock. As a result, the time synchronization process propagates from the top node to the nodes of the lowest layer. In some implementations, connections of the node with its child devices are staged (spaced) with intervals that allow individualized collection of data from each child device to occur prior to the node's communication window for data upload to the node's own parent device. As a result, data propagates up the network of wireless links over an efficiently ordered sequence of uploads until all collected data reaches the top node within an optimal time. In some implementations, multiple parallel uploads may occur concurrently using different frequencies (wireless communication channels) that are spaced out to reduce interference. Numerous other systems, methods, and techniques are further described below.

FIG.1is a diagram of a wireless network system100in which time synchronization, time multiplexing, frequency multiplexing, synchronous actions and various other techniques described in the present disclosure may be performed, according to some implementations. Depicted is a network device110that can support wireless connections and data exchanges with multiple devices. Network device120may communicate with a parent device110. Network device120may also communicate with a child device124. Even though a single child device is depicted, network device120may support wireless connections with any number of child devices (and, similarly, with multiple parent devices). Depicted are some components and modules of network device120, as discussed in more detail below. Although no internal structure is depicted for parent device110and child device124, it will be understood that some or all components of network device120may also be present in parent device110, child device124, and other devices of the wireless network system100.

Parent device110may have a wireless connection104with network device120, and network device120may have a wireless connection106with child device124, as indicated schematically with the corresponding arrows. Wireless connections (also referred to herein as wireless links)104and106may be Bluetooth (BT) connections, Bluetooth Low Energy (BLE) connections, or any other suitable connections. Some or all devices (e.g., nodes) of wireless network system100may be associated (and may communicate, e.g., using a bus or a wired connection) with one or more additional devices, e.g., parent device110may be associated (and communicatively coupled) with one or more devices122-A, network device120may be associated with one or more devices122-B, and child device124may be associated with one or more devices122-C. In some implementations, various devices of wireless network system100(including various associated devices) are configured to perform one or more synchronous actions.

Parent device110may send one or more messages via wireless link104to be used by network device120for time synchronization. Parent device110may form a wireless communication link with a parent device of its own, and may receive instructions from that parent device. Parent device110may be a central node of wireless network system100(control device), and may be generating instructions for network device120(as well as various child devices of network device120). In some implementations, one of associated devices122-A may be a control device for the entire wireless network system100. Network device120may send one or more messages to child device124to be used to by child device124to initiate or maintain time synchronization with network device120. In particular, network device120may act as a child device (peripheral device) with respect to wireless communication link104and as a parent (central device) with respect to wireless communication link106. Child device124may also have one or more of its own child devices (mot shown), and may, in turn, transmit messages to those child devices to further extend the time synchronization process. In some implementations, some or all of the devices ofFIG.1may form communications with multiple other devices. In some implementations, designations of parent, child, central, peripheral, etc., may be changeable; e.g., the wireless device network may be re-configured. In some implementations, the wireless device network may be a wireless mesh network where roles of devices may be dynamic.

An event of sending or receiving of a message may mark a time used by devices of wireless network system100for synchronization. In some implementations, child devices may use the time of reception of a message from the parent device to perform time synchronization. Network device120may use reception of one or more messages via link104to enable time synchronization and data exchange with parent device110. Child device124may use reception of one or more messages via link106to enable time synchronization and data exchange with network device120. Communicated messages may include explicit indications of time, such as time stamps (e.g., clock values at the time of generation of the respective messages), a future time for performing a specific action, an indication of a connection interval, an indication of a connection event count, etc. The cascade time synchronization may be performed as follows. Network device120may use one or more messages sent by parent device110to enable synchronization with parent device110, and child device124may use one or more messages sent by network device120to enable synchronization with network device120, e.g., after the latter has established synchronization with parent device110. In this way, all devices of the network may become synchronized.

Network device120(and, similarly, parent device110, child device124or any other device of wireless network system100) may be any device supporting the network connectivity and functionality (e.g., receiving, sending, and relaying data), such as a desktop computer, a laptop computer, a tablet, a phone, a smart TV, a sensor, a lighting device, an electric battery, an electric generator, an appliance, a controller (e.g., an air conditioning, heating, water heating controller), a lock, a component of a security system, a location beacon, or any other type of network devices. Network device120may support a synchronization application130, which may be a module (e.g., a software, firmware, hardware component, or any combination thereof) that performs time synchronization and facilitates synchronous actions by network device120(or an associated device122-B). In some implementations, synchronous action by network device120is performed simultaneously with actions by other devices, e.g., by parent device110, child device124, or other devices of wireless network system100, or devices associated with any of the aforementioned devices. In some implementations, synchronous action by network device120may be performed non-simultaneously with actions performed by other devices but according to a predetermined pattern. For example, parent device110may perform an action at a first predetermined time, network device120may perform another (or a similar) action at a second predetermined time (which may be earlier or later than the first predetermined time), and so on. Synchronization application130on network device120may operate in conjunction with a similar application instantiated on parent device110, e.g., receiving instructions from parent device110providing data to parent device110. Synchronization application130may be an industrial application, a vehicle application, a safety application, a measurement control application, a technical control and monitoring application, a smart home control application, a navigation application, a robotic application, or the like. Synchronization application130may receive (and process) indications from parent device110that include a time associated with a synchronous action, time synchronization, data exchange, etc. The received indications may cause associated devices122-B to perform one or more operations in conjunction with the synchronous action, collect data from the associated device122-B, process and communicate the collected data to parent device110, and so on. Application130may also generate messages that are sent to child device124to facilitate synchronization between child device124and network device120.

Network device120(and other devices of wireless network system100) may be capable of a wireless connectivity at a single radio band (e.g., 2.4 GHz band, 5 GHz, 60 GHz, etc.) or multiple bands (e.g., both 2.4 GHz and 5 GHz bands). Network device120may use (or be connected to) one or more antennas140, which are used to receive and transmit radio wave signals. In some implementations, antenna(s)140may be or include a single multi-input multi-output (MIMO) antenna. A signal received by antenna(s)140may be processed by a radio component142, which may include filters (e.g., band-pass filters), low-noise radio-frequency amplifiers, down-conversion mixer(s), intermediate-frequency amplifiers, analog-to-digital converters, inverse Fourier transform modules, deparsing modules, interleavers, error correction modules, scramblers, and other (analog and/or digital) circuitry that may be used to process modulated signals received by antenna(s)140. Radio component142may provide the received (and digitized) signals to a physical layer component (PHY)144. PHY144may convert the digitized signals into frames that can be fed into a Link Layer146. Link Layer146may have a number of states, such as advertising, scanning, initiating, connection, and standby. Link Layer146may transform frames into data packets. During transmission, data processing may occur in the opposite direction, with Link Layer146transforming data packets into frames that are then further transformed by PHY144into digital signals provided to radio component142. Radio component142may convert digital signals into analog radio signals and transmit the radio signals using antenna(s)140. In some implementations, radio component142, PHY144, and Link Layer146may be implemented as parts of a wireless controller, e.g., a wireless controller implemented as a single integrated circuit.

Network device120(or other devices) may include one or more central processing units (CPUs)150. In some implementations, CPU150may include one or more finite state machines (FSMs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASIC), or the like. Network device120may have a single processor that executes various operations related to synchronization and may also support any other processes running on network device120. In some implementations, network device120may have a dedicated processor for synchronization operations that is separate from other processes and applications running on network device120. Network device120may further include a memory device160, which may be (or include) a non-volatile, e.g., read-only (ROM) memory, and volatile, e.g., random-access (RAM), memory. Memory device160of network device120may also store codes and supporting data for synchronization application130.

Network device120may further include one or more clocks148and a power management unit (PMU)170, which may manage clock/reset functions and power resources. Network device120may further contain an input/output (I/O) controller190to enable communications with other external devices and structures, including associated devices)122-B. In some implementations, I/O controller190may enable a general purpose I/O (GPIO) interface, a USB interface, a PCM digital audio module, and other I/O components.

Wireless Device Time Synchronization and Drift Management

In some aspects of the current disclosure, wireless devices communicate in a connected mesh or tree of nodes. In some embodiments, instructions for managing the wireless network may be sent from a central, root, or aggregation node out to nodes further down a tree network. Data (e.g., measurement data) may flow from the lower nodes to the central node. In some embodiments, a time synchronization system may be implemented based on messages sent between nodes of the network. The time synchronization system may enable all nodes establishing or updating a common understanding of time each connection event.

FIG.2illustrates an example clock synchronization event200in wireless networks using a message212sent by a parent device and a known schedule of communication with the parent device, according to some implementations. Depicted schematically inFIG.2are operations of a parent device (e.g., central device, parent network device, etc.)210and a child device (e.g., peripheral device, child network device, etc.)220. Parent device210and child device220may be a part of a Bluetooth (BT) network, a BT Low Energy (BLE) network, or any other wireless network. Parent device210and child device220may have previously established a wireless network connection. Although depicted inFIG.2, for brevity and conciseness, is a single child device220, parent device210may be concurrently supporting connections with multiple child devices. Various devices depicted inFIG.2may be communicatively coupled (e.g., via a wired connection, a bus, or wirelessly) with one or more associated devices. In some implementations, parent device210and child device220may be monitoring a state of the associated device(s) or facilitating operations of the associated device(s). For example, child device220(and/or various other devices that are not shown inFIG.2) may be associated with one or more cells of a battery (e.g., an automotive battery of an electric vehicle) and may be performing (or facilitating) measurements of a state of the cells of the battery. The measurements may be performed periodically or at times determined by a host controller communicating with devices of the wireless network. Child device220, parent device210, and/or various other devices may be integrated into a battery pack. The battery may be used to power an electric motor that propels an electric vehicle. As the battery is powering the motor of the vehicle, battery cells may be in a constant state of discharging (and/or charging, e.g., during braking), which may occur differently in different cells. To perform meaningful and accurate measurements of the state of different cells, various devices of the wireless network may perform the measurements (or cause the measurements to be performed by associated sensors coupled to the cells) synchronously.

In some implementations, synchronous actions by the devices of the wireless network are enabled by allowing various devices of the wireless network to determine the difference of their internal clocks with a clock of at least one other reference device in the network, e.g., parent device210. The determined clock differences may be used to perform synchronous actions simultaneously on multiple devices. In some implementations, clock synchronization200may be facilitated by the specification of a wireless protocol of the wireless connections. For example, as may be set by parent device210during initial establishment of a connection between parent device210and child device220, connection events (occurring during a period of time defined by connection event230) may be spaced by a fixed connection interval T0.

In some implementations, clock synchronization200may be achieved as follows. Parent device210may send, at the beginning of scheduled connection event230, a message212to child device220. Child device220may be expecting the start of connection event230. In particular, child device220may power up radio circuitry as well as other hardware, software, circuitry, and the like, in preparation to receiving message212. Child device220may begin listening to communications from parent device210at a certain time before the onset of connection event230, thus enabling a widened connection event240, e.g., by adding some window widening242to the anticipated start of connection event230of parent device210. Window widening242may assist child device220in communicating (e.g., exchanging messages) with parent device210by anticipating a possibility that the clocks of parent device210and child device220are not perfectly synchronized, e.g., due to differing jitter, drift, etc., experienced by the clocks. In some embodiments, connection event230and widened connection event240may each include a transmission (TX) portion and a reception portion (RX). The TX portion of connection event230may occur before the RX portion of connection event230. The TX portion of connection event230may correspond to the RX portion of widened connection event240, and the RX portion of connection event230may correspond to the TX portion of widened connection event240. In some embodiments, window widening242may be applied to only the RX portion of widened connection event240, to provide protection against clock jitter, drift, offset, etc., between parent device210and child device220.

In some implementations, child device220may record a time stamp, according to the internal clock of child device220, at a time of reception of message212(e.g., upon a receiving hardware detecting a message header, message access code, etc.). In some implementations, child device220may generate a current clock time based on the time of reception of message212. Child device220may incorporate other information to generate the synchronized clock time, such as utilizing an expected time of arrival of message212. In some implementations (e.g., if the wireless network comprises a BLE wireless network), the expected time of arrival of message212may be determined from a connection event count (e.g., a number of connection events occurred since the connection was established, changed, reset, etc.) and the connection interval T0. The connection event count may be tracked by parent device210and child device220separately. In some implementations, message212may include an explicit indication of time to facilitate synchronization of the internal clocks of parent device210and child device220. Message212may include a connection event counter, for example to protect against lost messages, disrupted communications, interference, etc. Message212may further include a time stamp, a timing offset, etc. to facilitate generation of a common indication of time.

As a first example implementation, parent device210and child device220may form a wireless communication connection. Parent device210and child device220may share a common time established via a unilateral time synchronization. More specifically, parent device210may maintain its clock independently from clocks of child devices, whereas child device220may perform periodic corrections (time adjustments) to ensure that the clock of child device220is aligned with the clock of parent device210. Parent device210may schedule a time of communication for parent device210and child device220to exchange messages (e.g., message212, message222, etc.) based on the clock of parent device210. Child device220may prepare to receive a message by opening widened connection event240. Parent device210may send message212at the designated time (as measured by the clock of parent device210), at the onset of connection event230, denote as time t1, which may be also a time when child device220(as measured by its own clock) is expecting the communication from parent device210to begin. When communication hardware of child device220detects message212(e.g., by detecting a header or access code communicated by parent device210), child device220may record a time stamp tTS, e.g., as measured by the clock of child device220. A processing device of child device220may then record the difference (time correction), Δt1=t1−tTS, between the expected time of communication t1and the actual recorded time of communication tTS. Subsequently, when child device220is instructed (by parent device210, the root node, etc., to perform an action (e.g., a synchronous action) at a target time tTarget) child device220may perform the action at the corrected time (as measured by child device's clock), tTarget+Δt1. The time correction may then be updated (Δt1→Δt2→Δt3→ . . . ) during subsequent connection events (e.g., at times t2, t3, etc.) with parent device210. The operations of parent device210sending a message, child device220receiving and recording a time stamp, and child device220updating the time correction Δtjmay be repeated as necessary (e.g., periodically, every connection event, every n connection events, etc.) to maintain a target accuracy of time synchronization between the two devices.

As a second example implementation, parent device210and child device220may establish a communication connection and a common time as follows. The communication connection may be a BLE connection, with an established (e.g., at the time of setting up the connection) connection interval T0. When a wireless connection is established between two nodes, the nodes may share an understanding of a connection event counter (CEC) for each connection event. A child device uses a packet received from the parent device to synchronize the clock of the child device, e.g., when a hardware of the child device recognizes that a packet has been received, the hardware establishes a common epoch, where the parent device and the child device are time-synchronized.

Upon reception of message212, child device220may update a connection event counter, which may be an indication of how many connection events have been scheduled since some previous time, such as the onset of the communication connection. Child device220may then use connection interval T0to generate a common indication of time. For example, the expected time of reception of message212(e.g., according to the clock of parent device210) may be given by texp=CEC×T0+Toffset, where CConEvis a counter of connection events and Toffsetis a time offset assigned (e.g., during initial connection with parent device210) to child device210relative to the starting time of the connection interval T0. Any two connected nodes (e.g., parent device210and child device220) may establish a common timestamp based on the connection event counter. For example, parent device2100may share a data tuple (CEC, timestamp) after the connection with child device is established, and therefore establishes the timestamp in the child device220. The timestamp of child device220, although tied to that of parent device210, can drift from the timestamp of parent device210. To compensate for this drift, when child device220receives a communication from parent device210, child device increments connection event counter CEC+1→CEC, and uses the above formula to correct the timestamp on child device. For example, child device210may use the time of receiving a first packet of n-th connection event to set its clock to be texp=CEC(n)×T0+Toffsetat the time of reception of the first packet

The described technique allows to quickly establish a synchronized time between a parent device a child device. In some implementations, child device220may use the counter, the connection interval, and the time offset to determine the expected reception time texp, and then use the actual time of reception of message212as measured by the child device's clock to calculate the time correction Δtj(after recording the counter value CConEv=j). Other equations may be used to establish a common time between devices and still be within the scope of this disclosure. In some implementations, parent device210may communicate some information for use in clock synchronization and child device220may provide other information. For example, parent device210may include in message212the actual time of transmission (or generation) of message212(measured by the clock of parent device210) and child device220may determine the actual time of arrival of message212(by the clock of child device220). Child device220may then determine the difference of the two times as the current time correction Δt. In some implementations, child device220can further adjust the time correction using an estimate of time delay in transmission and reception of message212.

In some implementations, parent device210may send message212which includes a connection event counter and an indication of time (e.g., a time stamp). Parent device210may then send subsequent messages which do not include this information, and child device220may manage (e.g., increment) counter when subsequent messages are received. In some implementations, parent device210may, at a later time, resend (or update) the connection event counter and provide a new time stamp. Such a later message that includes the updated information may be sent responsive to, for example, a triggering event, such as a loss and reestablishment of connection with child device220, an update to connection parameters (e.g., a change to connection interval T0, a change of communication frequency, etc.), or the like.

Establishing time synchronization may be accomplished in a variety of ways. In one implementation, managing connection events and maintaining the time correction may be performed using multiple clocks (e.g., clocks148ofFIG.1). For example, prior to expected start (e.g., t1) of connection event230, software (e.g., firmware) executed by a processor of child device220may advance a first clock (e.g., an internal device clock, etc.) by an amount of an intended level of window widening242causing the first clock to start a reception interval (e.g., open widened connection event240) prior to t1. At the time of reception of message212(e.g., the message's header or access code), the hardware may adjust the first clock of child device220in such a way that the actual time of reception of message212matches the expected time of reception t1. The time-adjusted first clock may then be used to update a second clock (reference clock) maintained separately on child device220. The first clock may then be advanced again in anticipation of the next connection event that is expected to start at time t2. In the meantime, the updated second clock may maintain the synchronized time with the parent device (and, therefore, with other devices of the network) and may be used to determine a timing of various actions performed by child device220, e.g., synchronous actions. In some implementations, the expected times of reception t1, t2, etc., may be communicated from parent device210to child device220in advance (e.g., during initial connection setup) or during a previous connection event230(e.g., as part of message212). In some implementations, the expected times of reception may be calculated by child device220in view of a connection interval, a connection event count, or the like.

In some implementations, a single clock manages connection events and maintains a time correction. For example, at the time of reception of message212, child device220may create a time stamp. Software of child device220may then determine and maintain (e.g., as described above) the difference Δt between the time of arrival of the message, as measured by the internal clock of child device220(e.g., the time stamp) and the expected time of arrival of the message. The software then plays the role of the reference clock by scheduling various actions by child device220using the internal clock that is adjusted by Δt. Similarly, the software maintains the intended size of window widening242and causes child device220to open widened connection event(s)240at appropriate times.

In some implementations, child device220may receive message212, and may schedule (based on data received by in message212, data received in another message, data generated by child device220, etc.) a time for a future action by adding some interval to the time of reception of message. For example, message212may include indication that an event (e.g., a future connection event, a synchronous action or measurement, etc.) is to occur after a certain time delay (interval) from the time of reception of message122. Child device220may compute a target time of action by adding the delay to the current (at the time of reception) clock value and, when the clock reaches the target value, perform the action. In some implementations, various devices associated with the nodes of a wireless network may be configured to perform a synchronous action, and may use methods such as those described above to achieve clock synchronization. In one example, a battery management system for a multi-cell battery (e.g., the battery of an electric vehicle) may perform simultaneous measurements of properties of various cells. In another example, a medical sensing system may perform simultaneous measurements of a state of various parts of a patient's body. Devices that perform such measurements (e.g., of a battery or patient's body) may be associated with nodes of the wireless network that are synchronized using one or more methods described above.

In some implementations, child device220may correct for the time delay that passes between parent device210sending message212and child device220receiving message212(e.g., air time, processing time, etc.), which is illustrated schematically with the oblique arrow indicating communication of message212inFIG.2. For example, the time synchronization may be performed by adding an estimated time delay, an average time delay measured in field testing, and the like. In some implementations, the time delay is not taken into account. For example, synchronization tolerance of clocks of the various devices (in view of the accuracy of applications performed by the device) may be such that accounting for the delay does not bring significant additional benefits.

The technique of time synchronization may be extended to other nodes of the network. More specifically, intermediate nodes may translate the timestamps (determined from their connections to the respective parent nodes) to the child nodes. After the intermediate node established (received) timestamp tuple (CEC, timestamp) during one of the intermediate node connection events to its parent node, the intermediate node may translate a new tuple (CEC(j), timestamp(j)) for each connection to child node j. The child node then, in turn, translates the timestamp to its children. This process establishes a timestamp within the full topology of the network. Each level of the tree of nodes involves some error in the timestamp, and multiple levels of the tree can increase the error. Yet as long as the nodes are periodically exchanging packets, and thereby synchronizing clocks, this error may be meaningfully contained.

The CEC/timestamp tuples may be generated and transmitted between a parent device and a child devices at the time (or after) the respective connection is first established. In some implementations, it may be sufficient to generate and send this tuple once and use generated CEC/timestamp tuple for the rest of the lifetime of the connection. In some implementations, CEC/timestamp tuple may be updated one or more times via a message from the parent node to the child node. For example, connection parameters may have to be updated via the Connection Update procedure. In some implementations, CEC/timestamp tuple may be transmitted in application-level messages. In some implementations, CEC/timestamp tuple may be transmitted via custom Link Level messages.

The advantages of the disclosed techniques of establishing timestamp in the full topology of nodes include (but are not limited to) accuracy, efficiency and resilience (to lost packets). For example, if a high quality Low Power Oscillator (LPO) clocks are being used, the accuracy of timestamps can be ˜5-10 us in a tree of depth 2 and for a connection interval of 100 ms. The disclosed techniques have low demands to the bandwidth and low power consumption, use as little as one parent-child communication to synchronize time and can be established quickly in an arbitrary topology of nodes.

Clock Drift Management and Link Coupling

Clocks of different devices may be aligned (synchronized) as described above. Additionally, the aligned clocks of various device have to maintain this alignment by tracking and/or adjusting the timing of the communication links to child nodes to be in alignment with the links to the parent node(s), after synchronization communications are received from the parent node(s). As a result, a fixed relationship between parent and child communication links are enforced upon such synchronization. In some implementations, this may be implemented via coupling of a leader link to a follower link. For example, a link to a parent may be the leader link. When synchronization is performed using a communication received via the leader link, the timing of the follower link is updated and brought in alignment with the leader link. For example, a fixed offset is determined for the follower link using a clock adjustment procedure that updates the time offset between the leader and follower link to the new offset. If the leader link and the follower links are maintained via separate hardware clocks, the clock for the follower link may be updated based on the synchronization with the leader link.

Such a maintenance of alignment between two links is may be referred to as link coupling. Link coupling is distinct from what is known as clock dragging, where the timing of one link is slowly adjusted (dragged) to be in better alignment with another clock. Link coupling involves updating the timing of the follower link to be in alignment with the leader link, so that changes in timing of the leader link lead to immediate changes in the timing of the follower link. As a result clock drift cannot pull the two links away from optimal alignment.

Link coupling may also be used in a multi-device topology of nodes (as depicted below inFIG.3), which include a root node to which data is streamed from other nodes or, alternately, from which data is streamed to the other. Connections between the nodes may be dedicated Bluetooth (BR/EDR or LE) connections. Some or all connections may have the same or similar connection intervals. As described below, data transfer in such a tree of nodes may be optimized to achieve low latency and a low rate of retransmission.

FIG.3illustrates an example node topology300of a wireless network, according to some implementations. Node topology300may describe a Bluetooth network, a BLE network, a Wi-Fi network, or another type of wireless network. Node topology300may include any number of nodes configured to pass data to other nodes (or to associated devices), to process data, to combine data, etc. The nodes may also be configured to communicate with respective associated devices. For example, each (or at least some) nodes may be associated with (or may manage or control) a measuring device. A root (central) node of the network may be configured to communicate with a device that controls the entire wireless network. In some implementations, the wireless network may have multiple root nodes302(not shown inFIG.3), one or more of which may be back-up root nodes or nodes having the same network status and rights to control the network.FIG.3depicts a primarily binary tree topology, with each node communicating with one node of a higher level and multiple nodes of a lower level, but aspects of this disclosure may be applied to other topologies, including other tree topologies, topologies that are not trees, such as bus topology, star topology, ring topology, and the like. A node may be any device supporting wireless connectivity and functionality (e.g., capability of receiving, sending, and/or relaying data), such as a desktop computer, laptop computer, a tablet, a phone, a smart TV, lighting, or other device, an appliance, a controller, a component of a security system, a purpose-built device, or any other type of network device.

Node topology300includes a number of nodes, arranged in layers, connected by communication links310-j. In some implementations, nodes of the network (e.g., all nodes, nodes of several layers, etc.) are configured to control (or communicate with) associated devices. In some implementations, each node of the network is associated with a device for monitoring conditions of a cell of a battery of an electric vehicle. Root node302may be (or be associated with) a central or control device. The central or control device may control parameters of the wireless network, communication schedule between the nodes, may perform a final aggregation of data collected by (or at a direction) of various nodes, etc. Root node302is communicatively coupled with level-1 nodes304. (Level-j nodes may be nodes that are removed from root node302by j communication links.) In some implementations, a node (of a particular link310-j) that is closer to root node302(e.g., level-(j−1) node) may be a parent node in control of link310-j, e.g., may be the device that dictates timing, interval, frequency, etc., of communications occurring via link310-j. One or more nodes (of the same link310-j) that are farther away (e.g., level-j nodes) from root node302may be child nodes that follow the instructions of the parent node as to the communication timing, frequency, etc., occurring via link310-j.

In a tree scatternet topology, a level-j node may be a parent node to one or more level-(j+1) nodes and also a child node to a level-(j−1) node. Any node that has both a parent node and at least one child node may be referred herein as an intermediate node (intermediate device). For example, any node except the root node and the terminal nodes of the ultimate level-n nodes may be intermediate nodes. Topology300illustrates schematically such a scatternet topology (scatternet network) that includes a root node302, and nodes of several layers below root node302, namely level-1 nodes304-k, level-2 nodes306-k, and level-3 nodes308-k. It should be understood that any number of levels may be included in a tree topology of nodes. In some implementations, nodes of the lowest layer (e.g., level-3 nodes308-k) may be associated with devices for performing a synchronous action, such as manipulating a device, taking a measurement, etc. Segments of data (e.g., results of measurements) may be passed by level-3 nodes308-kto their respective parent nodes, e.g., level-2 nodes306-k. Level-2 nodes306-k(or their associated devices) may act as aggregators of the segments of data received from level-3 nodes308-k. Nodes306-kand may themselves be associated with devices that perform a synchronous action (e.g., the same synchronous action as being performed by one or more level-3 nodes308-k). Accordingly, nodes306-kmay generate additional data segments that are added to the aggregated data. The aggregated data may then be passed to level-1 nodes304, which may act as aggregators for the data from level-2 nodes306and level-3 nodes308. For example, node306-1may be a parent node (PN) to nodes308-1,308-2, and308-3and a child node (CN) to node304-1. The data may be collected by node306-1from upstream nodes308-1,308-2, and308-3, added to, aggregated (and, optionally, modified or otherwise processed) and provided to the downstream node304-1. This process may continue until the data generated during (or in conjunction with) the synchronous action is delivered to root node302. The specifics of data generation, communication, aggregation, etc., may be determined by a particular application, network topology, wireless communication protocol, or the like. In some implementations, some information may propagate in the opposite direction (as indicated by the dashed arrow). The information may include time synchronization data packets, time stamps, target times for the synchronous actions, instructions how the synchronous actions are to be performed, and so on.

In some implementations, instructions in topology300may flow from root node302to nodes of lower levels, e.g., a control device associated with root node302may determine communication timings, frequencies, intervals, etc., for the communication connections of the network, and may communicate instructions indicating these parameters to the nodes of the network via links various links310-jbetween the nodes. As used herein, for the sake of nomenclature, the direction from a given node toward the root node302may be referred to as the downstream direction and the direction away from the root node302may be referred to as the upstream direction. It should be understood, however, as explained above, that information may flow in both directions over each link. In some implementations, the data may be collected in the course of measuring conditions proximate to an associated device, such as properties of a battery cell, properties measured by a medical sensor, industrial sensor, laboratory sensor, and the like.

In some applications, the timing and alignment of data transmissions may be important since misaligned transmissions can cause delays in data transfer up the tree of node, increase latency and power loses in retransmissions due to data collisions. To enable optimal data transmission (and/or forwarding) from lower level nodes to higher level nodes, the optimal alignment in this tree of nodes may first be established. In particular, timing of the connections between a given node and its child nodes may be just before the connections to the parent node(s). A suitable gap (time delay) between parent and child connections may be used to allow for communication window widening and data aggregation.

The advantages of such placement of transmission may include (but are not limited to): low latency of data transfer, reduction in power due to avoidance of collisions, lower packet error rate. In a given topology, the connections may be established starting from higher level links (e.g., from the root node) followed by lower level links. Optimal arrangement of the timing of transmissions is facilitated by each intermediate being in control of connections to its child nodes and following its parent in with respect to the connection to that parent.

In BLE networks, the Connection Update procedure can be used to change (e.g., improve) the timing of the connection. The Connection Update procedure establishes the timing of a first connection event that follows the Connection Update, which determines the timing of subsequent connection events. The use of the Connection Update allows for reacquisition of the target placement in case a connection dropped and has to be recreated.

After the optimal timing of connections is established, link coupling procedure may be used to maintain this timing. At each intermediate node the connection to the parent is the leader link and the connections to the child nodes are the follower links. Correspondingly, whenever the intermediate node is synchronized with the parent node, the timing of the connections to the child nodes are immediately adjusted to conform to this optimal offset. Since parent devices at each level adjust their respective clocks to be in fixed alignment with their own parent, the child nodes may factor in the clock adjustment of their parent nodes by using a larger window widening factor, e.g., with each subsequent layer of nodes having an increased window widening. Such progressive window widening allows to mitigate drift compounding of clocks in multiple layers. The additional window widening may add an amount to the connection time interval. In some implementations, this may be mitigated by using shorter connection intervals and/or using more accurate clocks (e.g., to minimize window widening).FIG.4illustrates an example communication scheme400for communications between nodes of multiple layers of a wireless scatternet network, according to some implementations. Communication scheme400is illustrated using connections between node304-1of level-1, node306-1of level-2, and nodes308-1,308-2, and308-3of level-3 (as depicted inFIG.3), but the described communication scheme applies to communications of nodes of any three adjacent layers of any network having an arbitrary number of layers of nodes. Node306-1has a parent node304-1and three child nodes308-1,308-2, and308-3. A device associated with node304-1may control the communication connection between node304-1(and its associated device) and node306-1(and its associated device). For example, communication between node304-1and node306-1may be dictated by a clock of node304-1(or its associated device). The parameters (e.g., communication frequency, communication timing, connection interval, etc.) of the communication connection between node304-1and node306-1may be determined by node304-1, by the root node302(control node, control device) of the network, or by another device that controls communication scheme400. In some implementations, the parameters of the communication connection may be determined by multiple devices; for example, some parameters may be determined by the control device and some parameters may be determined by the device associated with node304-1. For example, a range of possible parameters may be provided by the control device and the specific values of these parameters (within the provided range) may be generated by node304-1. Likewise, node306-1may control the communication connection between node306-1and child nodes308-1,308-2, and308-3, e.g., in a similar fashion to that described above in connection with communications between nodes304-1and306-1.

At time t1, node304-1may open a connection event (CE)410to communicate data to node306-1and may receive data from node306-1. CE410may be opened at a time determined in view of a clock value of the device that controls the entire wireless network, such as the root node (node of level-0) using, e.g., the techniques of cascade clock synchronization described above in relation toFIG.2. In particular, a clock of node304-1(which is used to start CE410) may be synchronized relative to the clock of the root node. Node306-1may open its CE420(for communication with node304-1) prior to the start of CE410. This implements a widened connection event, to assist in accounting for clock drift, jitter, etc. In some implementations, all communication connections within a network (e.g., each link310-jofFIG.3) may have the same period of communication (e.g., T0). In some implementations, different links310-jmay be used with a different period between communications. For example, nodes308-1,308-2, and308-3may communicate with node306-1every connection interval T0, but node306-1may communicate with node304-1every two connection intervals (period 2T0) In some implementations, all links may be used to communicate during every connection interval T0.

Within a single connection interval T0, node306-1may communicate with each of its child nodes308-1,308-2, and308-3. More specifically, node306-1may open, at a time t2, as measured by a clock of node306-1, a CE422-1to communicate with child node308-1. Child node308-1may have opened a widened CE430-1at a time prior to time t2. A message received by node308-1during CE430-1from node306-1may be used to synchronize (or re-synchronize) the clock of node308-1to that of node306-1, as described above in relation toFIG.2or using similar techniques. Similarly, node306-1may open additional CEs to communicate with other child nodes of node306-1. For example, node306-1may, at time t3, open CE422-2to communicate with child node308-2and, at time t4, open CE422-3to communicate with child node308-3. Each of the nodes308-2and308-3may open a widened communication interval, e.g., CE430-2and CE430-3, respectively. In some implementations, various CEs may be non-overlapping in time so that there is no cross-talk or interference when different communication links are being used. In some implementations, time delays t2−t1, t3−t1, and t4−t1may be established, managed, and enforced by node306-1(or a device associated with node306-1). These fixed time delays may be enforced by the techniques of link coupling.

Communication scheme400ofFIG.4may be extended to include additional child devices, levels of nodes, etc. After expiration of connection interval T0, e.g., at time t5=t1+T0, node304-1may open a new CE411, node306-1may open a corresponding CE421, and some or all communications illustrated inFIG.4may be repeated.

In some implementations, as indicated with dashed arrows450, timing delays between connection events may be enforced to maintain relative connection timings. During CE410, node304-1may transmit a message412to node306-1. Node306-1may be configured to synchronize time (or update time synchronization) with node304-1upon reception of message412(e.g., upon the hardware of node306-1detecting message412, its access code, header, etc.). Subsequently, node306-1may open CE422-1and transmit a message414to node308-1. Node308-1may be configured to generate a synchronized time with node306-1upon reception of message414. As a result, any adjustment of clock of node306-1may be passed onto child node308-1by enforcing the time of transmission of message414to child node306-1based on the periodically adjusted (time-synchronized) clock of node306-1.

To accommodate de-synchronization of clocks of node304-1and node306-1that has occurred since the last synchronization event (e.g., that has occurred during the latest connection interval T0), node306-1may open CE420for communication with node304-1before an expected time of communication t1. Node304-1may open CE410at the scheduled communication time according to the clock of node304-1. Node306-1may establish a synchronized time based on the arrival time of message412and/or other information, such as a connection event counter (maintained by node306-1or communicated with message412), connection event interval, time stamp, etc. Node306-1may be scheduled to subsequently open CE422-1for communication with node308-1. Node306-1may enforce a delay440(e.g., t2−t1) of a target duration to maintain the target spacing between connection events, e.g., enforcing delay440between reception by node306-1of message412from node304-1and opening of CE422-1for communication with node308-1(e.g., the time of transmission of message414). Node306-1may similarly enforce target time delays t3−t1, t3−t1for communications with other child nodes308-2and308-3. Each of nodes308-1,308-2, and308-3may have one or more upstream child nodes (not shown inFIG.3andFIG.4) and may similarly enforce time delays (and facilitate time synchronization) for the upstream child nodes using the same techniques as described above.

Wireless Network Data Latency Management

In some aspects of the present disclosure, a wireless network of nodes is configured to collect data at a central processing device from devices associated with the nodes of the network. Reducing data latency (e.g., decreasing the time it takes to aggregate and transmit data from the nodes of the network to the central processing device) may be advantageous. In a topology of wireless nodes, efficient placement in time of connections between nodes may be arranged to optimize flow of data to the central device. The placement of connections in time may reduce collisions between connections involving the same device, connections involving exclusively different devices, etc. Other arrangements, such as placing connections in time such that data flow (e.g., instructions) from a central node down a tree topology to the other nodes of the network are within the scope of this disclosure. In some embodiments, connections may be placed to avoid collisions and minimize data latency. Connections placement may enable data collection from all the nodes of a network each connection interval (e.g., in a BLE network). Efficient connection placement may also improve reliability and reduce power consumption.

FIG.5illustrates an example communication scheme500that optimizes downstream data flow in a wireless network, according to some implementations. In communication scheme500, connection events may be arranged by a control device (e.g., a root/central node). In some implementations, the root node or a device associated with the root node may be configured to aggregate data from many (or all) nodes of the wireless network, to perform analysis of the aggregated data, and so on. In some implementations, timing of connection events may be arranged to optimize data flow in a different direction (e.g., upstream), using analogous (e.g., inverted) communication scheme, compared to the communication scheme500.FIG.5illustrates connections between the same nodes304-1,306-1,308-1,308-2, and308-3as previously described in conjunction withFIG.3andFIG.4. Nodes308-1,308-2, and308-3may communicate with node306-1at times dictated by node306-1. In some implementations, node306-1receives and passes on to nodes308-1,308-2, and308-3instructions from node304-1with the timing (delays) of various connection events.

As depicted, at time t1, node306-1may open reception (RX) window of CE522-1to collect data from node308-1. Prior to collecting data, as part of RX window of CE522-1, node306-1may also provide instructions and other information to node308-1. Node308-1may open transmission (TX) window of CE530-1for communication with node306-1prior to time t1, as described above, in conjunction withFIG.3andFIG.4. After the data is communicated from node308-1to node306-1, node306-1may close CE522-1and may enter a period of silence, e.g., interval524-1, before opening the next CE522-2for communication with node308-2. Node308-2may similarly open CE530-2prior to the scheduled CE522-2and communicate data during an overlapping portion of CE522-2and CE530-2. After the data is communicated from node308-2to node306-1, node306-1may close CE522-2and enter a period of silence, e.g., interval524-2, before opening the CE522-3for communication with node308-3. The periods of silence may allow to accommodate widening of CE530-1and CE530-2. Node308-3may open CE530-2prior to the scheduled CE522-2and communicate data during an overlapping portion of CE522-3and CE530-3. The intervals524-1and524-2provide a degree of flexibility for nodes308-kto deploy window widening.

In some implementations, after closing CE522-3, node306-1may enter an aggregation window (AW)526during which node306-1may process data, rearrange data, discard some data, append additional data, aggregate data, package data, and so on. The aggregated and packaged data may then be transmitted to node304-1. For example, node304-1may open RW510to receive data from node306-1. Node306-1may open CE520and transmit data to node304-1.

In some implementations, all RX windows may have the same (first) duration and all TX windows may have the same (second) duration. In some implementations, to account for a possible accumulation of clock errors in consecutive layers of nodes, upstream reception windows may be made progressively wider with each layer of nodes.

The same process may be followed by other nodes of the wireless network. For example, node306-1may be one of multiple child nodes communicating with node304-1. Correspondingly, CE510may be a part of a sequence of CEs opened for multiple child nodes (node306-1being just one among those child nodes). Numerous other devices (not shown inFIG.5) may be present in the wireless network. Each of nodes (devices)308-1,308-2, and308-3may have additional child devices. Similarly, node304-1may have a parent node further downstream the wireless network. Using the same principles of arrangement of transmission and reception windows, data may flow through the entire network (including any number of nodes) over a single connection interval, with each node communicating data to a downstream node as soon as the data is ready (e.g., obtained and/or aggregated) for transmission.

In some implementations, communication scheme500may be used to transfer data from a number of source nodes to a number of destination nodes. Destination nodes may be configured to obtain information from the devices of the wireless network for further processing. In some implementations, a wireless topology may be optimized for information delivery in the opposite direction, e.g., away from a central node, in which case downstream and upstream designations may be reversed. For example, if the information delivery is optimized in the opposite direction (from root node to higher-level nodes), communication scheme500may still be used with the directions of arrows and the direction of time axis inFIG.5reversed

FIG.6is a further illustration of an example communication scheme500ofFIG.5that optimizes downstream data flow in a wireless network, according to some implementations. In addition to node306-1,FIG.6illustrates operation of another level-2 node306-2ofFIG.3and two child nodes308-4and308-5of node306-2. As illustrated inFIG.6, a communication between node308-4(node308-5) and node306-2may occur concurrently (with a complete or partial overlap) with the communication between node308-1(node308-2) and node306-1. After aggregating, during an AW528, the data collected from nodes308-4and308-5, node306may open TX window521for communication of the aggregated data to node304-1, which opens the corresponding RX window512. As illustrated inFIG.6, communications from nodes306-1and306-2to node304-1occur at different times, separated by a period of silence. As illustrated inFIG.6, communication between node306-2and node304-1may occur while node306-1is aggregating data (AW526).

The arrangement of communications illustrated inFIG.6improves efficiency of data collection allowing a shorter total connection interval while still ensuring that the data from multiple (or all) nodes is communicated concurrently while no two upstream nodes are communicating with the same downstream node at the same time. Analogous timing techniques may be applied to communication links between nodes of any levels and to topologies of an arbitrary size (e.g., to wireless network having n layers of nodes).

The timing of data communication illustrated inFIG.6is such that multiple communications between different pairs of nodes may occur simultaneously. In a variety of applications, the nodes of the wireless network may be located within a limited volume (e.g., a car battery or a medical sensing apparatus) and may interfere with each other's communications when the same communication frequencies are being used. Methods of frequency multiplexing may be used to address such situations and reduce the amount of interference, as described in more detail below.

Communication Interference Management

In one aspect of the present disclosure, interference of wireless communication between devices of a wireless network is managed. In some embodiments, connection events between nodes are placed to avoid collisions in time. In some embodiments, some connection events in a network may be placed at the same time. For example, communication between a first node of the network and a second node of the network may overlap in time with communication between a third node of the network and a fourth node of the network. Communication channels (e.g., wireless communication frequencies) may be allocated to avoid collisions in frequency. Communication channels may be allocated to avoid overlap in frequency with signals originating outside the wireless network, e.g., external interference.

FIG.7is an illustration of an example channel multiplexing scheme700that reduces interference during data communication in a wireless network of nodes, according to some implementations. The wireless network of nodes may have a number of available wireless communication channels (WCCs) to be assigned to different wireless links. For example, a Bluetooth Low Energy network may have 40 WCCs having width of 2 MHz each, with 37 WCCs available to communicate data and 3 WCCs used for advertising. In the channel multiplexing scheme700, links that are not used concurrently may utilize the same WCCs, as no interference is likely to occur. For example, since links701-1and701-2are used at different times (are time-multiplexed), links701-1and701-2may share the same WCCs for wireless communications. Similarly, any links that are numbered with the same first three digits (e.g., links703-1and703-2) may communicate using the same WCCs. On the other hand, as illustrated inFIG.6, some of links704-jmay be used concurrently with at least some of links705-j(706-j,707-j, etc.). Such links may be assigned different WCCs, to avoid or reduce interference.

In some implementations, a control device (e.g., node710or a device associated with node710) may transmit a communication schedule to various nodes of the network. The control device may generate a schedule that assigns both the communication (transmission and reception) windows to the nodes (as described in more detail above) and the WCCs to various wireless links between the nodes. For example, each link may be assigned a set of WCCs that may be utilized by that link. In some implementations, the links that operated concurrently may be assigned different WCCs whereas the links that operate at different times (e.g., links that communicate with the same downstream node) may be assigned the same set of WCCs. A set of WCCs may have one or more WCCs depending on the total number of nodes in the network, with one or two WCCs per link in the instances of a large number of nodes and several or more WCCs for smaller networks. In some implementations, each of the nth level nodes may be assigned a different set of WCCs, e.g., node740may be assigned a set {C}(0), node741may be assigned a set {C}1), and so on, with node74X assigned a set {C}(X).

Assigning multiple WCCs to a given link may improve resilience of that link to interference or noise, in case an outside wireless device begins to communicate using one of the assigned frequencies. Accordingly, in some implementations, some sets of WCCs may be partially or fully overlapped. For example, since links707-jmay be used at different times, some of the sets {C}(7), {C}(8), and {C}(9)may have common channels. In some implementations, sets {C}(7), {C}(8), and {C}(9)may be the same. Likewise, sets {C}(0), {C}(1), and {C}(2)may be the same but different from sets {C}(7), {C}(8), and {C}(9)(and other sets).

Downstream links may have a larger variety of assigned WCCs, by virtue of having fewer nodes in the downstream layers. For example, if link702-1is not used simultaneously with links704-j, link702-1may be assigned any WCCs of the union {C}(0)U{C}(1)U{C}(2)(including all WCCs of this union) whereas link702-2may be assigned any WCCs of the union {C}(3)U{C}(4). Moreover, if links702-1and702-2are not used simultaneously, each of links702-1and702-2may be assigned any (or all) WCCs of the larger union {C}9))U{C}(1)U{C}(2)U{C}(3)U{C}(4). Such assignment of WCCs may extend through all downstream nodes, with the root node710being assigned any (or all) WCCs from the union of all sets {C}(j).

In some implementations, for additional protection against noise and interference from interloping signals of an adjacent wireless communication channel (e.g., having close frequency) different sets of WCCs may be separated (spaced) by one or more unassigned WCCs. For example, in the wireless network shown inFIG.7, available WCCs C1. . . C37(assuming a BLE network, for concreteness) may be assigned as follows:C1. . . C8: links704-1,704-2, and704-3;C9and C10: unassigned;C11. . . C18: links705-1and705-2;C19and C20: unassigned;C21. . . C28: links706-1and706-2;C29: unassigned;C30. . . C37: links707-1and707-2.
As a result, any two pairs of nodes that may be in simultaneous communication are separated with at least one (and, often, two) unassigned spacer WCCs. The above assignment is exemplary as any other spaced assignment of WCCs may be used instead. For example, a number of WCCs assigned to wireless links may be lower while the number of unassigned spacer WCCs may be higher.

At different times, different WCCs may be selected for communication by a particular node, from a set of WCCs assigned to that node. Selection of WCCs may be performed by a parent node, e.g., node734may select a WCC from a set {C}(6)assigned to node746, by root node710, or by any other downstream node that is between node734and node710(e.g., node722). Selection of WCCs may be communicated in instructions transmitted by parent nodes, and may be effective starting from the next, or any subsequent, communication. Selection of WCCs may by dynamic, in some implementations, and may be based on the amount of measured external interference/noise. More specifically, some (or all) nodes of the network may be configured to detect potential interference, e.g., by detecting energy present within a particular frequency band, which may include the WCC currently being used by the node for communications. The metrics used to evaluate the quality of each specific link may include received signal strength indicator (RSSI), signal-to-noise ratio (SNR), which may be the RSSI of the link adjusted by the amount of noise detected in the channel, or any other acceptable metric.

In some implementations, a node in control of a wireless link (e.g., a parent node or root node710) may receive information from one or more nodes of the network and may remove a specific WCC (or multiple WCCs) from subsequent communications, at least temporarily, until the environment of the wireless network changes. For example, a node may send a message to the parent node indicating that a certain WCC or WCCs are experiencing interference, reduced RSSI/SNR, etc. The message can propagate through the network and reach a control device (e.g., root node710), which may then remove the corresponding WCC(s) from subsequent communications. The control device may then distribute updated WCC information all (or the affected) nodes of the wireless network. In some implementations, the control device may perform a complete reassignment of WCCs if certain channels are underperforming. For example, if 15 highest-frequency BLE channels C23. . . C37are consistently having low SNR over a period of time, the control device may reassign the remaining channels C1. . . C22among the nodes of the network and maintain the channels C23. . . C37unassigned, for the time being (e.g., until the SNR improves).

In some implementations, assignment of WCCs may be random, e.g., based on a pseudorandom sequence of communication frequencies. For example, N available WCCs C1. . . CN(e.g., supported by network hardware, free from interference, etc.) may be assigned based on a random (or pseudorandom) sequence of numbers 1 . . . N. In some implementations, each node may store the same pseudorandom function and may generate the WCCs to be used for communications, without waiting for instructions from the parent node. Each node may be assigned an offset, e.g., number M, into the pseudorandom sequence of WCCs 1 . . . N and may select a WCC for communication as Mth number in the generated sequence. Nodes that communicate concurrently may be given different offsets to ensure that communications of such nodes do not interfere. For example, nodes741and745may given different offsets whereas nodes741and742may be given different or the same offsets. As a result, a pre-assigned offsets serve as pointers into the pseudorandom sequence. Since the same pseudorandom sequence may be generated by all nodes, different pointers used by different nodes ensure that concurrently communication nodes do not use the same WCCs.

In some implementations, the offset of each node may be shifted by a time-dependent number, e.g. M(t)=(M+[t/τ]) mod N, where t may be discrete time epoch (such as a value of a connection event counter) and τ may be some quantization parameter (e.g., a duration of connection interval, or some other item); the function [x] being the integer part of argument x. In some implementations, the pseudorandom function may have time as an additional input, such that different pseudorandom sequences are generated at different times. In some implementations, the pseudorandom function used to determine assignment of WCCs may include both time and an offset as input parameters. In some implementations, the pseudorandom function may include, in lieu of the offset, an address of the respective node (or an address of the parent of the respective node). In some implementations, the WCCs assigned by a pseudorandom function may be non-contiguous WCCs with spacer channels excluded, as described above.

Methods of Wireless Communication Management

FIGS.8-10illustrate example methods800-1000of time synchronization, time-multiplexing, and frequency-multiplexing of wireless connection (and their possible variations) in wireless networks. Methods800-1000and/or each of their individual functions, routines, subroutines, or operations may be performed by one or more processing units (CPUs, field-programmable gate arrays or FPGA, application-specific integrated circuits or ASICs, finite state machines, and so on) and memory devices communicatively coupled to the processing units of parent device110, network device120, child device124ofFIG.1, or any devices/nodes illustrated or mentioned in conjunction withFIGS.2-7, or any combination thereof. In certain implementations, a single processing thread may perform each of methods800-1000. Alternatively, two or more processing threads may perform each of methods800-1000, each thread executing one or more individual functions, routines, subroutines, or operations of the methods. In an illustrative example, the processing threads implementing methods800-1000may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing methods800-1000may be executed asynchronously with respect to each other. Various operations of methods800-1000may be performed in a different order compared with the order shown inFIGS.8-10. Some operations of methods800-1000may be performed concurrently with other operations. Some operations can be optional.

FIGS.8A-Cdepict flow diagrams of example methods of time synchronization and synchronous actions in wireless networks.FIG.8Adepicts a flow diagram of an example method800A of synchronization of devices in a wireless network, according to some implementations. In a wireless network, devices may have separate internal clocks used to track the passage of time. In some wireless networks, using very accurate clocks may be impractical or prohibitively expensive. In some applications that involve simultaneous measurements or other actions, such as music playing, it may be advantageous to establish a synchronized time throughout the network. Method800A may be used to establish the synchronized time in networks that have an arbitrary number of devices. In some implementations, establishing the synchronized time may include adjusting clocks of various devices to be in alignment with a particular clock, such as a clock of a central or root node, a clock of a device associated with a specific node of the network, and so on.

At block801, a network device (e.g., device306-1inFIGS.3and4) may receive a first message (e.g., message412inFIG.4) from a parent network device (e.g., node304-1inFIG.3) via a first link of the wireless network (e.g., link310-2). In some implementations, the wireless network may be a Bluetooth or Bluetooth Low Energy network. The parent network device may be a device in control of the first link. The parent network device may send instructions dictating timing, communication frequency, etc., related to the first link, to the network device. The network device may follow the instructions of the parent network device. In some wireless networks, e.g., wireless mesh networks, parent and child designations may not be static, and roles of devices may change with time. Some wireless networks may be reconfigured into a different topology, e.g., in response to changing conditions or needs. Reconfiguring the network may be performed upon instructions transmitted by the root node or some other node of the network.

At block802, the network device (e.g., node306-1) establishes a first common indication of time with the parent device. The first common indication of time may be established in view of at least one of (i) a connection interval associated with the first message or (ii) a first clock value associated with the first message. The first clock value may be a time of arrival of the first message or a time stamp included in the message, e.g., a time stamp corresponding to the transmission or generation (according to the clock of the parent network device) of the first message. The network device may record the time of reception of the first message (according to the clock of the network device) and compare the time of reception to the time stamp to generate a common indication of time with the parent network device (e.g., recording the time difference, adjusting the clock of the network device, etc.). In some implementations, the time of arrival of the first message (rather than the content of the first message) may be used to establish the common indication of time. For example, the network device may be aware of the connection interval T0and may be configured to multiply the connection event counter by the connection interval (e.g., the amount of time separating connection events that occur between the network device and the parent network device) to determine an expected time of arrival of the first message. In some implementations, the connection interval may be communicated with the first message. In some implementations, the connection interval may have been previously conveyed to the network device, e.g., when the link with the parent network device was first established.

At block803, method800A may continue with the first network device communicating to a child network device (e.g., node308-1inFIGS.3and4) via a second link (e.g., link310-3inFIG.3) a second message (e.g., message414inFIG.4). The second message may cause the child network device to establish a second common indication of time with the network device. As a result, the common time may be propagated throughout (cascade through) the entire wireless network.

As depicted schematically with optional blocks804and805, the first and second common indications of times in the wireless network may subsequently be updated. In some implementations, indications may be updated periodically (e.g., once per connection interval), upon detection of a clock drift, in preparation for a synchronous action, etc. More specifically, at block804, the network device may receive a third message (e.g., message416inFIG.4) from the parent network device. The third message may be one of subsequent messages communicated by the parent network device and may have content that is similar to that of the first message (e.g., with the time stamps updated, if applicable). At block805, the first common indication of time may be updated in view of the third message. For example, a new difference between the expected time of arrival of the third message and the actual time of arrival of the third message (measured by the clock of the network device) may be recorded. The updated first common indication of time may then be used to cause the child network device to update the second common indication of time, e.g., by communicating a fourth message from the network device (e.g., node306-1) to the child network device (e.g., node308-1). Any number of child network devices (e.g., nodes308-2,308-3) may be synchronized similarly, e.g., by the network device repeating blocks803and805with communications directed to the respective child network devices.

FIG.8Bdepicts a flow diagram of an example method800B of using a common indication of time to open a communication window for communication with a parent network device, according to some implementations. Method800B may be performed by a network device that has at least two clocks, referred herein to as a device clock and a reference clock, respectively. At block811, a network device of a wireless network adjusts the reference clock based on a common indication of time with a parent network device. The reference clock may be a clock internal to the network device. The common indication of time may have been established using any of the implementations described in conjunction with method800A or similar implementations. At block812, the device clock may be advanced by a time offset relative to the reference clock. In some implementations, the time offset is predetermined to be larger than the typical drift of the clocks (e.g., of the reference clock and/or the device clock), to allow sufficient widening of a future communication window with the parent network device and not to miss the start of the future transmission by the parent network device. The typical drift may be known from field testing.

At block813, the device clock may be used to open a reception window to receive a message, which may be the same (or different) than the third message of method800A. The message may be sent by the parent network device. The reception window may be opened when the reading of the device matches an expected time of reception of the message (e.g., an expected start of the next communication window with the parent network device).

At block814, method800B may continue with the device clock being adjusted again, in view of the timing of reception of the message. For example, the device clock may be adjusted (e.g., by the network device hardware) based upon the timing of detection of an access code or header in the message. In some implementations, the device clock may be adjusted in view of a value of the connection event counter. For example, the connection event counter CEC may be incremented upon reception of the message or based on the passage of time that is equal or approximately equal to the connection interval T0since the last connection event. The device clock may be adjusted to be in alignment with the clock of the parent network device clock, which is assumed to have a value CEC×T0(plus an offset that is independent of CEC). The device clock may then be used to adjust the reference clock, as described above in conjunction with block811. Operations of blocks811-814may be repeated multiple times, e.g., for the duration of the communication connection between the network device and the parent network device.

In some implementations, the reference clock and the device clock may be the same clock. In such implementations, the advancement of the device clock may be performed virtually, by the software of the network device.

FIG.8Cdepicts a flow diagram of an example method800C of using the common indication of time for performance of a synchronous action, according to some implementations. In some implementations, method800C may be performed in conjunction with method800A described above. At block821, a first clock value may be recorded by a network device. For example the first clock value may be associated with a message received by the first network device, as described above in conjunction with block802of method800A. In some implementations, the first clock value may be associated with a time of reception of the message. In some implementations, the first clock value may have been included in the message sent by the parent network device.

At block822, a time stamp may be generated. In some implementations, the time stamp may indicate a time of a future event. In some implementations, the device clock of the network device may be updated to be aligned with the clock of the parent network device. In some implementations, a specified delay time may be added to the first clock value to generate the time stamp. The future event may be a future connection event, a future communication window, a future action to be performed (such as a synchronous measurement), etc. In some implementations, the delay may be specified by the parent network device or passed on from a central device of the network. In some implementations, a device different from the parent network device or the central device may specify the delay time included in the first message.

At block823, an action may be performed in association with the future event. e.g., a communication window is opened, a message is sent, a measurement is taken, and the like. The action may be performed when the value of the clock (e.g., a second clock value) matches (e.g., reaches or exceeds) the value of the time stamp (e.g., the time of receiving the first message plus the delay time). In some implementations, the action may be performed synchronously with other devices of the wireless network (e.g., child devices, parent devices, etc.).

FIG.9depicts a flow diagram of an example method900of structuring a data flow in a wireless network, according to some implementations. In some applications, the wireless network of devices may be optimized to efficiently pass data in a target direction. It should be understood, however, that each connection event (e.g., each connection event between any two devices) may have the capability of passing data in both directions, e.g., to facilitate aggregation of data at a central node and dissemination of instructions away from the central node. The direction of optimized data flow (from sources nodes to destination node(s)) is herein referred to as the downstream direction whereas the opposite direction is referred to as the upstream direction. The wireless network may have a plurality of source nodes, one or more destination nodes, and a plurality of intermediate nodes (which may be additionally arranged into one or more layers or levels of nodes), each of the plurality of intermediate nodes having a downstream node and a plurality of upstream nodes. An intermediate node may act as a parent node for some wireless links and as a child node for other wireless links. For example, referring back toFIG.3, intermediate node306-1may have downstream parent node304-1and upstream child nodes308-1,308-2, and308-3.

At block901, the intermediate node (e.g., node306-1) may receive, from each one of the plurality of upstream nodes (e.g., nodes308-1,308-2, and308-3), a corresponding upstream message of a plurality of upstream messages. Each upstream message may be received within a respective reception window of a plurality of reception windows (e.g., RX window of CE522-1, RX window of CE522-2, and RX window of CE522-3, as depicted inFIG.5).

As indicated with optional block902, method900may include opening each of the plurality of reception windows at a respective one of a plurality of reception time offsets. The time offsets may be determined relative to the time associated with a reception window of the downstream node. For example, time offsets associated with the start of each of RX window of CE522-1, RX window of CE522-2, and RX window of CE522-3(referring toFIG.5) may be determined relative to time t1, which may be associated with a previous reception window RX of CE509.

At block903, method900may continue with transmitting, by the intermediate node (e.g., node306-1) to the downstream node (e.g., node304-1), a downstream message generated using the plurality of upstream messages. For example, the intermediate node may aggregate the received data and include the aggregated data in the downstream message. The intermediate node may also include additional data (e.g., measurements taken by a device associated with the intermediate node) in the downstream message. The downstream message may be transmitted within a transmission window (e.g., TX window of CE520) that is subsequent to the plurality of reception windows (e.g., RX window of CE522-1, RX window of CE522-2, and RX window of CE522-3). In some implementations, the transmission window may open after a delay following the close of the last reception window (e.g., RX window of CE522-3) allowing the intermediate node to aggregate data during a data aggregation window (e.g., AW526). In some implementations, as depicted inFIG.5, the reception windows may be non-overlapping and have a fixed offset with respect to each other. In some implementations, the reception windows may be equally (evenly) spaced in time to within a predetermined accuracy, e.g., to the accuracy of a device clock, the accuracy mandated by an application supported by the wireless network, and so on. As illustrated inFIG.5, interval524-1may be the same (or approximately the same) as interval524-2.

Such connection event spacing may be propagated upstream throughout the entire wireless network. In some implementations, utilizing fixed offsets between connection events may enable communication timings to remain stable to optimize data flow and to accommodate and compensate for clock drift/jitter that occurs between time synchronization events (as described in conjunction withFIGS.8A-C). In some implementations, time synchronization may occur for each connection interval of downstream data transmission. In some implementations, time synchronization may be performed once every set number of connection intervals of downstream data transmission. In some implementations, data may flow throughout the entire wireless network in a single connection interval. For example, at the beginning of the connection interval, source nodes (e.g., nodes of nth level) may transmit data to nodes of the next, n-1th, level. Nodes of n-1th level may aggregate data and send aggregated data the next downstream level until the aggregated data reaches the destination node (e.g., the root node) near the end of the connection interval. The next connection interval may then begin.

In some implementations, the transmission window of a downstream connection event may be a part of a downstream connection event. For example, TX window of CE520is a part of CE520. Similarly, each of the plurality of reception windows may be a part of a corresponding upstream connection event of a plurality of upstream connection events (e.g., RX windows of CE522-1, CE522-2, and CE522-3, are parts of the corresponding CE522-1, CE522-2, and CE522-3, respectively). In some implementations, since the amount of accumulated and transmitted data may increase with each layer of nodes, the TX window is wider than a respective TX window of each of the plurality of upstream connection events (e.g., TX window of CE520is wider than TX windows of CE530-k). In some implementations, the transmission window may be a part of a downstream connection event (e.g., CE520) that also includes a downstream reception window (e.g., RX of CE520). Similarly, each reception window of the plurality of reception windows (e.g., RX of CE522-k) may be associated with a respective upstream connection event (e.g., CE530-k) that also includes a reception window (RX of CE530-k) that is wider than the downstream reception window (e.g., wider than RX of CE520).

In some implementations, as indicated with an optional block904, method900may include opening the downstream connection event (e.g., CE520) at a time that is advanced compared with an expected communication time (e.g., start of CE510). The expected communication time may be determined as a sum of i) a time associated with a previous connection event of the downstream node and ii) a downstream node connection interval (e.g., T0). In some implementations, a set time advancement may be applied for the duration of the wireless connection, until network settings are changed, and so on. Similar set time advancements may be applied to connection events managed by other devices, e.g., various upstream devices. For example, node308-1may start CE530-1in advance of CE522-1.

As indicated with an optional block905, method900may include receiving, during the transmission window (e.g., TW of CE520), instructions from the downstream node (e.g., node304-1) for the intermediate node and/or for one or more of the upstream nodes. The received instructions may be related to future actions, future communications, changes of the settings of the wireless network, and the like. Similarly, during the reception windows (such as RX window of CE522-1, RX window of CE522-2, and RX window of CE522-3) the intermediate node may transmit one or more messages to the upstream nodes (e.g., nodes308-1,308-2, and308-3), including passing on instructions previously received from the downstream node.

FIG.10depicts a flow diagram of an example method1000of managing communication channels in a wireless network, according to some implementations. The network of wireless devices may be organized into n layers of nodes, where number n may be any integer number greater than two. The wireless network can have devices arranged in a tree of nodes, e.g., a tree of nodes depicted inFIG.7. Method1000may be used to optimize multiple wireless communication links that may be scheduled to communicate data during overlapping time windows. Wireless links that occur simultaneously (e.g., that overlap in time) may avoid interference by utilizing different communication frequencies (e.g., wireless communication channels). Method1000may be used to assign different communication frequencies to such simultaneously communicating links. Nodes of the wireless network may be classified into nodes of the first layer (e.g., root node710inFIG.7), nodes of the second layer (e.g., nodes720and722inFIG.7), nodes of the third layer (e.g., nodes730-736inFIG.7), and so on, up to the nodes of the last, nth, layer (e.g., nodes740-749inFIG.7). Method1000may be performed by a processing logic of a control device of the wireless network, e.g., by node710, a device associated with node710, of any other suitable device.

At block1001, the processing logic performing method1000may identify (e.g., based on stored topology of the network) that a first node of the n-1th layer (e.g., node730) supports a first plurality of wireless links (e.g., links704-j) ascending to the first node of the n-1th layer and a first wireless link (e.g., link702-1) ascending from the first node of the n-1th layer to a first node of an n-2th layer (e.g., node720). In some implementations, the first node of the n-1th layer may be in control (e.g., may act as a parent device) of each of the first plurality of wireless links ascending to that node. In some implementations, the first node of the n-1th layer (e.g., node730) may receive instructions related to the utilization of the first wireless link (e.g., link702-1) from the first node of the n-2th layer of nodes (e.g., node720).

At block1002, the processing logic may assign to each of the first plurality of wireless links (e.g., links704-1,704-2, and704-3) a respective set of WCCs (e.g., sets {C}(0), {C}(1), and {C}(2), respectively) of a first plurality of sets of WCCs. In some implementations, all sets of the first plurality of sets of WCCs may be the same (e.g., each of {C}(0), {C}(1), and {C}(2)may have identical sets of channels). In some implementations, different sets of the first plurality of sets of WCCs may be overlapping (e.g., {C}(0)may share some but not all WCCs with {C}(1)and/or {C}(2)). In some implementations, the sets in the first plurality of sets of WCCs may be non-overlapping (e.g., no WCC enters more than one of {C}(0), {C}(1), and {C}(2)).

At block1003, the processing logic may identify that a second node of the n-1th layer of nodes (e.g., node732) supports a second plurality of wireless links (e.g., links705-j) ascending to the second node of the n-1th layer of nodes and a second wireless link (e.g., link702-1) ascending from the second node of the n-1th layer of nodes to the first node of the n-2th layer of nodes (e.g., node720).

At block1004, method1000may continue with the processing logic assigning to each of the second plurality of wireless links (e.g., links705-1and705-2) a respective set of WCCs (e.g., sets {C}(3)and {C}(4), respectively) of a second plurality of sets of WCCs. Similarly to the above-described first plurality of WCCs, the channels of the second plurality of WCCs may be non-overlapping, partially overlapping, or identical to each other. Furthermore, WCCs of the first plurality of sets of WCCs (e.g., sets {C}(0), {C}(1), and {C}(2)) may be non-overlapping with the second plurality of sets of WCCs. Various sets of WCCs may be spaced by one or more unused (unassigned) WCCs.

It should be understood that blocks1001-1004illustrate only a portion of operations related to the assignment of wireless links and that various other wireless links (e.g., all wireless links of the network) may be assigned similarly. For example, a third plurality of sets of WCCs (e.g., sets {C}(5)and {C}(6)) may be assigned to the wireless links706-jascending to a second node of the n-1th layer of nodes (e.g., node734), and so on. The references to “first,” “second,” etc., should be understood as identifiers only and do not presuppose any specific ranking of corresponding elements and components or an order of assignment of WCCs.

In some implementations, wireless links that are assigned identical sets of WCCs may be time-multiplexed, e.g., communications over such links may happen at different times, such as during non-overlapping communication (transmission and reception) windows. Wireless links that are used concurrently may be assigned sets of non-overlapping or partially-overlapping WCCs.

At block1005, the processing logic may assign to the first wireless link (e.g., link702-1) ascending from the first node of the n-1th layer to a first node of n-2th layer, a first combined set of WCCs. The first combined set of WCCs may include at least one WCC of the first plurality of sets of WCCs (e.g., sets {C}(0), {C}(1), and {C}(2)) and at least one WCC of the second plurality of sets of WCCs (e.g., sets {C}(3)and/or {C}(4)). In some implementations, the first combined set may include all sets (e.g., be a union) of the first plurality of sets of WCCs and the second plurality of sets of WCCs (e.g., the union of sets {C}(0). . . {C}(4)).

Similarly, the processing logic may assign the same first combined set to the second wireless link (e.g., link702-2) ascending from the second node of n-1th layer to a first node of n-2th layer. The processing logic may further assign additional combined sets of WCCs to other wireless links. For example, both a third wireless link (e.g., link703-1) ascending from a third node of n-1th layer (e.g., node734) to a second node of n-2th layer (e.g., node722) and a fourth wireless link (e.g., link703-2) ascending from the fourth node of n-1th layer (e.g., node736) to the second node of n-2th layer (e.g., node722) may be assigned a second combined set of WCCs (e.g., a union of sets {C}(5). . . {C}(9)).

The assignment of unions of sets of WCCs may be continued for downstream nodes as well. For example, a third wireless link may be ascending from the first node of the n-2th LN (e.g., node720) to a first node of an n-3th LN (e.g., node710) and a fourth wireless link may be ascending from the second node of the n-2th LN (e.g., node722) to the (same) first node of the n-3th LN. Accordingly, each of the third WL and the fourth WL may be assigned a union of the first combined set of WCCs (e.g., the combination of sets {C}(0). . . {C}(4)) and the second combined set of WCCs, (e.g., the combination of sets {C}(5). . . {C}(9)).

In some implementations, method1000may include, at optional block1006, obtaining information characterizing link quality of the first plurality of sets of WCCs. The obtained information may be based on various metrics for the respective WCCs (e.g., RSSI, SNR, and the like) and may indicate that some WCCs may be providing inadequate or suboptimal connectivity. Responsive to receiving such information, the processing device performing method1000may communicate, at block1007, instructions to the first node of the n-1th LN not to use one or more WCCs of the first plurality of sets of WCCs. Similar instructions may be communicated to various other upstream and downstream nodes assigned the same underperforming WCCs.

It should be understood that the above description is intended to be illustrative, and not restrictive. Many other implementation examples will be apparent to those of skill in the art upon reading and understanding the above description. Although the present disclosure describes specific examples, it will be recognized that the systems and methods of the present disclosure are not limited to the examples described herein, but may be practiced with modifications within the scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense. The scope of the present disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

The implementations of methods, hardware, software, firmware or code set forth above may be implemented via instructions or code stored on a machine-accessible, machine readable, computer accessible, or computer readable medium which are executable by a processing element. “Memory” includes any mechanism that provides (i.e., stores and/or transmits) information in a form readable by a machine, such as a computer or electronic system. For example, “memory” includes random-access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM); ROM; magnetic or optical storage medium; flash memory devices; electrical storage devices; optical storage devices; acoustical storage devices, and any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

Reference throughout this specification to “one implementation” or “an implementation” means that a particular feature, structure, or characteristic described in connection with the implementation is included in at least one implementation of the disclosure. Thus, the appearances of the phrases “in one implementation” or “in an implementation” in various places throughout this specification are not necessarily all referring to the same implementation. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more implementations.

In the foregoing specification, a detailed description has been given with reference to specific exemplary implementations. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. Furthermore, the foregoing use of implementation, implementation, and/or other exemplarily language does not necessarily refer to the same implementation or the same example, but may refer to different and distinct implementations, as well as potentially the same implementation.

The words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Moreover, use of the term “an implementation” or “one implementation” or “an implementation” or “one implementation” throughout is not intended to mean the same implementation or implementation unless described as such. Also, the terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and may not necessarily have an ordinal meaning according to their numerical designation.