Frequency change during connection event

Abstract

The method includes sending, by a first node to a second node during a first connection event (410), a request (430) to change a current operating frequency, the request (430) being encoded at a first operating frequency (420). The method also includes sending, by the first node to the second node during the first connection event (410), a first packet (452) encoded at a second operating frequency (450), the second operating frequency (450) being different from the first operating frequency (420).

Description

Background Art

[0001] When two devices transfer data via a Bluetooth Low Energy (BLE) communication channel, a BLE connection event occurs. During a first connection event at a predefined operating frequency / channel, a central node sends a first packet to a peripheral node. After receiving the first packet, the peripheral node sends a second packet to the central node. The first connection event continues the alternating transfer between the two nodes until the device stops the first connection event, there is no more data to be transferred by these two nodes, or the longest duration of the connection event has elapsed. After the end of the first connection event, the nodes can start communicating again during a second connection event at a different predefined operating frequency / channel.

Summary of the Invention

[0002] In some examples, a method includes sending, by a first node to a second node during a first connection event, a request to change the current operating frequency, the request being encoded at a first operating frequency. The method also includes sending, by the first node to the second node during the first connection event, a first packet encoded at a second operating frequency, the second operating frequency being different from the first operating frequency.

[0003] In a further example, a device includes a transceiver circuit element and a processing circuit element. The processing circuit element is configured to generate a request to change the current operating frequency during a first connection event. The processing circuit element is also configured to send, to the transceiver circuit element, a request encoded at a first operating frequency. The processing circuit element is further configured to generate a first packet after sending the request to the transceiver circuit element. The processing circuit element is still further configured to cause the transceiver circuit element to send a first packet encoded at a second operating frequency during the first connection event, the second operating frequency being different from the first operating frequency.

[0004] In yet another example, a non-transitory computer-readable medium storing executable instructions is configured to be executable by a processing circuit element to cause the processing circuit element to generate a request to change a current operating frequency during a first connection event. Further, when these instructions are executed, the processing circuit element is caused to send a request encoded at a first operating frequency. When these instructions are executed, the processing circuit element is further caused to send a request encoded at the first operating frequency to a transceiver circuit element. Also, when these instructions are executed, the processing circuit element is further caused to generate a first packet after sending the request to the transceiver circuit element. Also, when these instructions are executed, during a first connection event, the transceiver circuit element is caused to send a first packet encoded at a second operating frequency, where the second operating frequency is different from the first operating frequency.

Brief Description of the Drawings

[0005] The following detailed description and the accompanying drawings illustrate the features of the present invention.

[0006]

Figure 1

[0007]

Figure 2

[0008]

Figure 3

[0009]

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

[0010]

Figure 9

Figure 10

[0011]

Figure 11

Figure 12

[0012]

Figure 13

Mode for Carrying Out the Invention

[0013] Specific examples will be described in detail below with reference to the accompanying drawings. These examples are not limiting, and unless otherwise specified, no feature is required for any particular example.

[0014] Two electronic devices may communicate with each other using a technical standard that provides connection events involved in packet exchange between the devices. Packet exchange between devices during a single connection event may occur at a single predefined operating frequency / channel. In other words, according to this technical standard, each device may encode packets at a single operating frequency without switching to another operating frequency during the duration of the connection event.

[0015] If a node experiences interference, noise, or jamming at a certain operating frequency during a connection event, any retransmission of packets will occur at the same operating frequency. The interfering source may interfere with a number of frequencies less than all of the available operating frequencies (e.g., frequency selective fading), but the other available operating frequencies are not interfered with. According to this technical standard, the node communicates at the same operating frequency throughout the connection event even when facing high loss rates and retransmission rates. Therefore, since the node cannot hop to another operating frequency before the connection event ends, the performance of the node may deteriorate.

[0016] In the technology described herein, one of the nodes may issue a request to switch to a new operating frequency before the current connection event ends. By migrating to another operating frequency, the node may avoid interference in one channel by quickly migrating to another operating frequency. A fast switch to another operating frequency may improve throughput, increase resistance to interference and jamming, and reduce latency and response time. Of course, these advantages are merely examples and no advantages are required for any particular example.

[0017] An example of frequency switching during a connection event will be described with reference to the following figures. In this regard, FIG. 1 is a conceptual block diagram of a central node 110 communicating with a peripheral node 150 in accordance with some aspects of this description. System 100 includes a central node 110 and a peripheral node 150, and each node includes an antenna 120 or 160, a transceiver circuit element 130 or 170, and a processing circuit element 140 or 180. The central node 110 and the peripheral node 150 are communicatively coupled via wireless communication such as a short-range technology standard (e.g., Bluetooth Low Energy (BLE) specified by the Bluetooth Special Interest Group). Additional exemplary details of BLE can be found in commonly assigned U.S. Patent Application Publication No. 2020 / 0187010, filed on Dec. 11, 2018, titled "Secure Localization in a Wireless Network", and U.S. Patent No. 10,225,873, filed on Feb. 18, 2016 and issued on Mar. 5, 2019, titled "System and Method for Peripheral Initiated Host Arbitration", each of which is incorporated herein by reference in its entirety. [Patent Document 1] U.S. Patent Application Publication No. 2020 / 0187010 [Patent Document 1] U.S. Patent No. 10,225,873

[0018] In at least some examples, the processing circuit element 140 constructs a packet for transmission to the peripheral node 150. The processing circuit element 140 may be configured to construct the packet to include a header, a payload, and an error correction code. The processing circuit element 140 then causes the transceiver circuit element 130 to transmit the packet to the peripheral node 150 via the antenna 120. The transceiver circuit element 130 and / or the processing circuit element 140 may be configured to encode the packet at an operating frequency based on a predefined set of operating frequencies (i.e., a channel set). In an example of BLE communication, the transceiver circuit element 130 and / or the processing circuit element 140 may be configured to encode the packet by modulating a carrier signal using phase PSK such as differential shift keying (PSK).

[0019] The peripheral node 150 tunes to a predefined operating frequency to receive the packet at the antenna 160, and the transceiver circuit element 170 filters and / or amplifies the signal encoding the packet. The transceiver circuit element 170 and / or the processing circuit element 180 may be configured to decode the signal encoding the packet and store data in the packet. The transceiver circuit element 170 and / or the processing circuit element 180 may be configured to perform the same steps as the transceiver circuit element 130 and / or the processing circuit element 140 in the generation and transmission of the packet. The same general steps may be undertaken by the processing circuit elements 140 and 180 and the transceiver circuit elements 130 and 170 to generate and transmit the requests described herein. As an example, the link layer or radio access control in the processing circuit element 140 or 180 may be configured to generate a request to change the current operating frequency for transmission by the transceiver circuit element 130 or 170. The frequency change request may be transparent to the host and to the application running at the node 110 or 150. The frequency change request may be issued by the processing circuit element 140 or 180 in response to a short channel or long channel quality assessment.

[0020] Nodes 110 and 150 can be communicatively coupled via a wireless channel at a predefined operating frequency, and nodes 110 and 150 can change their operating frequency at the start of each connection event. Nodes 110 and 150 can exchange packets with encoded data at the operating frequency during the connection event. In an example of BLE communication, the central node 110 can be configured to initiate each connection event by sending a packet to the peripheral node 150. The connection event can continue while nodes 110 and 150 exchange packets until the connection event ends. When nodes 110 and 150 reach the end of the duration of the connection event, nodes 110 and 150 can stop exchanging packets and can initiate the next connection event at a predefined time. Alternatively, nodes 110 and 150 can also voluntarily stop exchanging packets before the connection event ends. After this early stop, nodes 110 and 150 can be configured to refrain from communicating for the remaining duration of the connection event until nodes 110 and 150 initiate the next connection event.

[0021] Figure 2 is a timing chart 200 of two connection events 210 and 220. Connection event 210 starts at time 230 and ends at time 232 at a predefined operating frequency, while connection event 220 starts at time 232 and ends at time 234 at a different predefined operating frequency. Each of connection events 210 and 220 can have a duration known as a connection interval, which can be a preset duration. In some examples, each connection event can have a variable duration limited by a maximum allowable duration.

[0022] During connection event 210, the central node and the peripheral node exchange packets 212 - 217. During connection event 220, the central node and the peripheral node exchange packets 222 - 227. In some examples, the duration of each packet (e.g., the time from the start of packet 212 to the start of packet 213) is about 150 microseconds.

[0023] In the example shown in timing chart 200, the central node and the peripheral nodes alternate between transmitting and receiving. For example, during connection event 210, the transmission of packets 212, 214, and 216 by the central node is interleaved with the transmission of packets 213, 215, and 217 by the peripheral nodes. During connection event 220, the transmission of packets 222, 224, and 226 by the central node is interleaved with the transmission of packets 223, 225, and 227 by the peripheral nodes. The central node starts both connection events 210 and 220 by transmitting packets 212 and 222, but the peripheral nodes can be configured to start a connection event by transmitting a packet.

[0024] In some examples, the central node and the peripheral nodes can exchange packets 212 - 217 within a first operating frequency and can exchange packets 222 - 227 within a second operating frequency different from the first operating frequency. The central node and the peripheral nodes can be configured to select an operating frequency for each connection event based on a predefined channel set and / or by negotiating a new operating frequency. The predefined channel set can be an ordered list of channels that the nodes use for a new connection event. In the example of BLE, there are up to 40 channels (such as potential operating frequencies), and the center spacing is 2 megahertz. Additional exemplary details of BLE can be found in version 5.3 of the Bluetooth Core Specification published on July 13, 2021, which is hereby incorporated by reference in its entirety.

[0025] FIG. 3 is a timing chart 300 of four connection events 310, 320, 330, and 340, and the node receives noise between these connection events. In some examples, the exchange of packets between each connection event 310, 320, 330, and 340 occurs at different operating frequencies. The node may exchange packets at a first operating frequency during connection event 310, and the node may exchange packets at a second operating frequency different from the first operating frequency during connection event 320. Also, the node may exchange packets at a third operating frequency different from the first and second operating frequencies during connection event 330. The node may exchange packets at a fourth operating frequency different from the first, second, and third operating frequencies during connection event 340. During connection event 330, the peripheral node does not receive transmissions from the central node, for example, due to noise or interference. During connection event 330, the operating frequency used for communication is subject to this noise or interference, while other available operating frequencies may be relatively noise-free. If the node is not configured to change the operating frequency within connection event 330, the node may need to wait until connection event 340 where normal operating frequency transitions occur.

[0026] This situation is shown in timing chart 300, and the peripheral node waits during a waiting time 360 until the start of connection event 340. The peripheral node does not receive the packet transmitted by the central node at the start of connection event 330. As a result, the peripheral node does not transmit a packet to the central node during connection event 330. Instead, the peripheral node waits until the start of connection event 340 where the central node transmits a packet encoded at a new operating frequency. The node implements this retry mechanism by waiting to attempt communication at the start of connection event 340 on either the channel used in connection event 330 or a different channel. During the waiting period shown as waiting time 360 in FIG. 3, the node does not communicate.

[0027] Returning to the beginning of the timing chart 300, connection event 310 starts at time 352 and ends at time 354, connection event 320 starts at time 354 and ends at time 356, connection event 330 starts at time 356 and ends at time 358, and connection event 340 starts at time 358. The central node and the peripheral nodes exchange two packets during connection event 310, six packets during connection event 320, one packet during connection event 330, and two packets during connection event 340. In the example shown in the timing chart 300, the central node starts each connection event by transmitting. Some technical specifications may establish that the central node starts communication during each connection event and may permit the peripheral node to start communication in some situations.

[0028] Each of connection events 310, 320, 330, and 340 includes a set of peaks and valleys, where each peak represents a transmission by the central node and each valley represents a transmission by the peripheral node. The timing chart 300 shows alternating transmissions by each node, but in some examples, a node may be configured to transmit two consecutive packets without another node transmitting intervening packets.

[0029] This technical specification may support early termination of each connection event. That is, either node may stop packet exchange in connection events 310, 320, 330, and 340, after which communication ceases until the start of the next connection event. For example, the timing chart 300 shows a sub-interval of interrupted communication in connection event 310 after the node has exchanged two packets. This technical specification may require that the duration of each of connection events 310, 320, 330, and 340 be of fixed length or less than a preset maximum length.

[0030] Figures 4 to 8 are timing charts 400, 500, 600, 700, and 800 that include requests for changing the operating frequency between connection events, according to some aspects of the present description. Each timing chart 400, 500, 600, 700, and 800 shows the exchange of packets encoded at two different operating frequencies during a single connection event. In each timing chart 400, 500, 600, 700, and 800, a node issues a request to change the operating frequency, and the node transitions to a new operating frequency within the connection event.

[0031] Timing chart 400 shows the communication between a central node and a peripheral node during connection event 410. During connection event 410, the nodes exchange packets 422 - 427 encoded at operating frequency 420. During this exchange, the central node sends packet 426 to the peripheral node along with a request 430 to change the operating frequency. The peripheral node then sends packet 427 to the central node along with a response 432 to request 430. Request 430 and / or response 432 may include data such as a new operating frequency for communication (e.g., operating frequency 450), and / or a time to switch, transition, or migrate to the new operating frequency (e.g., transition timing 440).

[0032] After the peripheral node sends packet 427, the nodes perform a transition 440 from operating frequency 420 to operating frequency 450. Transition 440 occurs when the central node does not send any more packets after request 430 and the peripheral node does not send any more packets after response 432. After the nodes perform transition 440, the central node sends packet 452 to the peripheral node. The nodes exchange packets 452 - 459 encoded at operating frequency 450 after transition 440. The exchange of packets 452 - 459 occurs after the transition 440 to operating frequency 450 but before the end of connection event 410. Thus, the nodes exchange packets 422 - 427 and 452 - 459 at two different operating frequencies 420 and 450 during a single connection event 410.

[0033] The central node may be configured to effect transition 440 by encoding packets 452, 454, 456, and 458 on a signal with an operating frequency of 450 rather than on a signal with an operating frequency of 420. The central node may then be configured to listen on a channel for the operating frequency of 450, on which packets 453, 455, 457, and 459 are encoded. The peripheral nodes may be configured to effect transition 440 by listening on a channel for the operating frequency of 450, on which packets 452, 454, 456, and 458 are encoded. The peripheral nodes may then be configured to encode packets 453, 455, 457, and 459 on a signal with an operating frequency of 450.

[0034] Timing chart 400 shows that transition 440 occurs immediately after the nodes exchange request 430 and response 432, although the transition to the new operating frequency may occur later in a connection event. In other words, the nodes may effect transition 440 immediately after the peripheral node sends response 432, or, as described below with reference to FIG. 5, the nodes may also schedule a delay for the transition. Timing chart 500 shows a delay for transition 540 after request 530 and response 532, as compared to transition 440 occurring immediately after response 432, shown in timing chart 400. The nodes may schedule the duration of the delay from request 530 and response 532 to transition 540. For example, the central node may be configured to propose a delay for request 530, and the peripheral node may be configured to accept the proposed delay for response 532. The central node may propose the delay by adding a timestamp for transition 540 to request 530. Here, the timestamp indicates the timing at which transition 540 occurs.

[0035] During connection event 510, the nodes exchange packets 522 - 527 encoded at operating frequency 520. During this exchange, the central node sends packet 524 to the peripheral node along with a request 530 to change the operating frequency. The peripheral node then sends packet 525 to the central node along with a response 532 in response to request 530. Request 530 and / or response 532 may contain data such as a new operating frequency for communication (e.g., operating frequency 550).

[0036] After the peripheral node sends packet 527, the nodes perform a transition 540 from operating frequency 520 to operating frequency 550. After the nodes perform transition 540, the central node sends packet 552 to the peripheral node. After transition 540, the nodes exchange packets 552 - 559 encoded at operating frequency 550. The exchange of packets 552 - 559 occurs after the transition 540 to operating frequency 550 but before the end of connection event 510. Thus, the nodes exchange packets 522 - 527 and 552 - 559 at two different operating frequencies 520 and 550 during a single connection event 510.

[0037] Timing charts 400 and 500 show the central node issuing requests 430 and 530, but as shown in FIGS. 6 and 7, it can also be configured such that the peripheral node issues a request to change the operating frequency. Timing chart 600 shown in FIG. 6 shows a peripheral node issuing a request 630 and a central node issuing a response 632. Thus, in the examples shown in FIGS. 4 - 8, either or both nodes can be configured to issue a request to change the operating frequency.

[0038] During connection event 610, the nodes exchange packets 622 - 627 encoded at operating frequency 620. During this exchange, a peripheral node sends packet 625 to the central node along with a request 630 to change the operating frequency. The central node then sends packet 626 to the peripheral node along with a response 632 in response to request 630. Request 630 and / or response 632 may include data such as a new operating frequency for communication (e.g., operating frequency 650).

[0039] The node performs transition 640 immediately after request 630 and response 632, except that the node waits until immediately before the central node sends packet 652. In other words, transition 640 occurs at the next transmission by the central node (i.e., packet 652). The node may be configured to wait to perform transition 640 until immediately before the transmission by the central node so that the transmission at operating frequency 650 is initiated by the central node. Thus, transition 640 occurs when the peripheral node sends only one more packet (e.g., packet 627) without the central node sending any more packets after response 632. This approach may be similar to a technical standard that requires the central node to initiate communication in each connection event, except that packet 652 is not the start of the connection event but the first packet encoded at operating frequency 650. Although not shown in any of FIGS. 4 - 8, the node may be configured to perform the transition immediately after the request or response instead of waiting for the next transmission by the central node (e.g., the peripheral node sends the first packet at the new operating frequency).

[0040] After the peripheral node sends packet 627, the node performs a transition 640 from operating frequency 620 to operating frequency 650, and the node exchanges packets 652 - 659 encoded at operating frequency 650 after transition 640. The exchange of packets 652 - 659 occurs after the transition 640 to operating frequency 650 but before the end of connection event 610. Thus, the node exchanges packets 622 - 627 and 652 - 659 at two different operating frequencies 620 and 650 during a single connection event 610.

[0041] The timing chart 700 shown in FIG. 7 shows the delay of the transition 740 after the request 730 and the response 732, compared to the transition 640 that occurs at the next transmission by the central node after the response 632 shown in the timing chart 600. The node may schedule the duration of the delay from the request 730 and the response 732 to the transition 740. For example, the peripheral node may be configured to propose the delay of the request 730, and the central node may be configured to accept the proposed delay of the response 732. The peripheral node is configured to propose the delay by adding a timestamp for the transition 740 in the request 730, where the timestamp indicates the timing at which the transition 740 occurs.

[0042] During the connection event 710, the nodes exchange packets 722 - 727 encoded at the operating frequency 720. During this exchange, the peripheral node transmits the packet 723 to the central node together with a request 730 for changing the frequency. The central node then transmits the packet 724 to the peripheral node together with a response 732 in response to the request 730. The request 730 and / or the response 732 may include data such as a new operating frequency for communication (e.g., operating frequency 750) and the timing of the transition 740.

[0043] After the peripheral node transmits the packet 727, the node performs the transition 740 from the operating frequency 720 to the operating frequency 750, and the nodes exchange packets 752 - 759 encoded at the operating frequency 750 after the transition 740. The exchange of the packets 752 - 759 occurs after the transition 740 to the operating frequency 750 but before the end of the connection event 710. Therefore, the nodes exchange the packets 722 - 727 and 752 - 759 at two different operating frequencies 720 and 750 during a single connection event 710.

[0044] Timing charts 400, 500, 600, and 700 show transitions to new operating frequencies that occur during the same connection event as the transition request. For example, the central node issues a request 430 during connection event 410, and the node performs a transition during the same connection event 410. In contrast, timing chart 800 shown in FIG. 8 shows a transition 840 that occurs during a subsequent connection event 860 after the completion of connection event 810 in which a node issues a request 830 to change the operating frequency. Connection events 810 and 860 may be consecutive events, or there may be one or more events between connection events 810 and 860.

[0045] During connection event 810, the nodes exchange packets 822-827 encoded at operating frequency 820. During this exchange, the central node sends packet 826 to the peripheral nodes along with a request 830 to change the operating frequency. The peripheral nodes then send packet 827 to the central node along with a response 832 in response to request 830. Request 830 and / or response 832 may include data such as a new operating frequency (e.g., operating frequency 880) for communication and the timing of transition 840.

[0046] Despite the nodes exchanging request 830 and response 832, connection event 810 ends without transitioning to the new operating frequency. This is because the nodes are scheduled such that transition 840 occurs during connection event 860. The nodes may schedule the timing of transition 840 using request 830 and / or response 832. After packet 827, the nodes stop communicating for the remainder of connection event 810 until connection event 860 begins.

[0047] During connection event 860, the node exchanges packets 842 - 847 encoded at operating frequency 870. After exchanging packets 842 - 847, the node performs a transition 840 from operating frequency 870 to operating frequency 880 based on the schedule established in request 830 and / or response 832. After transition 840, the node then exchanges packets 852 - 859 encoded at operating frequency 880. The exchange of packets 852 - 859 occurs after the transition 840 to operating frequency 880 but before the end of connection event 860. Thus, the node exchanges packets 842 - 847 and 852 - 859 at two different operating frequencies 870 and 880 during a single connection event 860.

[0048] After changing the operating frequency, the node may exchange packets 852 - 859 for the remainder of connection event 860. However, packets 842 - 847 exchanged before transition 840 may not have been received by the non - transmitting nodes. Therefore, it may be beneficial for the node to extend the duration of connection event 860 to enable additional communication before a new connection event must be started. Connection event 860 may have a preset duration and / or a maximum duration established in the technical standard. After transition 840, the remaining duration of connection event 860 may not be sufficient for the node to complete their communications.

[0049] If a node determines that there is not enough time remaining in connection event 860 to exchange information, that node may request an extension of the duration of connection event 860. In other words, each node may be configured to send a request to extend the duration of connection event 860 or the duration of any other connection event. The node may send this request during connection event 860 or during connection event 810. For example, the central node may send a request to extend the duration of connection event 860 along with request 830 to change the operating frequency. Alternatively, even if the central node issues request 830 to change the operating frequency, a peripheral node may issue a request to extend the duration of connection event 860.

[0050] The requirement to extend the duration of a connection event was described in the context of operating frequency change. However, regardless of which node requests the change in operating frequency, the node can be configured to request an extension of the duration of the connection event. Even in the absence of a request to change the operating frequency, the node can be configured to request an extension of the duration of the connection event. The node can request that the duration be extended beyond the current duration and / or beyond the maximum duration set by the technical specification. With this extension, by delaying the end of the connection event, the node can achieve a higher throughput.

[0051] FIG. 9 and FIG. 10 are flowcharts of methods 900 and 1000 for changing the operating frequency during a connection event according to some aspects of the present description. Some parts of the processes of methods 900 and 1000 may be performed in an order other than that described, and many processes may be performed simultaneously in parallel. Also, in some examples of the present description, the processes of methods 900 and 1000 may be omitted or replaced. Methods 900 and 1000 will be described with reference to the central node 110 shown in FIG. 1, but other components such as the peripheral node 150 shown in FIG. 1 can also be examples of the same technology.

[0052] Referring to block 910, the central node 110 exchanges packets encoded at a first operating frequency with the peripheral node 150 during a first connection event. To exchange packets, each of the processing circuit elements 140 and 180 may generate a packet and cause the transceiver circuit elements 130 and 170 to transmit the packet via the antennas 120 and 160. The first operating frequency may be the default operating frequency for the first connection event. For example, nodes 110 and 150 may be configured to select the first operating frequency based on a predefined channel set, based on negotiation between nodes 110 and 150, and / or based on some other criterion. However, nodes 110 and 150 may experience noise, interference, and / or jamming at the first operating frequency. As a result, nodes 110 and 150 may discard one or more of the packets exchanged at the first operating frequency.

[0053] Referring to block 920, the central node 110 sends a request to the peripheral node 150 to change the operating frequency during the first connection event. The processing circuit element 140 may embed a request to change the operating frequency within one of the packets sent by the transceiver circuit element 130. Alternatively, the processing circuit element 140 may be configured to generate a request to change the operating frequency as a separate message from other packets sent by the transceiver circuit element 130. In some examples, the central node 110 may send a request to change the operating frequency in methods 900, 1000, 1100, or 1200 along with a request to extend the duration of the connection event.

[0054] The request may include an indication of one or more parameters, such as a new operating frequency or the timing of the transition to the new operating frequency. Instead of negotiating a new operating frequency, nodes 110 and 150 may determine a new operating frequency based on a channel set. Each of nodes 110 and 150 may store a predefined channel set in on-board memory.

[0055] The request at block 920 is a fast means of signaling a change in the operating frequency for nodes 110 and 150 compared to waiting until the next connection event begins. For example, using a request to change the operating frequency may take less than 1 millisecond (e.g., 300 microseconds) to change the operating frequency. In contrast, waiting for the next connection event may take longer than 1 millisecond (e.g., 2 or 3 milliseconds).

[0056] Referring to block 930, the central node 110 optionally receives a response from the peripheral node 150 during the first connection event after sending a request to change the operating frequency. The processing circuit element 180 may generate a response to confirm that the peripheral node 150 has received the request to change the operating frequency. With this response, the peripheral node 150 may confirm the new operating frequency and / or the timing of the transition to the new operating frequency. In this response, the processing circuit element 180 may be configured to request renegotiation of the frequency transition and / or impose restrictions on the transition, such as restrictions on the new operating frequency or the timing of the transition. The processing circuit element 180 may send this response as part of a packet in the exchange between nodes 110 and 150 to the transceiver circuit element 170.

[0057] Referring to block 940, the central node 110 exchanges at least one packet encoded at a second operating frequency with the peripheral node 150. Here, the second operating frequency is different from the first operating frequency. Nodes 110 and 150 exchange this at least one packet after transitioning to the second operating frequency and before the first connection event ends. Thus, nodes 110 and 150 use two different operating frequencies during the first connection event. The second operating frequency may be less susceptible to received noise, interference, and / or jamming, thereby reducing the error rate in the communication between nodes 110 and 150.

[0058] In method 900, the central node 110 issued a request to change the operating frequency. However, the peripheral node 150 can also issue a request to change the operating frequency. Referring to block 1010, the central node 110 exchanges packets encoded at a first operating frequency with the peripheral node 150 during a first connection event. Referring to block 1020, the central node 110 receives a request to change the operating frequency from the peripheral node 150 during the first connection event. The peripheral node 150 can send a request to change the operating frequency embedded within one of the packets exchanged between nodes 110 and 150. Alternatively or additionally, the peripheral node 150 may be configured to send a request to change the operating frequency as a message separate from other packets exchanged by nodes 110 and 150. This request may include a first indication of a new operating frequency and / or a second indication of the timing of the transition to the new operating frequency.

[0059] Referring to block 1030, the central node 110 optionally sends a response to the peripheral node 150 during the first connection event after receiving the request to change the operating frequency. The processing circuit element 140 may cause the transceiver circuit element 130 to transmit this response to confirm that the central node 110 has received a request to change the operating frequency. With this response, the central node 110 may confirm the new operating frequency and / or the timing of the transition to the new operating frequency. The central node 110 may send this response as part of a packet in the exchange between nodes 110 and 150.

[0060] Referring to block 1040, the central node 110 exchanges at least one packet encoded at a second operating frequency with the peripheral node 150. Here, the second operating frequency is different from the first operating frequency. Nodes 110 and 150 exchange this at least one packet after transitioning to the second operating frequency and before the first connection event ends. Therefore, nodes 110 and 150 use two different operating frequencies during the first connection event. The second operating frequency can have less noise, interference, and / or jamming received, thereby reducing the error rate in the communication between nodes 110 and 150.

[0061] Methods 900 and 1000 are involved in transitioning to a new operating frequency during the same connection event as the request to change the operating frequency. However, a node may schedule a transition to a new operating frequency in a subsequent connection event. In this regard, FIGS. 11 and 12 are flowcharts of methods 1100 and 1200 for scheduling a transition to a new operating frequency in a subsequent connection event, according to some aspects of the present description. Some parts of the processes of methods 1100 and 1200 may be performed in an order other than that described, and many processes may be performed simultaneously in parallel. Also, in some examples of the present description, the process of method 1300 may be omitted or replaced. Methods 1100 and 1200 are described with reference to the central node 110 shown in FIG. 1, but other components such as the peripheral node 150 shown in FIG. 1 may also be examples of similar techniques.

[0062] Referring to block 1110, central node 110 exchanges a first set of packets encoded at a first operating frequency with peripheral node 150 during a first connection event. Referring to block 1120, processing circuit element 140 causes transceiver circuit element 130 to send a request to peripheral node 150 to change the operating frequency during the first connection event. Central node 110 may send a request to change the operating frequency embedded within one of the packets in the first set of packets. Alternatively or additionally, central node 110 may be configured to send a request to change the operating frequency as a message separate from the first set of packets. This request may further include a first indication of a new operating frequency and / or a second indication of the timing of the transition to the new operating frequency during a subsequent connection event.

[0063] Referring to block 1130, central node 110 optionally receives a response from peripheral node 150 during the first connection event after sending a request to change the operating frequency. Peripheral node 150 may send a response to confirm that peripheral node 150 has received a request to change the operating frequency. With this response, peripheral node 150 may confirm the new operating frequency and / or the timing of the transition to the new operating frequency. Peripheral node 150 may send this response as part of a packet in the first set of packets. By exchanging these requests and responses, nodes 110 and 150 may pre-negotiate the channel transitions that nodes 110 and 150 will apply during a subsequent connection event.

[0064] Referring to block 1140, central node 110 exchanges a second packet encoded at a second operating frequency with peripheral node 150. Here, the second operating frequency is different from the first operating frequency. Nodes 110 and 150 exchange the second packet in a second connection event after the first connection event. The second packet may be part of a second set of packets exchanged between nodes 110 and 150 at the start of the second connection event (e.g., packets 842 - 847 shown in FIG. 8).

[0065] Referring to block 1150, central node 110 exchanges a third packet encoded at a third operating frequency with peripheral node 150. Here, the third operating frequency is different from the second operating frequency. The third operating frequency may also be different from the first operating frequency used by nodes 110 and 150 during the first connection event. Nodes 110 and 150 exchange the third packet after transitioning to the third operating frequency but before the second connection event ends. Therefore, nodes 110 and 150 use two different operating frequencies during the second connection event.

[0066] In method 1100, central node 110 issues a request to change the operating frequency in a subsequent connection event. However, peripheral node 150 can also issue a request to change the operating frequency in a subsequent connection event. Referring to block 1210, central node 110 exchanges a first set of packets encoded at the first operating frequency with peripheral node 150 during the first connection event. Referring to block 1220, central node 110 receives a request to change the operating frequency from peripheral node 150 during the first connection event. Peripheral node 150 can send a request to change the operating frequency embedded in one of the packets of the first set of packets. Alternatively, peripheral node 150 may be configured to send a request to change the operating frequency as a message separate from the first set of packets. This request may include a first indication of a new operating frequency and / or a second indication of the timing of the transition to the new operating frequency during a subsequent connection event.

[0067] Referring to block 1230, the central node 110 optionally sends a response to the peripheral node 150 during the first connection event after receiving a request to change the operating frequency. The central node 110 may send a response to confirm that the central node 110 has received a request to change the operating frequency. With this response, the central node 110 may confirm the new operating frequency and / or the timing of the transition to the new operating frequency. The central node 110 may send this response as part of a certain packet in the first set of packets.

[0068] Referring to block 1240, the central node 110 exchanges a second packet encoded at a second operating frequency with the peripheral node 150. Here, the second operating frequency is different from the first operating frequency. Nodes 110 and 150 exchange the second packet in a second connection event after the first connection event. The second packet may be part of a second set of packets exchanged between nodes 110 and 150 at the start of the second connection event (e.g., packets 842 - 847 shown in FIG. 8).

[0069] Referring to block 1250, the central node 110 exchanges a third packet encoded at a third operating frequency with the peripheral node 150. Here, the third operating frequency is different from the second operating frequency. The third operating frequency may also be different from the first operating frequency used by nodes 110 and 150 during the first connection event. Nodes 110 and 150 exchange the third packet after transitioning to the third operating frequency and before the second connection event ends. Therefore, nodes 110 and 150 use two different operating frequencies during the second connection event.

[0070] FIG. 13 is a flowchart of a method 1300 for extending the duration of a connection event according to some aspects of the present description. Some parts of the process of method 1300 may be performed in an order other than that described, and many processes may be performed simultaneously in parallel. Also, in some examples of the present description, the process of method 1300 may be omitted or replaced. Method 1300 is described with reference to the central node 110 shown in FIG. 1, but other components such as the peripheral nodes 150 shown in FIG. 1 may also be examples of the same technology.

[0071] Referring to block 1310, the central node 110 determines a first duration for a first connection event. The first duration can be a default duration, a preset duration, and / or a maximum duration. The central node 110 can be configured to determine the first duration based on a technical standard. For example, software or firmware stored in a memory mounted on the central node 110 can include data values for the first duration.

[0072] Referring to block 1320, the central node 110 exchanges a first set of packets with the peripheral node 150 during the first connection event. Nodes 110 and 150 can start exchanging the first set of packets at the start of the first connection event. Referring to block 1330, the central node 110 sends a request to the peripheral node 150 to extend the first connection event to a second duration. The central node 110 can embed this request within one of the packets of the first set of packets. Alternatively or additionally, the central node 110 can be configured to send this request as a message separate from the other packets of the first set of packets.

[0073] Referring to block 1340, the central node 110 optionally receives a response from the peripheral node 150 during the first connection event after sending this request. The peripheral node 150 may send a response to confirm that the peripheral node 150 has received a request to extend the duration of the first connection event. With this response, the peripheral node 150 may confirm the new duration. The peripheral node 150 can send this response as part of a packet in the first set of packets or as a message separate from the first set of packets.

[0074] Referring to block 1350, after sending a request to extend the duration of the first connection event, the central node 110 exchanges a second set of packets with the peripheral node 150 during the first connection event. The exchange of the second set of packets can continue beyond the first duration of the first connection event. Therefore, the actual duration of the first connection event (e.g., the second duration) can be longer than the preset default duration and / or longer than the preset maximum duration. In other words, nodes 110 and 150 can continue to exchange packets beyond the first duration without stopping the first connection event or setting a second connection event.

[0075] As the duration increases, the throughput during the first connection event can be increased without the overhead of stopping the first connection event and then starting a second connection event. As described above, methods 900, 1000, 1100, 1200, and 1300 have been described as being implemented by the central node 110, but the peripheral node 150 may be configured to implement methods 900, 1000, 1100, 1200, and / or 1300.

[0076] In this description, nodes 110 and 150 are given functions. Nodes 110 and 150, transceiver circuit elements 130 and 170, and processing circuit elements 140 and 180 may include one or more processors. Nodes 110 and 150, transceiver circuit elements 130 and 170, and processing circuit elements 140 and 180 may include any combination of integrated circuit elements, individual logic circuit elements, and analog circuit elements such as one or more microprocessors, microcontrollers, digital signal processors, application-specific integrated circuits, central processing units, graphics processing units, field-programmable gate arrays, and / or any other processing resources.

[0077] In some examples, nodes 110 and 150, transceiver circuit elements 130 and 170, and processing circuit elements 140 and 180 may include any combination of the processing resources listed above, as well as multiple components such as other individual or integrated logic circuit elements and / or analog circuit elements.

[0078] The techniques described in this description may also be embodied or encoded in a manufacture that includes a non-transitory computer-readable storage medium. Exemplary non-transitory computer-readable storage media may include random access memory (RAM), read-only memory (ROM), programmable ROM, erasable programmable ROM, electronically erasable programmable ROM, flash memory, solid state drive, hard disk, magnetic media, optical media, or any other computer-readable storage device or tangible computer-readable medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagated signal. In some examples, the non-transitory storage medium may store data that can change over time (e.g., in RAM or a cache).

[0079] As used herein, the term "coupled" may include a connection, communication, or signal path that enables a functional relationship consistent with this description. For example, if device A generates a signal for controlling device B to perform a certain action, (a) in a first example, device A is coupled to device B by a direct connection, or (b) in a second example, when an intervening component C does not change the functional relationship between device A and device B, device A is coupled to device B via the intervening component C such that device B is controlled by device A by the control signal generated by device A.

[0080] This description provides several examples, and these examples can also be modified. Such modifications are clearly within the scope of this description. Also, applying these teachings to other environments, applications, and / or purposes is consistent with this description and is contemplated by this disclosure.

Claims

1. A method comprising: During a first connection event, sending, by a first node, a request to a second node to change a current operating frequency, the request being encoded at a first operating frequency; During the first connection event, sending, by the first node, to the second node, a first packet encoded at a second operating frequency; wherein the second operating frequency is different from the first operating frequency.

2. The method according to claim 1, further comprising, at the first node during the first connection event, receiving a response to the request from the second node, the response being encoded at the first operating frequency.

3. The method according to claim 1, wherein the request is a first request, and the method further comprises, during the first connection event, sending, by the first node, to the second node, a second request to extend a duration of the first connection event.

4. The method according to claim 3, further comprising, after sending the second request, exchanging packets between the first node and the second node during the first connection event for a duration exceeding a preset duration of the first connection event.

5. The method according to claim 1, wherein the request is a first request, and the method further comprises, during the first connection event, the first node receiving from the second node a second request to extend a duration of the first connection event.

6. The method according to claim 1, wherein after sending the request, the first node does not send other packets encoded at the first operating frequency during the first connection event.

7. The method according to claim 1, wherein after sending the request, the first node sends only one other packet encoded at the first operating frequency during the first connection event.

8. The method according to claim 1, further comprising generating the request to include an indication of time for changing the current operating frequency for the first and second nodes, wherein sending of the first packet is performed after the time for changing the current operating frequency.

9. The method according to claim 1, further comprising generating a second packet before sending the request; embedding the request in the second packet; comprising; a method, wherein sending the request includes sending the second packet and the embedded request to a peripheral node during the first connection event. **Claim 10** The method according to claim 1, wherein the first connection event is a Bluetooth Low Energy connection event. **Claim 11** The method according to claim 1, wherein sending the first packet is performed before the end of the first connection event. **Claim 12** The method according to claim 1, further comprising generating the request to include an indication of the second operating frequency. **Claim 13** The method according to claim 1, further comprising determining the second operating frequency based on a predefined channel set. **Claim 14** A device comprising: a transceiver circuit element; a processing circuit element; comprising; wherein the processing circuit element: generates a request to change the current operating frequency during a first connection event; causes the transceiver circuit element to send the request encoded at a first operating frequency; generates a first packet after causing the transceiver circuit element to send the request; causes the transceiver circuit element to send the first packet encoded at a second operating frequency during the first connection event; is configured such that; the second operating frequency is different from the first operating frequency. **Claim 15** The device according to claim 14, wherein the request is a first request, and the processing circuit element is further configured to cause the transceiver circuit element to send a second request to extend the duration of the first connection event during the first connection event. **Claim 16** The device according to claim 14, wherein the processing circuit element is further configured to generate the request to include an indication of the time for changing the current operating frequency for the first and second nodes, and the processing circuit element is configured to cause the transceiver circuit element to send the first packet after the time for changing the current operating frequency. **Claim 17** The device according to claim 14, wherein the processing circuit element is further configured to generate the request to include an indication of the second operating frequency.

18. A non-transitory computer-readable medium storing instructions executable by a processing circuit element, the instructions causing the processing circuit element to generate a request to change a current operating frequency during a first connection event, send the request encoded at a first operating frequency to a transceiver circuit element, generate a first packet after sending the request to the transceiver circuit element, cause the transceiver circuit to send the first packet encoded at a second operating frequency during the first connection event, wherein the second operating frequency is different from the first operating frequency, the non-transitory computer-readable medium.

19. The non-transitory computer-readable medium according to claim 18, wherein the request is a first request, and the instructions are further configured to cause the transceiver circuit element to send a second request to extend the duration of the first connection event during the first connection event, the non-transitory computer-readable medium.

20. The non-transitory computer-readable medium according to claim 18, wherein the instructions are further configured to generate the request to include an indication of time for changing the current operating frequency for the first and second nodes, and the instructions are configured to cause the transceiver circuit element to send the first packet after the time for changing the current operating frequency, the non-transitory computer-readable medium.

Images