Frequency variation during connection events

Abstract

A 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, where the request (430) is encoded at a first operating frequency (420). The method also includes transmitting, 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), wherein the second operating frequency (450) is different from the first operating frequency (420).

Description

Background Art

[0001] A Bluetooth Low Energy (BLE) connection event occurs when two devices transmit data on a BLE communication channel. During a first connection event at a predefined operating frequency / channel, the 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 to be transmitted alternately between the two nodes until the device terminates the first connection event, until the two nodes no longer have data to transmit, or until the maximum duration of the connection event has passed. After the first connection event ends, 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, the method includes sending, by the first node to the second node during a first connection event, a request to change a current operating frequency, wherein the request is encoded in the 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 in a second operating frequency, wherein the second operating frequency is different from the first operating frequency.

[0003] In another example, an apparatus includes a transceiver circuit and a processing circuit. The processing circuit is configured to generate a request to change a current operating frequency during a first connection event. Additionally, the processing circuit is configured to cause the transceiver circuit to send the request encoded at the first operating frequency. The processing circuit is further configured to generate a first packet after causing the transceiver circuit to send the request. The processing circuit is further configured to 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.

[0004] In yet other examples, a non-transitory computer-readable medium has executable instructions stored thereon, the executable instructions being configured to be executable by a processing circuit to cause the processing circuit to generate a request to change a current operating frequency during a first connection event. The instructions, when executed, also cause the processing circuit to cause a transceiver circuit to send a request encoded at the first operating frequency. The instructions, when executed, further cause the processing circuit to generate a first packet after causing the transceiver circuit to send the request. Additionally, the instructions, when executed, cause the transceiver circuit to send a 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The following detailed description and accompanying drawings describe the features of the present invention. In this regard:

[0006] Figure 1 A conceptual block diagram of a central node communicating with peripheral nodes according to some aspects of the present specification.

[0007] Figure 2 Figure 2 is a timing diagram of two connection events.

[0008] Figure 3 Figure 2 is a timing diagram of four connection events during which the node experienced noise.

[0009] Figure 4-8 A timing diagram of a request to change frequency during a connection event according to some aspects of the present disclosure.

[0010] Fig. 9 and 10 Flowchart of a method for changing frequency during a connection event according to some aspects of the present specification.

[0011] Fig.11 and 12 Flowchart of a method for scheduling a transition to a new operating frequency in a subsequent connection event according to some aspects of the present specification.

[0012] Fig.13 A flowchart of a method for extending the duration of a connection event according to some aspects of the present specification. DETAILED DESCRIPTION

[0013] Specific examples are described in detail below with reference to the accompanying drawings. These examples are not limiting, and unless otherwise indicated, no feature is essential to any specific example.

[0014] Two electronic devices can communicate with each other using technical standards provided for connection events involving the exchange of packets between the devices. The exchange of packets between the devices during a single connection event can occur within a single predefined operating frequency / channel. In other words, according to the technical standards, each device can encode packets at a single operating frequency for the duration of the connection event without switching to another operating frequency.

[0015] If a node experiences congestion, noise, or interference on an operating frequency during a connection event, any retransmission of a packet will occur on the same operating frequency. A jammer may jam less than all available operating frequencies (e.g., frequency selective fading), while other available operating frequencies are not jammed. According to technical standards, a node will communicate on the same operating frequency throughout a connection event, even in the face of high loss rates or high retransmission rates. Therefore, the performance of a node may suffer due to the node being unable to hop to another operating frequency before the connection event ends.

[0016] In the techniques of the present specification, one of the nodes may issue a request to switch to a new operating frequency before the current connection event ends. By switching to another operating frequency, the node may be able to avoid interference on one channel by quickly switching to another operating frequency. Quickly switching to another operating frequency can increase throughput, increase immunity to congestion and interference, and reduce latency and response time. Of course, these advantages are only examples, and no advantage is required for any particular example.

[0017] An example of frequency switching during a connection event is described below with reference to the drawings. In this regard, Figure 1 1 is a conceptual block diagram of a central node 110 communicating with a peripheral node 150 according to some aspects of the present specification. System 100 includes central node 110 and peripheral node 150, each node including antenna 120 or 160, transceiver circuit 130 or 170, and processing circuit 140 or 180. Central node 110 and peripheral node 150 communicate via wireless communication, such as via a short-range technology standard (e.g., Bluetooth Low Energy as specified by the Bluetooth SIG). (BLE)) is communicatively coupled. Additional example details of BLE can be found in commonly assigned U.S. Patent Application Publication No. 2020 / 0187010, filed on December 11, 2018, entitled “Secure Localization in Wireless Networks,” and U.S. Patent Application Publication No. 10,225,873, filed on February 18, 2016 and published on March 5, 2019, entitled “System and Method for Peripheral Initiated Host Arbitration,” each of which is incorporated herein by reference in its entirety.

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

[0019] The peripheral node 150 tunes to a predefined operating frequency to receive a packet at the antenna 160, and the transceiver circuit 170 filters and / or amplifies the signal encoding the packet. The transceiver circuit 170 and / or the processing circuit 180 may be configured to decode the signal encoding the packet and store the data in the packet. The transceiver circuit 170 and the processing circuit 180 may be configured to perform the same steps as when the transceiver circuit 130 and the processing circuit 140 generate and transmit the packet. The same general steps may be performed by the processing circuits 140 and 180 and the transceiver circuits 130 and 170 to generate and transmit the request described herein. For example, the link layer or air access control in the processing circuit 140 or 180 may be configured to generate a request for changing the current operating frequency transmitted by the transceiver circuit 130 or 170. The frequency change request may be transparent to the host and to the application running on the node 110 or 150. A frequency change request may be issued by processing circuit 140 or 180 in response to a short or long channel quality assessment.

[0020] Nodes 110 and 150 may be coupled in a communication manner via a wireless channel at a predefined operating frequency, and the nodes 110 and 150 may change at the beginning of each connection event. Nodes 110 and 150 may exchange packets at the operating frequency through encoded data during the connection event. In the example of BLE communication, the central node 110 may be configured to initiate each connection event by sending a packet to the peripheral node 150. The connection event may continue to cause nodes 110 and 150 to exchange packets until the connection event ends. Once nodes 110 and 150 have reached the end of the duration of the connection event, nodes 110 and 150 may stop exchanging packets and initialize the next connection event at a predefined time. Alternatively, nodes 110 and 150 may autonomously terminate the exchange of packets before the connection event ends. After this early termination, nodes 110 and 150 may be configured to avoid communication during the remaining duration of the connection event until nodes 110 and 150 initialize the next connection event.

[0021] Figure 2 2 is a timing diagram 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 may have a duration referred to as a connection interval, which may be a preset duration. In some examples, each connection event may have a variable duration bounded by a maximum allowable duration.

[0022] During connection event 210, the central node exchanges packets 212-217 with the peripheral node. During connection event 220, the central node exchanges packets 222-227 with the peripheral node. In some examples, the duration of each packet (e.g., the time between the start of packet 212 and the start of packet 213) is approximately one hundred fifty microseconds.

[0023] In the example shown in timing diagram 200, the central node and the peripheral nodes alternate between transmission and reception. For example, during connection event 210, the transmission of packets 212, 214, and 216 by the central node alternates 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 alternates with the transmission of packets 223, 225, and 227 by the peripheral nodes. The central node initiates both connection events 210 and 220 by transmitting packets 212 and 222, while the peripheral nodes may be configured to initiate connection events by transmitting packets.

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

[0025] Figure 3310, 320, 330 and 340 during which the node experiences noise. In some examples, during each of the connection events 310, 320, 330 and 340, the exchange of packets occurs at different operating frequencies. The node may exchange packets at a first operating frequency during the connection event 310, and the node may exchange packets at a second operating frequency different from the first operating frequency during the connection event 320. In addition, the node may exchange packets at a third operating frequency different from the first and second operating frequencies during the connection event 330. The node may also exchange packets at a fourth operating frequency different from the first, second and third operating frequencies during the connection event 340. During the connection event 330, the peripheral node does not receive transmissions from the central node due to, for example, noise or congestion. The operating frequency used for communication during the connection event 330 experiences this noise or congestion, while other available operating frequencies may be relatively noise-free. If the node is not configured to change the operating frequency within the connection event 330, then when the conventional operating frequency transition occurs, the node may have to wait until the connection event 340.

[0026] This is illustrated in timing diagram 300, where the peripheral node waits during wait time 360 ​​until a connection event 340 begins. The peripheral node does not receive packets transmitted by the central node at the beginning of the connection event 330. Therefore, the peripheral node does not transmit packets to the central node during the connection event 330. Instead, when the central node will transmit packets encoded at the new operating frequency, the peripheral node waits until the connection event 340 begins. The node implements this retry mechanism by waiting at the beginning of the connection event 340 to attempt communication on the channel used in the connection event 330 or on a different channel. The node does not Figure 3 Communications occur during a wait period, shown as wait time 360.

[0027] Returning to the beginning of timing diagram 300, connection event 310 begins at time 352 and ends at time 354, connection event 320 begins at time 354 and ends at time 356, connection event 330 begins at time 356 and ends at time 358, and connection event 340 begins at time 358. The central node and the peripheral node 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 timing diagram 300, the central node initiates each connection event by transmitting. The technical standard may specify that the central node initiates communication during each connection event, or the technical standard may allow the peripheral node to initiate communication in some circumstances.

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

[0029] The technical standard may support early termination of each connection event, which means that in connection events 310, 320, 330, or 340, any of the nodes may terminate the exchange of packets, after which no communication will occur until the next connection event begins. For example, timing diagram 300 depicts a subinterval of stopped communication in connection event 310 after the nodes exchange two packets. The technical standard may require that the duration of each of connection events 310, 320, 330, and 340 be a fixed length or less than a preset maximum length.

[0030] Figure 4-8 The timing diagrams 400, 500, 600, 700, and 800 are timing diagrams 400, 500, 600, 700, and 800 that include a request to change operating frequency during a connection event according to some aspects of the present specification. Each of the timing diagrams 400, 500, 600, 700, and 800 shows the exchange of packets encoded at two different operating frequencies during a single connection event. In each of the timing diagrams 400, 500, 600, 700, and 800, a node issues a request to change operating frequency, and the node switches to the new operating frequency within the connection event.

[0031] Timing diagram 400 shows communication between a central node and a peripheral node during a connection event 410. During connection event 410, the nodes exchange packets 422-427 encoded at operating frequency 420. During this exchange, the central node transmits packet 426 to the peripheral node along with a request 430 to change the operating frequency. The peripheral node then transmits packet 427 to the central node along with a response 432 in response 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, convert, or transition to the new operating frequency (e.g., timing of transition 440).

[0032] After the peripheral node transmits packet 427, the node performs a transition 440 from operating frequency 420 to operating frequency 450. After request 430, transition 440 occurs without the central node sending any more packets, and after response 432, the peripheral node does not send any more packets. After the node performs transition 440, the central node transmits packet 452 to the peripheral node. After transition 440, the node exchanges packets 452-459 encoded at operating frequency 450. 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 node exchanges 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 perform transition 440 by encoding packets 452, 454, 456, and 458 on a signal at operating frequency 450 instead of encoding the packets on a signal at operating frequency 420. The central node may be configured to thereafter listen to the channel for operating frequency 450 where packets 453, 455, 457, and 459 are encoded. The peripheral nodes may be configured to perform transition 440 by listening to the channel for operating frequency 450 where packets 452, 454, 456, and 458 are encoded. The peripheral nodes may be configured to thereafter encode packets 453, 455, 457, and 459 on a signal at operating frequency 450.

[0034] Although timing diagram 400 shows transition 440 occurring immediately after the nodes exchange request 430 and response 432, the transition to the new operating frequency may occur later in the connection event. In other words, the node may perform transition 440 immediately after the peripheral node sends response 432, or the node may schedule a delay in the transition, as described below with respect to Figure 5 The timing diagram 500 depicts a delay in the transition 540 following the request 530 and the response 532, which occurs immediately after the response 432, compared to the transition 440 shown in the timing diagram 400. The nodes may schedule the duration of the delay from the request 530 and the response 532 to the transition 540. For example, the central node may be configured to propose a delay in the request 530, and the peripheral nodes may be configured to accept the proposed delay in the response 532. The central node may propose a delay by adding a timestamp for the transition 540 to the request 530, where the timestamp indicates when the transition 540 occurs.

[0035] During connection event 510, nodes exchange packets 522-527 encoded with operating frequency 520. During this exchange, the central node transmits packet 524 to the peripheral node along with a request 530 to change the operating frequency. The peripheral node then transmits 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 transmits packet 527, the node performs a transition 540 from operating frequency 520 to operating frequency 550. After the node performs transition 540, the central node transmits packet 552 to the peripheral node. After transition 540, the node exchanges 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 the connection event 510. Thus, the node exchanges packets 522-527 and 552-559 at two different operating frequencies 520 and 550 during a single connection event 510.

[0037] Although timing diagrams 400 and 500 show a central node issuing requests 430 and 530, peripheral nodes may be configured to issue requests to change operating frequencies, such as Figure 6 and 7 shown. Figure 6 The timing diagram 600 shown in FIG. 6 shows that the peripheral node sends a request 630 and the central node sends a response 632. Figure 4-8 In the example shown in , either or both of the nodes may be configured to issue a request to change the operating frequency.

[0038] During connection event 610, the nodes exchange packets 622-627 encoded with operating frequency 620. During this exchange, the peripheral node transmits packet 625 to the central node along with a request 630 to change the operating frequency. The central node then transmits packet 626 to the peripheral node along with a response 632 in response to request 630. Request 630 and / or response 632 may contain 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 just before the central node transmits packet 652. In other words, transition 640 occurs at the next transmission by the central node (i.e., packet 652). The node can be configured to wait to perform transition 640 until just before a transmission by the central node, so that the transmission at operating frequency 650 is initiated by the central node. Therefore, transition 640 occurs when the central node does not send any more packets after response 632 and the peripheral nodes only send more packets (e.g., packet 627). This approach can be similar to technical standards that require the central node to initiate communication in each connection event, except that packet 652 is not the beginning of a connection event, but is actually the first packet encoded at operating frequency 650. Although not in Figure 4-8 , but the nodes may be configured to perform the transition immediately following a request or response (e.g., a peripheral node would transmit the first packet at the new operating frequency) rather than waiting for the next transmission from the central node.

[0040] After the peripheral node transmits 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] Figure 7 730 and the central node 732, the time delay in the transition 740 causing the next transmission of the central node after the response 632, compared to the transition 640 shown in the timing diagram 600. The node can schedule the duration of the delay from the request 730 and the response 732 to the transition 740. For example, the peripheral node can be configured to propose a delay in the request 730, and the central node can be configured to accept the proposed delay in the response 732. The peripheral node can be configured to propose a delay by adding a timestamp for the transition 740 in the request 730, where the timestamp indicates when the transition 740 occurs.

[0042] During the connection event 710, the nodes exchange packets 722-727 encoded with the operating frequency 720. During this exchange, the peripheral node transmits a packet 723 to the central node along with a request 730 to change the operating frequency. The central node then transmits a packet 724 to the peripheral node along 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 packet 727, the node performs a transition 740 from operating frequency 720 to operating frequency 750, and the node exchanges packets 752-759 encoded at operating frequency 750 after transition 740. The exchange of packets 752-759 occurs after the transition 740 to operating frequency 750 but before the end of connection event 710. Thus, the node exchanges packets 722-727 and 752-759 at two different operating frequencies 720 and 750 during a single connection event 710.

[0044] The timing diagrams 400, 500, 600, 700 show a transition to a new operating frequency occurring during the same connection event as the request to transition. For example, the central node issues a request 430 during a connection event 410, and the node performs the transition during the same connection event 410. In contrast, Figure 8 The timing diagram 800 shown in shows a transition 840 that occurs during a later connection event 860 after the end of connection event 810 when a node issues a request 830 to change the operating frequency. Connection event 810 and connection event 860 may be consecutive events, or there may be one or more events between connection event 810 and connection event 860.

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

[0046] Even though the nodes exchange requests 830 and responses 832, connection event 810 ends without transitioning to a new operating frequency. This is because the nodes schedule transition 840 to occur during connection event 860. The nodes may use the timing of request 830 and / or response 832 to schedule transition 840. After packet 827, the nodes cease communications for the remainder of connection event 810 until connection event 860 begins.

[0047] During the connection event 860, the node exchanges packets 842-847 encoded at the operating frequency 870. After exchanging packets 842-847, the node performs a transition 840 from the operating frequency 870 to the operating frequency 880 based on the schedule established in the request 830 and / or the response 832. After the transition 840, the node then exchanges packets 852-859 encoded at the operating frequency 880. The exchange of packets 852-859 occurs after the transition 840 to the operating frequency 880 but before the end of the 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 the connection event 860. However, the packets 842-847 exchanged before the transition 840 may not have been received by the non-transmitting node. For this reason, it may be beneficial for the node to extend the duration of the connection event 860 to allow for additional communications before a new connection event must be started. The connection event 860 may have a preset duration and / or a maximum duration that has been established in a technical standard. After the transition 840, the remaining duration of the connection event 860 may not be sufficient for the node to complete its communications.

[0049] If a node determines that the time remaining in connection event 860 is insufficient to exchange information, the 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 to extend the duration of any other connection event. A node may send such a request during connection event 860 or during connection event 810. For example, a central node may send a request to extend the duration of connection event 860 together with a request 830 to change the operating frequency. Alternatively, a peripheral node may issue a request to extend the duration of connection event 860 even if the central node has issued a request 830 to change the operating frequency.

[0050] Although the request to extend the duration of a connection event has been described in the context of changing the operating frequency, a node may be configured to request an extension of the duration of a connection event regardless of whether any node has requested a change in the operating frequency. A node may be configured to request an extension of the duration of a connection event even without any request to change the operating frequency. A node may request an extension of the duration beyond the current duration and / or beyond a maximum duration set by a technical standard. The extension may allow a node to achieve higher throughput by delaying the end of a connection event.

[0051] Fig. 9 and 101 is a flow chart of methods 900 and 1000 for changing operating frequency during a connection event according to some aspects of the present specification. Some processes of methods 900 and 1000 may be performed in an order different from the order described, and many processes may be performed in parallel. In addition, in some examples of the present specification, processes of methods 900 and 1000 may be omitted or replaced. Figure 1 The central node 110 shown in FIG. 1 is used to describe methods 900 and 1000 , but Figure 1 Other components shown in FIG. 1 , such as peripheral node 150 , may illustrate similar techniques.

[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 circuits 140 and 180 may generate packets and cause the transceiver circuits 130 and 170 to transmit packets via the antennas 120 and 160. The first operating frequency may be a default operating frequency for the first connection event. For example, the nodes 110 and 150 may be configured to select the first operating frequency based on a predefined channel set, based on a negotiation between the nodes 110 and 150, and / or based on some other criteria. However, the nodes 110 and 150 may experience noise, congestion, and / or interference on the first operating frequency. Therefore, the nodes 110 and 150 may discard one or more of the packets exchanged on the first operating frequency.

[0053] Referring to block 920, the central node 110 sends a request to change the operating frequency to the peripheral node 150 during the first connection event. The processing circuit 140 may embed the request to change the operating frequency within one of the packets sent by the transceiver circuit 130. Also, or alternatively, the processing circuit 140 may be configured to generate the request to change the operating frequency as a separate message from other packets sent by the transceiver circuit 130. In some examples, the central node 110 may send the request to change the operating frequency in the method 900, 1000, 1100, or 1200 along with the 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 and an opportunity for transitioning to the new operating frequency. As an alternative to negotiating a new operating frequency, nodes 110 and 150 may determine a new operating frequency based on a set of channels. Each of nodes 110 and 150 may store a set of predefined channels in an onboard memory.

[0055] Compared to waiting for the next connection event to start, the request in block 920 is a fast means for nodes 110 and 150 to signal a change in operating frequency. For example, by using a request to change operating frequency, the time to change operating frequency may be less than one millisecond (e.g., three hundred microseconds). In contrast, waiting for the next connection event may take more than one millisecond (e.g., two or three milliseconds).

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

[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, wherein the second operating frequency is different from the first operating frequency. The nodes 110 and 150 exchange at least one packet after switching to the second operating frequency and before the first connection event ends. Thus, the nodes 110 and 150 use two different operating frequencies during the first connection event. The second operating frequency may have less noise, congestion, and / or interference, thereby allowing the error rate in the communication between the nodes 110 and 150 to be reduced.

[0058] In method 900, central node 110 issues a request to change the operating frequency. However, peripheral node 150 may also be able to issue a request to change the operating frequency. Referring to box 1010, central node 110 exchanges packets encoded with a first operating frequency with peripheral node 150 during a first connection event. Referring to box 1020, central node 110 receives a request to change the operating frequency from peripheral node 150 during the first connection event. Peripheral node 150 may send the request to change the operating frequency embedded in one of the packets exchanged between nodes 110 and 150. And, or alternatively, peripheral node 150 may be configured to send the request to change the operating frequency as a message separate from other packets exchanged by nodes 110 and 150. The request may include a first indication of the new operating frequency and / or a second indication of the timing of transitioning to the new operating frequency.

[0059] Referring to block 1030, the central node 110 optionally sends a response to the peripheral node 150 after receiving the request to change the operating frequency during the first connection event. The processing circuit 140 may cause the transceiver circuit 130 to send a response to confirm that the central node 110 received the request to change the operating frequency. Through the response, the central node 110 may confirm the new operating frequency and / or confirm the timing of transitioning to the new operating frequency. The central node 110 may send the response as part of a packet in an exchange between the 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, wherein the second operating frequency is different from the first operating frequency. The nodes 110 and 150 exchange at least one packet after switching to the second operating frequency and before the first connection event ends. Thus, the nodes 110 and 150 use two different operating frequencies during the first connection event. The second operating frequency may have less noise, congestion, and / or interference, thereby allowing the error rate in the communication between the nodes 110 and 150 to be reduced.

[0061] Methods 900 and 1000 involve transitioning to a new operating frequency during the same connection event as the request to change the operating frequency. However, the node may schedule the transition to the new operating frequency at a later connection event. In this regard, Fig.11 and 12 1 is a flow chart 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 specification. Some processes of methods 1100 and 1200 may be performed in an order different from the order described, and many processes may be performed in parallel. In addition, in some examples of the present specification, processes of methods 1100 and 1200 may be omitted or replaced. Reference Figure 1 The central node 110 shown in FIG. 1 describes methods 1100 and 1200 , but Figure 1 Other components shown in FIG. 1 , such as peripheral node 150 , may illustrate similar techniques.

[0062] Referring to block 1110, the central node 110 exchanges a first set of packets encoded at a first operating frequency with the peripheral node 150 during a first connection event. Referring to block 1120, the processing circuit 140 causes the transceiver circuit 130 to send a request to change the operating frequency to the peripheral node 150 during the first connection event. The central node 110 may send the request to change the operating frequency embedded in a packet in the first set of packets. In addition, or in the alternative, the central node 110 may be configured to send the request to change the operating frequency as a message separate from the first set of packets. The request may include a first indication of a new operating frequency and / or a second indication of an opportunity to transition to the new operating frequency during a later connection event.

[0063] Referring to block 1130, the central node 110 optionally receives a response from the peripheral node 150 after sending the request to change the operating frequency during the first connection event. The peripheral node 150 may send the response to confirm that the peripheral node 150 received the request to change the operating frequency. Through the response, the peripheral node 150 may confirm the new operating frequency and / or confirm the timing of transitioning to the new operating frequency. The peripheral node 150 may send the response as part of a packet in the first set of packets. By exchanging the request and the response, the nodes 110 and 150 may preemptively negotiate a channel transition that the nodes 110 and 150 will apply in a later connection event.

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

[0065] Referring to block 1150, the central node 110 exchanges a third packet encoded at a third operating frequency with the peripheral node 150, wherein 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 the nodes 110 and 150 during the first connection event. The nodes 110 and 150 exchange the third packet after switching to the third operating frequency and before the second connection event ends. Therefore, the 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 later connection event. However, peripheral node 150 may also issue a request to change the operating frequency in a later connection event. Referring to box 1210, central node 110 exchanges a first set of packets encoded with a first operating frequency with peripheral node 150 during a first connection event. Referring to box 1220, central node 110 receives a request to change the operating frequency from peripheral node 150 during the first connection event. Peripheral node 150 may send a request to change the operating frequency embedded in a packet in the first set of packets. And, or alternatively, peripheral node 150 may be configured to send the request to change the operating frequency as a message separate from the first set of packets. The request may include a first indication of the new operating frequency and / or a second indication of the timing of transitioning to the new operating frequency during a later connection event.

[0067] Referring to block 1230, the central node 110 optionally sends a response to the peripheral node 150 after receiving the request to change the operating frequency during the first connection event. The central node 110 may send the response to confirm that the central node 110 received the request to change the operating frequency. Through the response, the central node 110 may confirm the new operating frequency and / or confirm the timing of transitioning to the new operating frequency. The central node 110 may send the response as part of a 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, wherein the second operating frequency is different from the first operating frequency. The nodes 110 and 150 exchange the second packet in a second connection event subsequent to the first connection event. The second packet may be a set of second packets exchanged between the nodes 110 and 150 at the beginning of the second connection event (e.g., Figure 8 Portions of packages 842-847) shown in FIG.

[0069] Referring to block 1250, the central node 110 exchanges a third packet encoded at a third operating frequency with the peripheral node 150, wherein 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 the nodes 110 and 150 during the first connection event. The nodes 110 and 150 exchange the third packet after switching to the third operating frequency and before the second connection event ends. Therefore, the nodes 110 and 150 use two different operating frequencies during the second connection event.

[0070] Fig.13 1 is a flow chart of a method 1300 for extending the duration of a connection event according to some aspects of the present specification. Some processes of the method 1300 may be performed in an order different from the order described, and many processes may be performed in parallel. In addition, in some examples of the present specification, processes of the method 1300 may be omitted or replaced. Figure 1 The central node 110 shown in FIG. 1 describes the method 1300, but Figure 1 Other components shown in FIG. 1 , such as peripheral node 150 , may illustrate similar techniques.

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

[0072] Referring to block 1320, the central node 110 exchanges a first set of packets with the peripheral node 150 during a first connection event. The nodes 110 and 150 may begin exchanging the first set of packets at the beginning 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 may embed the request within a packet in the first set of packets. Also, or alternatively, the central node 110 may be configured to send the request as a message separate from other packets in the first set of packets.

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

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

[0075] The longer duration may allow for increased throughput during the first connection event without the overhead of terminating the first connection event and thereafter initiating a second connection event. As noted above, although methods 900, 1000, 1100, 1200, and 1300 have been described as being performed by central node 110, peripheral node 150 may also be configured to perform methods 900, 1000, 1100, 1200, and / or 1300.

[0076] This description attributes functionality to nodes 110 and 150. Nodes 110 and 150, transceiver circuits 130 and 170, and processing circuits 140 and 180 may include one or more processors. Nodes 110 and 150, transceiver circuits 130 and 170, and processing circuits 140 and 180 may include any combination of integrated circuits, discrete logic circuits, analog circuits (e.g., 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 circuits 130 and 170, and processing circuits 140 and 180 may include multiple components, such as any combination of the processing resources listed above, as well as other discrete or integrated logic circuits, and / or analog circuits.

[0078] The techniques described in this specification may also be embodied or encoded in an article of manufacture that includes a non-transitory computer-readable storage medium. Example 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 propagating signal. In some examples, a non-transitory storage medium may store data that may change over time (e.g., in RAM or cache).

[0079] In this specification, the term "coupled" may encompass connections, communications, or signal paths that enable a functional relationship consistent with this specification. For example, if device A generates a signal to control device B to perform an action, then: (a) in a first instance, device A is coupled to device B through a direct connection; or (b) in a second instance, device A is coupled to device B through an intermediate component C, provided that the intermediate component C does not change the functional relationship between device A and device B, so that device B is controlled by device A via the control signal generated by device A.

[0080] This specification provides several examples and the modifications are possible for these examples. Such modifications are clearly within the scope of this specification. In addition, the application of these teachings to other environments, applications and / or purposes is consistent with this specification and is contemplated by this specification.

Claims

1. A method comprising: sending, by the first node to the second node, a request to change a current operating frequency during the first connection event, wherein the request is encoded in the first operating frequency; as well as sending, by the first node to the second node, a first packet encoded at a second operating frequency during the first connection event, The second operating frequency is different from the first operating frequency. 2 . The method of claim 1 , further comprising receiving, at the first node, a response to the request from the second node during the first connection event, wherein the response is encoded at the first operating frequency. 3 . The method of claim 1 , wherein the request is a first request, the method further comprising sending, by the first node to the second node during the first connection event, a second request to extend a duration of the first connection event.

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

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

6. The method of 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 of 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 of claim 1, further comprising generating the request including an indication of a time for the first and second nodes to change the current operating frequency, Wherein sending the first packet occurs after the time of changing the current operating frequency.

9. The method according to claim 1, further comprising: generating a second packet before sending the request; as well as embedding the request in the second packet, Wherein sending the request comprises sending the second packet and the embedded request to the peripheral node during the first connection event.

10. The method according to claim 1, wherein the first connection event is a Bluetooth low energy connection event. The method of claim 1 , wherein sending the first packet occurs before the first connection event ends.

12. The method of claim 1, further comprising generating the request including an indication of the second operating frequency.

13. The method of claim 1, further comprising determining the second operating frequency based on a predefined set of channels.

14. An apparatus comprising: transceiver circuit; as well as A processing circuit configured to: generating a request to change a current operating frequency during a first connection event; causing the transceiver circuit to transmit the request encoded at a first operating frequency; generating a first packet after causing the transceiver circuit to transmit the request; and causing the transceiver circuit to transmit the first packet encoded at a second operating frequency during the first connection event, The second operating frequency is different from the first operating frequency.

15. The device according to claim 14, wherein the request is a first request, and Wherein the processing circuit is further configured to cause the transceiver circuit to send, during the first connection event, a second request to extend a duration of the first connection event.

16. The device according to claim 14, wherein the processing circuit is further configured to generate the request including an indication of a time for the first and second nodes to change the current operating frequency, and Wherein the processing circuit is configured to cause the transceiver circuit to send the first packet after the time of changing the current operating frequency.

17. The device of claim 14, wherein the processing circuit is further configured to generate the request to include an indication of the second operating frequency.

18. A non-transitory computer-readable medium having executable instructions stored thereon, the executable instructions configured to be executable by a processing circuit for causing the processing circuit to: generating a request to change a current operating frequency during a first connection event; causing the transceiver circuit to transmit the request encoded at a first operating frequency; generating a first packet after causing the transceiver circuit to transmit the request; as well as causing the transceiver circuit to transmit the first packet encoded at a second operating frequency during the first connection event, The second operating frequency is different from the first operating frequency.

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

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

Images