Power saving for multi-connectivity wireless devices

Abstract

An apparatus (201) includes host logic (200) and a wireless controller (250). The wireless controller (250) includes a transceiver (258) and a scheduler (260). The scheduler (260) is configured to determine that a first device and a second device are to cluster together. In addition, upon occurrence of a communication event, the scheduler (260) is configured to wake up the transceiver (258) for a period of time to cause the transceiver to exchange packets with the first device and the second device, exchange packets with the first device, exchange packets with the second device, and power down the transceiver (258).

Description

Background Technology

[0001] Bluetooth Low Energy (BLE) is a protocol describing a wireless personal area network (PAN). On a BLE piconet (between two BLE devices), data transmission between a central node (also called the "master node") and peripheral devices (also called "slave nodes") occurs at periodic time intervals. A "connection event" is a data exchange between the central node and a single peripheral device. In some applications, the time anchoring of the first connection event instance is determined by the central node as part of the connection establishment procedure between the central node and the peripheral device. To conserve power, the BLE radio frequency (RF) transceivers of both the peripheral device and the central node device are powered off between two sequential connection events. In multi-connection applications, the RF transceivers are powered on again before the next expected connection event begins for the same central node / peripheral device connection or other connections. Summary of the Invention

[0002] In one example, a device includes host logic and a wireless controller. The wireless controller includes a transceiver and a scheduler (e.g., part of the link layer). The scheduler is configured to determine whether a first device and a second device should converge. Additionally, upon the occurrence of a communication event, the scheduler (or other hardware or software based on the scheduler's decisions) is configured to wake the transceiver for a period of time to allow the transceiver to exchange packets with the first and second devices, exchange packets with the first device, exchange packets with the second device, and power off the transceiver.

[0003] In another example, a method includes determining that a first device and a second device should converge together. Additionally, upon the occurrence of a communication event, the method includes waking the transceiver for a period of time to allow the transceiver to exchange packets with the first and second devices, exchange packets with the first device, exchange packets with the second device, and then powering off the transceiver. Attached Figure Description

[0004] For a detailed description of the various examples, reference will now be made to the accompanying drawings, in which: Figure 1 This describes a wireless network in which peripheral devices can be clustered together to communicate with a central node device.

[0005] Figure 2 An example implementation of a central node or peripheral device is shown.

[0006] Figure 3 This describes the sequence of stages during a single connection event between the peripheral device and the central node device.

[0007] Figure 4 Compare non-cluster scheduling and cluster scheduling.

[0008] Figure 5 An example method for communication between a central node and multiple peripheral devices is shown.

[0009] Figure 6 This describes multiple central node devices that are aggregated to the peripheral equipment.

[0010] Figure 7 This describes a method for aggregating multiple central nodes to peripheral devices.

[0011] Figure 8 This illustrates an example of a device that acts as both a peripheral device that serves as a central node and a central node for multiple peripheral devices. Detailed Implementation

[0012] If a central node is configured to exchange data with multiple peripheral devices, for each peripheral device, the central node powers on its RF transceiver, exchanges data packets with the specific peripheral device, and then powers off its RF transceiver. This process is repeated for each peripheral device that needs to communicate with the central node. In this way, the central node repeatedly powers on and off its RF transceiver. The process of powering on and off the transceiver consumes power. For example, to power on the transceiver, one or more software and hardware components are activated or woken up, and to power off the transceiver, the same software and hardware components are deactivated or turned off.

[0013] In one example, for communication purposes, a central node aggregates multiple peripheral devices and, for each BLE anchor, communicates with each peripheral device in the cluster during a back-to-back connection event. In one example, the peripheral devices as part of the cluster have the same connection interval. The central node powers on its RF transceiver before executing a connection event to the first peripheral device in the cluster and does not power on its RF transceiver until the connection event with the last peripheral device in the cluster is completed. This reduces the number of times the central node powers on and off its RF transceiver to communicate with a given set of peripheral devices compared to other cases where peripheral devices are not aggregated for back-to-back connection events, thus saving power. Power savings are advantageous in various applications such as battery-powered applications.

[0014] Figure 1A system 100 is described, comprising a central node device 110 and multiple peripheral devices 121, 122, 123, 124, and 125. Although five peripheral devices 121-125 are illustrated in this example, any number of peripheral devices may typically be included. In one example, each peripheral device is a sensor or includes sensors (e.g., a temperature sensor), and the central node device 110 can retrieve sensor values ​​from each such sensor. In one implementation, the central node 110 communicates with the peripheral devices 121-125 using the BLE protocol. According to the BLE protocol, anchor points are established by the central node 110 at discrete points in time (e.g., at periodic intervals). The interval between anchor points of a BLE connection is called a connection interval. During a connection interval, the central node device 110 may participate in connection events with the peripheral devices, or participate in multiple connection events if multiple peripheral devices are clustered together. For each cluster of peripheral devices, the central node turns its RF transceiver on and off once during each connection interval (e.g., for each anchor point).

[0015] Central node device 110 and peripheral devices 121-125 participate in the advertising process, enabling central node device 110 to determine which peripheral devices are present and within its wireless range. For example, each peripheral device 121-125 may transmit an advertising packet that may include the peripheral device's MAC address, an identifier of the service provided by the peripheral device, the peripheral device's name, and other information. When central node device 110 determines which peripheral devices 121-125 are present, it aggregates two or more of the peripheral devices. Any of a variety of aggregation techniques can be implemented, such as those described below. In each cluster in one example, the connection intervals of the peripheral devices are the same or similar (or an integer multiple of the common connection interval). Furthermore, the duration of a connection event for any given peripheral device within the cluster should be fixed; however, the duration of the connection event can be the same or different among the various peripheral devices in the cluster. As described below, the duration of a connection event for a given peripheral device can be known a priori, determined based on adaptive learning techniques, or enforced by the link-layer scheduler (so that it enforces connection event termination).

[0016] Figure 2An example implementation of hardware circuitry 201 applicable to one or both of central node device 110 or peripheral devices 121-125 is described. This implementation includes host logic 200 coupled to a wireless controller such as BLE controller 250. Host logic 200 includes one or more central processing units (CPUs) 202 coupled to or including memory 210. Memory 210 includes a profile 215, a cluster identifier 216, and host software 217. Host software 217 is executed by CPU 202 to enable the device to act as one or both of a central node or a peripheral device. Profile 215 and cluster identifier 216 are described below.

[0017] BLE controller 250 implements multi-layer logic, including host controller interface 252, link layer 254, and physical (PHY) layer 256. PHY layer 256 includes RF transceiver 258. Scheduler 260 is implemented within link layer 254 and executed by CPU 202. For devices used as central nodes, scheduler 260 determines which peripheral devices 121-125 will be aggregated and schedules them for back-to-back connection events.

[0018] Figure 3 An example of a single connection event between the central node device 110 and the peripheral device is shown. Figure 3 The example illustrates multiple phases of a connection event from the perspective of the central node device 110. Each phase occurs over a period of time as shown along the x-axis and is characterized by the average quiescent current during that phase, as shown along the y-axis. The connection event phases include a wake-up phase 301, a CPU activity / radio idle phase 302 (where CPU 202 is active but RF transceiver 258 is idle and the transceiver switches from receive mode to transmit mode), a receive phase 303, a CPU idle / radio ready phase 304 (where CPU 202 is active and RF transceiver 258 is ready), a transmit phase 305, and a power-off phase 306. A connection event may include a single pair of transmit and receive phases, or multiple pairs of transmit and receive phases. The total time for all phases 301-306 to occur is the duration of the connection event.

[0019] During wake-up phase 301, RF transceiver 258 transitions from sleep state to wake-up state. As described above, the wake-up phase includes, for example, activating and / or waking up one or more software and hardware components. In this example, the average quiescent current of wake-up phase 301 is approximately 3.2 mA, and its duration is approximately 1.2 ms. CPU activity / radio idle phase 302 is characterized by an average quiescent current of 3.3 mA and a duration of approximately 0.3 ms. Receive phase 303, CPU idle / radio phase 304, and transmit phase 305 are characterized by average quiescent currents / durations of approximately 6.5 mA / 0.3 ms, 4.5 mA / 0.1 ms, and 6.8 mA / 0.3 ms, respectively. During power-down phase 306, central node device 110 deactivates or powers down one or more software and hardware components and powers down its RF transceiver 258. The power-down phase has an average quiescent current of approximately 2.2 mA and a duration of approximately 0.5 ms.

[0020] During each phase 301-305, the energy consumption of the central node device 110 is a function of the product of quiescent current and time (i.e., the area under the curve for each phase). It can be seen that the combined energy consumption during the wake-up phase 301 and the power-down phase 306 is a significant portion of the total energy consumption across all phases (e.g., 40%-50% of the total energy consumption).

[0021] Figure 4 Compare non-cluster scheduling 410 and cluster scheduling 450. Figure 4 The diagram illustrates three peripheral devices 121, 122, and 123. For non-cluster scheduling 410, the central node device 110 establishes anchor points 411-416 as shown. The diagram illustrates the connection interval (CI). For each anchor point, the central node device 110 initiates a connection event for one of the peripheral devices. As shown in this example, the central node device initiates a connection event 421 for peripheral device 121 at anchor point 411. Then, the central node device initiates a connection event 422 for peripheral device 122 at the next anchor point 412, and a connection event 423 for peripheral device 123 at the next anchor point 413. This process is then repeated, i.e., the central node device 110 again initiates a connection event for each of the three peripheral devices at anchor point 414 (connection event 424 for peripheral device 121), anchor point 415 (connection event 425 for peripheral device 122), and anchor point 416 (connection event 426 for peripheral device 123). For Figure 4 In each of the six connection events 421-426 shown, the central node device 110 executes the wake-up phase 301 and the power-down phase 306.

[0022] By utilizing cluster scheduling (shown at 450), the central node device 110 aggregates three peripheral devices 121-123 together and initiates back-to-back connection events with all three aggregated peripheral devices 121-123 for each anchor point 451 and 452. At anchor point 451, the central node device 110 performs a wake-up phase 301, followed by a set of three CPU activity / radio idle phases 302, a receive phase 303, a CPU activity / radio ready phase 304, and a transmit phase 305, as indicated by 461, 462, and 463, respectively, for each of the three peripheral devices 121. After the transmit phase of the connection event with the last peripheral device in the communication sequence (i.e., peripheral device 123 in this example), the central node 110 performs a power-down phase 306. This process is repeated at the next anchor point 452. In this way, for each anchor point, multiple (three in this example) peripheral devices exchange data with the central node, and the central node does not repeatedly power on and off its RF transceiver to communicate with each peripheral device. Instead, the central node device 110 performs a wake-up phase 301 and a power-off phase 306 while communicating with multiple peripheral devices. The connection interval (CI) is longer in the case of cluster scheduling to allow the central node device 110 more time to communicate with multiple peripheral devices.

[0023] In the example of non-cluster scheduling 410, the central node device 110 performs six wake-up phases 301 and six power-down phases 306 to communicate twice with each of the three peripheral devices 121-123. However, in the example of cluster scheduling 450, the central node device 110 performs only two wake-up phases 301 and two power-down phases 306 to communicate twice with each of the three peripheral devices 121-123. Because fewer wake-up and power-down phases are required when peripheral devices are clustered, it is advantageous for the central node 110 to consume less power.

[0024] As described above, the scheduler 260 of the central node device 110 ( Figure 2The process employs any of several different aggregation techniques. In one example, peripheral devices with fixed connection event durations and connection intervals are aggregated. The memory 210 of the host logic 200 of the central node device 110 may store one or more device profiles 215 (e.g., since peripheral devices advertise their respective profiles to the central node device), and profile 215 may be associated with each peripheral device. In one example, the peripheral device profile includes the peripheral device's connection event duration and connection interval. The connection event duration is a value representing the time required for the central node and peripheral devices to transfer data to each other. In another example, device profiles may be provided to the central node 110 from an external shared database. Therefore, peripheral devices associated with the same profile 215 may be aggregated together (i.e., peripheral devices that typically have the same connection interval (or an integer multiple thereof) and connection event duration).

[0025] In another example, the central node device 110 can perform adaptive learning techniques to determine which peripheral devices should be clustered together. For example, in a sensor network (where the peripheral devices are sensors or have sensors), two or more peripheral devices may transmit the same amount of data during each connection event, and therefore the duration of the connection events is approximately the same. Peripheral devices with connection events of fixed but different durations can be clustered together. The central node device 110 can maintain a historical log of the connection event durations of the peripheral devices and then cluster those peripheral devices with approximately the same connection event duration and connection interval (or an integer multiple thereof) together. In another example, the central node device 110 obtains the connection event durations of the peripheral devices from a shared database.

[0026] Figure 5 A method for communication between multiple peripheral devices and a central node device is described. At 501, as described above, the central node device 110 determines, for example, via its CPU 202 of its execution scheduler 260 which peripheral devices will be clustered. The central node device 110 may store the identifiers (e.g., MAC addresses) of those peripheral devices to be clustered in the memory 210 of the central node device's host logic 200. The cluster identifier is in... Figure 2 It is displayed as cluster identifier 216.

[0027] As determined at 502, when it is time for the next anchor point, at 503, the method includes initiating connection events to peripheral devices in the peripheral device cluster. At 504, the method determines whether there is another peripheral device in the cluster that has not yet initiated a connection event for the current anchor point. If another peripheral device exists, the control loop returns to operation 503, and the connection event for the peripheral device is executed. If connection events to all peripheral devices in the cluster have been executed, the control loop returns to 502, and the central node device 110 waits for the next anchor point.

[0028] The central node device can make a decision about which peripheral devices to cluster during its initialization, and if the clustering information is known (pre-configured), it can make this decision as part of the connection establishment phase, or periodically during the central node device's runtime (if the clustering information is known and / or used for adaptive learning). If one or more additional peripheral devices are added to (or removed from) the network after the initial clustering decision is made, the central node device 110 can update its clustering decision to accommodate and include the additional peripheral devices (or remove the peripheral devices). In one example, if the connection for a given peripheral device terminates (e.g., the central node device no longer needs to communicate with that particular peripheral device), the central node device can change the anchor point to one or more remaining peripheral devices in the cluster to maintain the remaining peripheral devices with back-to-back connections in the cluster.

[0029] According to the BLE protocol, the central node device sets an initial anchor point relative to its subordinate peripheral devices, but either the central node device or a peripheral device can initiate a change in the timing of the anchor point. For example, changing the anchor point might involve the central node device's link layer sending a BLE LL_CONNECTION_PARAM_REQ_PDU to the peripheral device. The LL_CONNECTION_PARAM_REQ_PDU includes parameters that can be set by the central node device to specify the change in the anchor point's timing. In response, the peripheral device can (a) reject the parameter change request using LL_REJECT_EXT_IND_PDU if the requested parameters are incompatible with the peripheral device's operation, or (b) accept the newly proposed anchor point parameters using LL_CONNECTION_PARAM_RSP_PDU. Similarly, a peripheral device can send an LL_CONNECTION_PARAM_REQ_PDU to the central node device to request a change in the anchor point's timing, and the central node device can accept or reject the requested change.

[0030] exist Figure 1 In the diagram, the wireless network is illustrated as including multiple peripheral devices 121-125 connected to a public central node device 110. Figure 6 An example of a peripheral device 620 with connections to multiple (two in this example) central node devices 610 and 612 is shown. Of course, each of the central nodes 610, 612 can also have connections to additional peripheral devices. Because the peripheral device 620 acts as a peripheral to two distinct central node devices 610, 612, there is an opportunity to save power by clustering the central node devices together through communication relative to the central node devices 610, 612 and their common peripheral device 620. In one example, the peripheral device 620 requests one of the central nodes 610, 612 to change its anchor point to the peripheral device, such that both central nodes will participate in a back-to-back connection event with the common peripheral device 620. For the clustered central node devices, the peripheral device wakes up its RF transceiver 258 (and activates / powers on any other software or hardware required for the connection event) at the start of the first connection event from one of the central node devices, and does not power down its RF transceiver between connection events of the two central nodes. Instead, the peripheral device 620 remains powered on until the last connection event (e.g., ...). Figure 6 In the example, the RF transceiver is powered off only after the second connection is completed. This saves power by not powering off the RF transceiver of the peripheral device between connection events with the two central node devices 610 and 612 and then backing it up.

[0031] According to the BLE protocol, a peripheral device can request a central node device to change its anchor point for that peripheral device. The BLE protocol allows for a connection parameter update procedure, through which one or more parameters regarding the connection between devices can be updated. One of the updatable parameters is the time when the anchor point occurred. As part of the connection update procedure, the peripheral device can request the central node to change the anchor point time to a different time value specified by the peripheral device in the request. The central node device can accept or reject the request to change the anchor point. If the central node device rejects the request from peripheral device 620, central node devices 610 and 612 are not aggregated together (i.e., their connection events to the peripheral device are not performed back-to-back). However, if the central node device accepts the request, the central node device changes its anchor point for peripheral device 620, and the connection events from central node devices 610 and 612 to peripheral device 620 are performed back-to-back.

[0032] Figure 7 An example is given of the logic executed by peripheral device 620 to attempt to bring together central node devices 610 and 620. Figure 7The logic also applies to a central node device that wants to move the anchor point of a peripheral device to better facilitate aggregation with one or more other peripheral devices. At block 702, a new connection is established between the peripheral device (e.g., peripheral device 620) and the central node (e.g., one of central nodes 610 or 612). This connection is established with an anchor point for the new central node device. The peripheral device may already have a connection to another central node device or may not yet have one. At decision 704, the peripheral device (using scheduler 260 in its link layer 254) determines whether the peripheral device already has a connection to another central node. If the answer is "no," the connection established in block 702 is the only connection the peripheral device has to the central node, power savings from the aggregation central node device are unavailable, and the process stops at 706. As described above, the peripheral device then responds to connection events from the central node device.

[0033] If the answer to decision 704 is "yes," then the connection established at box 702 is not the only connection from the peripheral device to the central node device, and therefore it is possible that the central node devices can be clustered together. At decision 708, the peripheral device (using its scheduler 260) determines whether the existing central node device and the new central node device can be clustered together. This determination depends on whether the connection interval between the peripheral device and its existing central node device and the connection interval between the peripheral device and the new central node device are the same or an integer multiple thereof, and whether the duration of the connection events is the same. If the connection intervals are the same or an integer multiple thereof, and if the duration of the connection events is determined to be the same, the peripheral device determines that the new central node device should be clustered with the existing central node device. If the answer is "no," the process stops at 710, and the peripheral device responds to non-clustered connection events from all central node devices it is connected to.

[0034] If the answer to 708 is "yes", the peripheral device (using scheduler 260) initiates a connection parameter update request (box 712) to the new central node device (i.e., the central node with the most recent connection established in box 702). The connection parameter update request includes the proposed value for the new anchor point. Alternatively, a connection parameter update request can be initiated to an existing central node.

[0035] The central node device receiving a connection parameter update request can accept or reject the request. The request may be rejected because, for example, the newly proposed anchor point might coincide with an anchor point the central node device already has with another peripheral device. If the request is rejected (decision 714), the process stops at 716, and the central node device is not aggregated relative to the common peripheral device. The central node device may return a rejection packet to the peripheral device. However, if the connection parameter update request is accepted, the central node accepts the request by changing the anchor point and communicating or acknowledging the change to the peripheral device (box 718). In this case, the central node device may return an acceptance packet to the peripheral device. At this point, the central node is aggregated and a back-to-back connection event to the common peripheral device is performed, resulting in power savings for the peripheral device.

[0036] Figure 8 The network of devices 802-812 is described. Any device can act as a peripheral device, a central node device, or both. The roles performed by the device are implemented through the device's host logic 200 and BLE controller 250. Acting as both a peripheral device and a central node device (i.e., a multi-role device) means that the device acts as a peripheral device of another central node device and as a central node device of one or more other peripheral devices. For example, device 802 acts as a central node device, while devices 808, 810, and 812 act as peripheral devices of device 802. Device 812 also acts as a central node device of devices 804 and 806 (which themselves act as peripheral devices). Typically, a device can be a multi-role device in which multiple peripheral devices (acting as central node devices) and multiple central node devices (acting as peripheral devices) are connected. The aggregation techniques described herein can be implemented on any device, regardless of whether the device is a central node device only, a peripheral node device only, or capable of acting as either a central node device or a peripheral device. Furthermore, any given multi-role device can be a member of more than one cluster simultaneously. For example, a device can be a member of a cluster of peripheral devices (for a central node device), and can also be a member of a cluster of multiple central node devices.

[0037] The term "coupled" is used throughout this specification. This term can encompass a connection, communication, or signal path that achieves a functional relationship consistent with this specification. For example, if device A generates a signal to control device B to perform an action, in the first example, device A is coupled to device B. Or, in the second example, if intermediate component C substantially does not alter the functional relationship between device A and device B, device A is coupled to device B via intermediate component C, such that device B is controlled by control signals generated by device A.

[0038] Within the scope of the claims, modifications can be made to the described embodiments, and other embodiments are also possible.

Claims

1. An electronic device comprising: Host logic; and A controller coupled to the host logic, the controller including a transceiver, the controller being configured to: Identify the equipment cluster that includes the first and second devices; The transceiver is awakened for a first time period. In the first communication event within the first time period, the transceiver exchanges a first packet with the first device; In the second communication event within the first time period, the transceiver exchanges a second packet with the second device; At the end of the first time period, the transceiver is powered off. The device cluster is modified to include at least one of the first device, the second device, and the third device; as well as The transceiver is woken up for a second time period, during which it exchanges packets with each device in the modified cluster, and then the transceiver is powered off at the end of the second time period.

2. The electronic device of claim 1, wherein the controller is configured to determine the device cluster based on the first device and the second device having the same profile, the profile including connection event duration and connection interval.

3. The electronic device of claim 1, wherein the controller is configured to apply adaptive learning techniques to determine the device cluster.

4. The electronic device of claim 1, wherein the controller is a Bluetooth Low Energy controller, and wherein the first communication event and the second communication event are performed for each anchor point.

5. The electronic device according to claim 1, wherein the electronic device is a central node.

6. The electronic device of claim 1, wherein the electronic device is a peripheral node.

7. The electronic device according to claim 1, wherein the first device and the second device have the same connection interval.

8. The electronic device of claim 1, wherein the connection intervals for the first device and the second device are each an integer multiple of the common connection interval.

9. The electronic device of claim 1, wherein the controller is configured to remove the first device and the second device from the device cluster.

10. The electronic device of claim 1, wherein the duration of the first communication event is predetermined.

11. The electronic device of claim 1, wherein the controller is configured to send a request to the first device to change the anchor point of the first communication event.

12. A method for communication, comprising: Identify the equipment cluster that includes the first and second devices; Wake up the transceiver, wherein the transceiver is in a wake-up state for a first duration, the first duration including the time of the first connection event and the time of the second connection event; In the first connection event, exchange a first packet with the first device; In the second connection event, exchange a second packet with the second device; At the end of the first duration, the transceiver is powered off; After powering down the transceiver, the device cluster is modified to include a third device; as well as In the third connection event, a third packet is exchanged with the third device, wherein the time of the third connection event is included in the second duration during which the transceiver is in a wake-up state.

13. The method of claim 12, wherein determining the device cluster is based on the first device and the second device having the same configuration file.

14. The method of claim 12, further comprising performing adaptive learning techniques to determine the device cluster.

15. The method of claim 12, wherein the first connection event and the second connection event are performed for each Bluetooth Low Energy anchor, i.e., a BLE anchor.

16. The method of claim 12, further comprising receiving a request from the first device to change the first BLE anchor point.

17. The method of claim 12, wherein the first device is a central node.

18. The method of claim 17, wherein the second device is another central node.

19. The method of claim 12, wherein the first device is a peripheral device.

20. The method of claim 12, wherein the first device and the second device have the same connection interval.

21. The method of claim 12, wherein the connection intervals for the first device and the second device are each an integer multiple of the common connection interval.

22. The method of claim 12, further comprising removing the first device or the second device from the device cluster after the first duration.

23. The method of claim 12, further comprising sending a request to the first device to change the anchor point of the first connection event.

Images