Advanced Dual-Band Virtual Parallelism for Wi-Fi

Abstract

This invention is entitled "Advanced Dual-Band Virtual Parallelism for WiFi". Exemplary methods for advanced DBVC for WiFi involve one or more of the following: avoiding beacon collisions between a repeater and a root AP; optimizing traffic flow based on buffers queued in hardware; optimizing TCP throughput through DPI and priority ordering of TCP ACK packets; or optimizing transmission through a trigger-based mechanism. An exemplary method may include receiving a transmission from a root AP. The method may include obtaining from the transmission the next root AP TBTT for the next beacon to be sent by the root AP. The method may include determining an amount of time to delay the next repeater TBTT for the next beacon to be sent by the repeater to avoid collisions between the next root AP TBTT and the next repeater TBTT. The method may include delaying the next repeater TBTT based on the determined amount of time.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit and priority of U.S. Provisional Application No. 62 / 890,970, filed August 23, 2019, entitled “METHODS AND SYSTEMS TO OPTIMIZE DBVC PERFORMANCE FORTHROUGHPUT AND STABILITY”, and U.S. Provisional Application No. 62 / 969,229, filed February 3, 2020, entitled “ADVANCED DUAL BAND VIRTUAL CONCURRENTFOR WIFI NETWORKS”. Both Provisional Applications 62 / 890,970 and 62 / 969,229 are each incorporated herein by reference in their entirety. Technical Field

[0003] The specific implementation discussed in this article involves advanced dual-band virtual parallelism (DBVC) for WiFi. Background Technology

[0004] Unless otherwise indicated, the information described in this disclosure is not prior art to the claims of this application and is not admitted to be prior art simply because it is included in this section.

[0005] DBVC for WiFi (sometimes also called Virtual Parallel Dual-Band (VCDB)) is a Time Division Multiple Access (TDMA) protocol typically applied on top of WiFi connections to provide dual-band operation on devices containing only a single radio. The DBVC protocol works by dividing time into open-channel and closed-channel periods to support both Access Point (AP) and Station of Station (STA) roles in the network. More specifically, a repeater in a WiFi network can serve clients or downlinks during the open-channel period, during which it acts as an AP and is therefore referred to as a repeater AP when in this role. Furthermore, the repeater can serve the uplink or root AP during the closed-channel period, during which it acts as a STA and is therefore referred to as a repeater STA when in this role.

[0006] Issues associated with DBVC operation include scheduling problems, performance optimization in time-division networks, and timing / resource conflicts that can lead to link instability. Additional problems may arise when interoperating with various third-party devices, such as traditional WiFi clients, which may not support standards-specific and proprietary operations used to provide a seamless WiFi experience. The overall goal of a DBVC system is to reduce the total cost of WiFi systems, such as industrial repeaters, by eliminating the need for two separate physical radios in a given frequency band, while providing optimal support for traditional devices that do not support more advanced channel management features such as Channel Switching Announcement (CSA).

[0007] The subject matter claimed in this disclosure is not limited to addressing any shortcomings or specific implementations that operate only in environments such as those described above. Rather, this background is provided merely to illustrate an example technical field in which some of the specific implementations described in this disclosure may be practiced. Summary of the Invention

[0008] In one implementation, a method may include receiving a transmission from a root AP via a repeater configured to communicate according to the DBVC protocol. The method may include obtaining from the transmission the Next Root AP Target Beacon Transmission Time (TBTT) of the next beacon to be transmitted by the root AP. The method may include determining an amount of time to delay the Next Repeater TBTT of the next beacon to be transmitted by the repeater to avoid a conflict between the Next Root AP TBTT and the Next Repeater TBTT. The method may include delaying the Next Repeater TBTT based on the determined amount of time.

[0009] In another embodiment, a method may include determining the load on an upstream buffer within a repeater configured to communicate according to the DBVC protocol. The load on the upstream buffer may correspond to data to be transmitted within an upstream network. The method may include determining the load on a downstream buffer within the repeater corresponding to the data to be transmitted within a downstream network. The method may include determining whether to adjust the DBVC duty cycle of the repeater based on the load on the upstream buffer and the load on the downstream buffer. The method may include adjusting the DBVC duty cycle of the repeater.

[0010] In another embodiment, a method may include determining that a first wireless communication device intends to transmit traffic to a second wireless communication device during a period when the second wireless communication device, configured to communicate according to the DBVC protocol, is not operating on a first channel. The method may include switching to a second channel. The method may include providing a trigger frame to the second wireless communication device on the second channel. The method may include receiving an acknowledgment (ACK) frame from the second wireless communication device. The ACK frame may be sent to the first wireless communication device via the second wireless communication device in response to receiving the trigger frame. The method may include transmitting data to the second wireless communication device on the second channel. The method may include transmitting an end frame to the second wireless communication device on the second channel. The method may include switching back to the first channel in response to transmitting the end frame.

[0011] In another specific implementation, a method may include performing deep packet inspection (DPI) at a repeater configured to communicate according to the DBVC protocol to observe the Transmission Control Protocol (TCP) connection through the repeater and the TCP window size of the TCP connection. The method may include setting or adjusting the repeater's open / close channel dwell time based on the TCP window size of the TCP connection. Attached Figure Description

[0012] The specific implementation of the example will be described and explained with additional features and details using the accompanying drawings, wherein:

[0013] Figure 1 This is a block diagram of an exemplary operating environment for implementing the DBVC protocol;

[0014] Figure 2 An exemplary sequence is shown to avoid beacon collisions between the repeater and the root AP;

[0015] Figure 3 A flowchart illustrating an exemplary method for avoiding TBTT conflicts is provided.

[0016] Figure 4A The illustration shows an exemplary sequence of transmission optimizations using a trigger-based mechanism when repeaters and root APs are configured to be optimized via a trigger-based mechanism.

[0017] Figure 4B The illustration shows another exemplary sequence of transmission optimization using a trigger-based mechanism when repeaters and root APs are configured to be optimized via a trigger-based mechanism.

[0018] Figure 5 A flowchart illustrating an exemplary method for optimizing transmission through a trigger-based mechanism is provided.

[0019] Figure 6A flowchart illustrating an exemplary method for optimizing traffic flow based on buffers queued within the hardware of a repeater or other STA configured to communicate according to the DBVC protocol; and

[0020] Figure 7 A flowchart illustrating an exemplary method for optimizing TCP throughput through the DPI and priority ordering of TCP ACK packets is provided. Detailed Implementation

[0021] Some of the specific implementations described in this paper address one or more issues typically associated with DBVC operation in WiFi networks, such as scheduling problems, performance optimization in time-division networks, timing / resource conflicts that can lead to link instability, and interoperability with third-party devices. These and other specific implementations can be implemented by repeaters configured to communicate according to the DBVC protocol.

[0022] For example, some exemplary implementations avoid beacon collisions between the repeater and the root AP. In this example and others, the repeater can obtain the root AP's TBTT, determine the amount of time to delay the repeater's TBTT to avoid a collision between the repeater's TBTT and the root AP's TBTT, and delay the repeater's next TBTT based on the determined amount of time.

[0023] Some exemplary implementations can optimize traffic flow based on buffers queued within the hardware. In this example and others, the repeater may have both an upstream buffer and a downstream buffer. The repeater can determine the load on the upstream buffer, which indicates the data to be transmitted within the upstream network (e.g., on a closed channel on the uplink). The repeater can also determine the load on the downstream buffer, which indicates the data to be transmitted within the downstream network (e.g., on an open channel on the downlink). The repeater can then determine the amount of adjustment to the repeater's DBVC duty cycle based on the load on the upstream and downstream buffers, and can adjust the DBVC duty cycle accordingly.

[0024] Some exemplary implementations can optimize TCP throughput through the DPI and priority ordering of TCP ACK packets. In this and other examples, the repeater can perform DPI to observe the TCP connections passing through the repeater and the TCP window size of that TCP connection. Additionally, the repeater can set or adjust its on / off channel dwell time based on the TCP window size of that TCP connection. As a specific example, the repeater can set or adjust its on / off channel dwell time to a relatively long time in response to a relatively large average TCP window size. As another specific example, the repeater can set or adjust its on / off channel dwell time to a relatively short time in response to a relatively small average TCP window size. As yet another specific example, the repeater can set or adjust its on / off channel dwell time to a relatively short time in response to a relatively large average TCP window size to control TCP flow. Alternatively or additionally, the repeater can merge TCP ACK packets to reduce overhead.

[0025] Some exemplary implementations may optimize transmission using a trigger-based mechanism when repeaters and root APs are configured to do so. In this example and others, a first AP (e.g., a root AP or a repeater acting as a repeater AP) may determine that it will transmit traffic to a second AP according to the DBVC protocol during a period when a second AP (e.g., a repeater acting as a repeater AP or a root AP) is not operating on the first channel. The first AP may switch to the second channel. The first AP may provide a trigger frame to the second AP. The first AP may determine, in response to the trigger frame, to receive an ACK frame from the second AP. The first AP may transmit data to the second AP on the second channel. The first AP may transmit an end frame to the second AP. Finally, the first AP may switch back to the first channel in response to transmitting the end frame.

[0026] These and other specific embodiments of this disclosure will be illustrated with reference to the accompanying drawings. It will be understood that the drawings are illustrations and schematic representations of these exemplary embodiments and are not limiting, nor are they necessarily drawn to scale. In the drawings, features with the same numerals indicate the same structure and function, unless otherwise described.

[0027] Figure 1This is a block diagram of an exemplary operating environment 100 for implementing the DBVC protocol. Operating environment 100 may include a root AP 102, a repeater 104, a first client device 106, and a second client device 108. Root AP 102, repeater 104, first client device 106, and second client device 108 are all examples of wireless communication devices. Repeater 104 may be or includes an AP. Alternatively or additionally, repeater 104 may be or includes a STA. Generally, repeater 104 may be configured to receive a signal from root AP 102 on uplink 110 during channel shutdown and to provide (e.g., relay) that signal on downlink 112 to one or more of first client device 106 and second client device 108 during channel activation. Additionally, repeater 104 can be configured to receive signals from one or both of the first client device 106 and the second client device 108 on downlink 112 during channel open, and to provide (e.g., relay) those signals to root AP 102 on uplink 110 during channel closed. When receiving signals from or providing signals to root AP 102 on uplink 110, repeater 104 operates as a client device or STA and may be referred to as a repeater STA. When receiving signals from or providing signals to one or both of the first client device and the second client device 106, 108 on downlink 112, repeater 104 operates as an AP and may be referred to as a repeater AP.

[0028] In some embodiments, repeater 104 may include a repeater STA side (e.g., a repeater STA interface) and a repeater AP side (e.g., a repeater AP interface). In these and other embodiments, repeater 104 may operate as both a repeater STA and a repeater AP. Alternatively or additionally, repeater 104 may be configured to perform one or more of the methods or operations described herein.

[0029] The root AP 102 and repeater 104 may implement the IEEE 802.11 standard, a contention-based standard for handling communication between multiple competing devices over a shared wireless communication medium on a selected of multiple communication channels. The frequency range of each communication channel is specified in the corresponding protocol of the implemented IEEE 802.11 protocol, such as "a", "b", "g", "n", "ac", "ad", "ax". Additionally, the root AP 102, repeater 104, first client device 106, and second client device 108 may communicate using the DBVC protocol. The DBVC protocol may include a disabled channel switching protocol.

[0030] The DBVC protocol allows repeater 104 or root AP 102 to include a single radio while supporting multiple modes on multiple channels. For example, root AP 102 may be connected to repeater 104 on a first channel (referred to herein as an AP channel or a closed channel), as this first channel is generally the channel used by repeater 104 during the closed channel duration. Furthermore, repeater 104 may be connected to first client device 106 or second client device 108 on a second channel (referred to herein as a repeater channel or an open channel), as this second channel is generally the channel used by repeater 104 during the open channel duration. Therefore, repeater 104 may include a single radio capable of communicating on both the AP or closed channel and the repeater or open channel. In some implementations, repeater 104 may switch between channels to simultaneously maintain links (e.g., uplink 110 and downlink 112) with root AP 102, first client device 106, or second client device 108. The duty cycle of each element in the channel can be adjusted based on the service or link type.

[0031] The DBVC protocol enables repeater 104 or root AP 102 to operate in an on / off channel mode. During the on channel period, some time is spent serving clients (e.g., STAs of the repeater AP such as first client devices and second client devices 106, 108) on downlink 112, and some time is spent serving root AP 102 on uplink 110 during the off channel period. The DBVC protocol is a TDMA-type protocol typically used on top of WiFi connections to provide dual-band operation on devices such as repeater 104 that contain only a single radio in a given frequency band (e.g., 2.4 GHz, 5 GHz, or 6 GHz). Other implementations may use licensed spectrum and operate in higher or lower frequency ranges (e.g., 27 GHz, 30 GHz). The DBVC protocol works by dividing time into on channel and off channel periods to support both AP and STA roles at repeater 104 or other DBVC-enabled devices in operating environment 100.

[0032] In some implementations, to communicate using the DBVC protocol, repeater 104 can separate root AP 102, first client device 106, or second client device 108 into different groups associated with different channels. In other implementations, repeater 104 can designate a specific channel as a VIP channel. In these and other implementations, repeater 104 can assign a VIP device (e.g., one or more of root AP 102, first client device 106, or second client device 108) to use that VIP channel for communication. In other implementations, repeater 104 can separate root AP 102, first client device 106, or second client device 108 into different groups based on device characteristics. These characteristics may include one or more of support (or lack thereof) for CSA, PHY mode, or Low Received Signal Strength Indicator (RSSI). Repeater 104 can switch between channels to communicate with root AP 102, first client device 106, or second client device 108 on different channels. As used in this disclosure, the phrase "switching between channels" means that repeater 104 or root AP 102 can cause a radio to disable its ability to communicate on one channel (e.g., a closed channel) while enabling its ability to communicate on another channel (e.g., an open channel). For example, repeater 104 can switch between an AP or a closed channel and a repeater or an open channel by causing a radio to disable its ability to communicate on an AP channel and enable its ability to communicate on a repeater channel.

[0033] Figure 2 The diagram is used to avoid communication between the repeater and the root AP (such as in...). Figure 1 An exemplary sequence 200 of beacon collisions (between repeater 104 and root AP 102). More specifically, Figure 2 An exemplary current relative alignment is illustrated between the root AP's TBTT schedule 202 (hereinafter referred to as "root AP TBTT schedule 202") and the repeater's current TBTT schedule 204 (hereinafter referred to as "current repeater TBTT schedule 204"). Figure 2 An exemplary adjusted relative alignment is also illustrated between the root AP TBTT schedule 202 and the new or adjusted TBTT schedule 206 of the repeater (hereinafter referred to as "new repeater TBTT schedule 206").

[0034] exist Figure 2In the diagram, a solid vertical line intersecting one of the given TBTT schedules 202, 204, and 206 indicates the TBTT of the root AP or repeater transmitting the beacon at that time according to the corresponding TBTT schedule 202, 204, and 206. For example, solid vertical line 208 intersecting the root AP TBTT schedule 202 at 110 milliseconds (ms) indicates the 110ms TBTT of the root AP transmitting its next beacon at that time according to the root AP TBTT schedule 202. Similarly, solid vertical line 210 intersecting the current repeater TBTT schedule 204 at 105ms indicates the 105ms TBTT of the repeater transmitting its next beacon at that time according to the current repeater TBTT schedule 204. Similarly, the solid vertical line 212 intersecting the new repeater TBTT schedule 206 at 185ms indicates that at that time, the repeater is scheduled to transmit the next beacon of the repeater at 185ms TBTT according to the new repeater TBTT schedule 206.

[0035] therefore, Figure 2 The diagram illustrates scheduling the next TBTT (hereinafter referred to as "Next Root AP TBTT") of the root AP in Root AP TBTT Schedule 202 for 110ms along the exemplary timeline 214. More generally, the TBTT of the root AP in Root AP TBTT Schedule 202 in this example can be scheduled at time 110ms + N*Δ root beacon, where N is an integer and Δ root beacon is the beacon interval of the root AP (hereinafter referred to as "Root AP Beacon Interval"). Therefore, if the root AP beacon interval is 100ms, then in this example, the TBTT of the root AP in Root AP TBTT Schedule 202 can be scheduled for 110ms, 210ms, 310ms, etc. Figure 2 The root AP TBTT following the next root AP TBTT shown in the figure can be referred to as the subsequent root AP TBTT (e.g., for any root AP TBTT following the next root AP TBTT scheduled for 110ms).

[0036] Figure 2 The diagram also illustrates scheduling the next TBTT (hereinafter referred to as "Next Current Repeater TBTT") of the repeater in the current repeater TBTT schedule 204 for 105 ms along timeline 214. More generally, this can be done at time 105 ms + N*Δ. 中继器信标 The current repeater TBTT schedule 204 in this example is arranged to schedule the TBTT of the repeater, where N is an integer and Δ 中继器信标This refers to the repeater's beacon interval (hereinafter referred to as the repeater beacon interval). Therefore, if the repeater beacon interval is 100ms, then in this example, the repeater's TBTT in the current repeater TBTT schedule 204 can be scheduled for 105ms, 205ms, 305ms, etc. Figure 2 The current repeater TBTT following the next current repeater TBTT shown in the figure can be referred to as the subsequent current repeater TBTT (e.g., for any current repeater TBTT following the next current repeater TBTT scheduled for 105ms).

[0037] At least in part, because the first time amount 216 of the repeater performing the DBVC channel shutdown operation is greater than the difference between the 105ms TBTT of the next current repeater TBTT and the 110ms TBTT of the next root AP TBTT, the relative alignment between the root AP TBTT schedule 202 and the current repeater TBTT schedule 204 causes a conflict between the next root AP TBTT and the next current repeater TBTT. If the beacon intervals of the root AP and the repeater are the same (e.g., 100ms each), similar conflicts will exist between each subsequent pair of root AP TBTT and repeater TBTT.

[0038] Therefore, the specific implementation described herein can adjust the next repeater TBTT and / or one or more subsequent repeater TBTTs to avoid such TBTT conflicts. For example, such as Figure 2 The diagram illustrates that the next current repeater TBTT in the current repeater TBTT schedule 204, scheduled for 105ms, can be delayed by an amount of time 220, such that the next current repeater TBTT is scheduled at (for example) 185ms. This next current repeater TBTT is depicted as the next new repeater TBTT in the new repeater TBTT schedule 206. Subsequently, in this example, the TBTT of the repeater in the new repeater TBTT schedule 206 can be scheduled at time 185ms + N*Δ repeater beacon. Therefore, if the repeater beacon interval is 100ms, then in this example, the TBTT of the repeater in the new repeater TBTT schedule 206 can be scheduled for 185ms, 285ms, 385ms, etc. Figure 2 The new repeater TBTT following the next new repeater TBTT shown in the figure can be referred to as the subsequent new repeater TBTT (e.g., for any new repeater TBTT following the next new repeater TBTT scheduled for 185ms).

[0039] Consistent with the above content, Figure 3A flowchart illustrating an exemplary method 300 for avoiding TBTT conflicts is provided. Method 300 can be performed by any suitable system, device, or apparatus. For example, any of the root APs or repeaters described herein can perform or direct the performance of one or more of the operations associated with method 300. Method 300 may include one or more of blocks 302, 304, 306, or 308. Method 300 may begin at block 302.

[0040] At box 302, method 300 may include receiving transmissions from the root AP via a repeater configured to communicate according to the DBVC protocol. Box 304 may follow box 302.

[0041] At box 304, method 300 may include obtaining from the transmission the next root AP TBTT of the next beacon to be sent by that root AP. For example, Figure 2 The repeater can obtain the next root AP TBTT (Teleport Time To Beamed) of the next beacon to be sent by the root AP from the transmission received by the repeater from the root AP, for example, 110ms. Box 306 may follow box 304.

[0042] At box 306, method 300 may include determining an amount of time to delay the next repeater TBTT of the next beacon to be transmitted by the repeater, in order to avoid a conflict between the next root AP TBTT and the next repeater TBTT. For example, Figure 2 The repeater can determine the amount of time 220 that will delay the next current repeater TBTT of the next beacon to be transmitted by the repeater, in order to avoid a conflict between the next root AP TBTT and the resulting next new repeater TBTT. Box 308 may follow box 306.

[0043] At box 308, method 300 may include delaying the next repeater TBTT based on the determined amount of time. For example, Figure 2 The repeater can delay the next current repeater TBTT of the current repeater TBTT schedule 204 by a determined amount of time 220 to the next new repeater TBTT of the new repeater TBTT schedule 206, or additionally delay the next current repeater TBTT to the next new repeater TBTT based on the determined amount of time.

[0044] Although illustrated by separate boxes, steps and operations associated with one or more of the boxes in method 300 may be divided into additional boxes, combined into fewer boxes, or excluded, depending on the specific implementation. Alternatively or additionally, method 300 may include additional boxes, steps, or operations.

[0045] For example, combined reference Figure 2 and Figure 3 Determining the amount of time to delay the next repeater TBTT at block 306 of method 300 may include some or all of the following: The repeater may determine the next repeater TBTT, for example, based on the current repeater TBTT schedule 204. In this example, the next repeater TBTT is the next current repeater TBTT at 105 ms. The repeater may determine or otherwise obtain the repeater beacon interval. In this example, the repeater beacon interval is 100 ms. The repeater may determine the first amount of time 216 for the repeater to perform DBVC channel shutdown operation. Figure 2 In the example, the first time value 216 is 10 ms. The repeater then determines a second time value 218 that will cause the next repeater TBTT to avoid occurring during the repeater's DBVC channel shutdown operation. Figure 2 In the example, the second time value is 15ms. The repeater can sum the next root AP TBTT (110ms) and the repeater beacon interval (100ms) to generate an intermediate sum (110ms + 100ms = 210ms). The repeater can then subtract the first time value 216 (10ms), the second time value 218 (15ms), and the next repeater TBTT (105ms) from this intermediate sum (210ms) to generate a difference (210ms – 10ms – 15ms – 105ms = 80ms) as the delay time value 220.

[0046] At block 308 of method 300, delaying the next repeater TBTT based on a determined time amount may include, for example, delaying the next repeater TBTT by the determined time amount by adding the repeater beacon interval (e.g., the initial repeater beacon interval) from the previous repeater TBTT to the next repeater TBTT. For example, as... Figure 2 The diagram illustrates that the next current repeater TBTT, which is 105 ms in the current repeater TBTT schedule 204, can be delayed by a determined time amount 220 (e.g., 80 ms) to the next new repeater TBTT, which is 185 ms in the new repeater TBTT schedule 206. After the next new repeater TBTT, the repeater can then change the repeater beacon interval back to the original repeater beacon interval. Alternatively, delaying the next repeater TBTT based on the determined time amount may include delaying the next repeater TBTT by a portion of the determined time amount; the repeater may then delay one or more other portions of the determined time amount for one or more subsequent repeater TBTTs, wherein the sum of all such portions of the determined time amount equals the determined time amount.

[0047] Alternatively or additionally, method 300 or other specific embodiments described herein may include setting the repeater beacon interval to a value different from the root AP beacon interval. In such embodiments, at least some repeater TBTTs may be out of phase with the root AP TBTT to avoid TBTT collisions at least some time, but not necessarily all time. For example, suppose the repeater beacon interval is 130 ms and the first repeater TBTT is at 5 ms, such that the first five repeater TBTTs are at 5 ms, 135 ms, 265 ms, 395 ms, and 525 ms. Also suppose the root AP beacon interval is 100 ms and the first root AP TBTT is at 50 ms, such that the first six root AP beacon intervals are at 50 ms, 150 ms, 250 ms, 350 ms, 450 ms, and 550 ms. In this example, the repeater TBTTs at at least 5 ms, 395 ms, and 525 ms may be sufficiently out of phase with the nearest corresponding root AP TBTT to avoid collisions.

[0048] Alternatively or additionally, method 300 may include setting the repeater beacon interval to be equal to the root AP beacon interval when the repeater beacon interval and the root AP beacon interval are no longer equal, or confirming that the repeater beacon interval is equal to the root AP beacon interval. When the repeater beacon interval is equal to the root AP beacon interval by a determined amount of time relative to the next root AP TBTT, this ensures that all subsequent repeater TBTTs are out of phase with all subsequent root AP TBTTs, thereby avoiding collisions.

[0049] Some of the specific implementations described in this paper can be alternatively or additionally optimized for transmission through trigger-based mechanisms. Figure 4A The illustration shows an exemplary sequence 400A used to optimize transmission via a trigger-based mechanism when the repeater and root AP are configured to be optimized via a trigger-based mechanism. Figure 4A Specifically, a first wireless communication device 402 (hereinafter referred to as "first device 402") and a second wireless communication device 404 (hereinafter referred to as "second device 404") are illustrated, one or both of which can be configured to communicate according to the DBVC protocol. In one example, the first device 402 includes a root access point (AP) and the second device 404 includes a repeater. In another example, the first device 402 includes a repeater and the second device 404 includes a root access point (AP).

[0050] The first device 402 can be configured to communicate simultaneously or selectively on the first channel 406 and the second channel 408. Similarly, the second device 404 can be configured to communicate simultaneously or selectively on the first channel 406 and the second channel 408. For example, if the second device 404 is a repeater implementing the DBVC protocol, the second device 404 can be configured to communicate selectively on the first channel 406 or the second channel 408, wherein the first channel 406 is the off channel (or on channel) of the second device and the second channel 408 is the on channel (or off channel) of the second device.

[0051] Generally, and according to the DBVC protocol, one or both of the first or second devices 402, 404 can be configured to alternately communicate on the first and second channels 406, 408 within a predetermined interval on each channel 406, 408, before switching to another channel. This predetermined interval may be the same for each channel 406, 408 or may differ between channels 406, 408 and the other. Alternatively or additionally, this predetermined interval may be adjusted from one switching cycle to the next, but it is generally fixed in duration at the beginning of the interval.

[0052] Given the foregoing, when the first device or the second device 402, 404 is on one of channels 406, 408, the device may generally not be able to communicate on the other channel 406, 408 until the device completes its current interval and switches to another channel. Now suppose the first device and the second device 402, 404 are on different channels 406, 408, but the first device 402 (or the second device 404) determines (e.g., by checking the device's buffer) that data for the second device 404 (or the first device 402) is accumulating at the first device 402. Some existing systems require the first device 402 to wait until the second device 404 completes its interval on its current channel (e.g., second channel 408) and switches to the same channel as the first device 402 (e.g., first channel 406), after which the first device 402 can transmit the data accumulated there to the second device 404. However, the specific implementation described herein is based on a triggering mechanism to allow the first device 402 to transmit data to the second device 404 without waiting for the second device 404 to complete its interval and switch to the same channel as the first device 402.

[0053] exist Figure 4AIn the example illustrated, for instance, first device 402 communicates on first channel 406, while second device 404 communicates on second channel 408. If first device 402 decides to communicate with second device 404 without waiting for second device 404 to complete its current interval and switch back to first channel 406, first device 402 may switch to second channel 408 and provide a trigger frame 410 to second device 404 on second channel 408. Second device 404 may receive trigger frame 410 and, in response to trigger frame 410, send ACK frame 412 to first device 402 on second channel 408. ACK frame 412 may acknowledge to first device 402 that trigger frame 410 was received at second device 404 and signal readiness to communicate with first device 402 on second channel 408. First device 402 may receive ACK frame 412 from second device 404. After receiving or in response to receiving an ACK frame, the first device 402 may transmit first data 414 to the second device 404 on the second channel 408. After transmitting the first data 414, the first device 402 may transmit an end frame 416 to the second device 404 on the second channel 408. The second device 404 may receive the end frame 416 and, in response to the end frame, send an ACK frame 418 to the first device 402 on the second channel 408. The ACK frame 418 may acknowledge to the first device 402 that the end frame 416 has been received at the second device 404. After transmitting the end frame 416 or receiving the ACK frame 418, or in response to such transmission or reception, the first device 402 may switch back to the first channel 406.

[0054] In some implementations, the first device 402 may avoid a TBTT (Block Time To Watch) when transmitting the trigger frame 410 and / or when transmitting the first data 414. For example, the first device 402 may determine its next TBTT and transmit the trigger frame 410 only if there is sufficient time to transmit it, and optionally transmit the first data 414 before the next TBTT of the first device 402. Alternatively or additionally, the dwell time, such as duration or interval, of the first device 402 on the second channel 408 may be determined based on the predetermined size of the first data 414 in the buffer of the first device 402 for the second device 404 and / or whether other clients are connected and whether there is traffic.

[0055] like Figure 4AFurther illustration shows that the second device 404 can send the second data 420 to the first device 402. In this example, the second device 404 can switch from the second channel 408 to the first channel 406 and send a trigger frame 422 to the first device 402 on the first channel 406. The second device 404 can send an end frame 424 to the first device 402 on the first channel 406 when it has completed the transmission of the second data 420. In this and other embodiments, the second device 404 can begin transmitting the second data 420 as a normal power-saving client by sending a QoS data null frame with the power management bits changed. The second device 404 can then switch back to the second channel 408 after transmitting the end frame 424 and / or after the dwell time or interval for the second device 404 on the first channel 406 has been completed.

[0056] Figure 4B The illustration shows another exemplary sequence 400B used to optimize transmission via a trigger-based mechanism when the repeater and root AP are configured to be optimized via a trigger-based mechanism. Figure 4B The first device 402 and the second device 404 are specifically illustrated.

[0057] There is a possibility that the first device 402 and the second device 404 may switch to opposite channels simultaneously or substantially simultaneously, for example, when attempting to communicate with each other. Therefore, some specific implementations described herein may, for example, switch the first device 402 (or the second device 404) back to another channel relatively quickly in response to a certain number of trigger frames (such as 10 trigger frames) being sent to the second device 404 (or the first device 402) without receiving any ACK frames. By switching back relatively quickly, the first device 402 may "meet" the second device 404 in the channel to which it was last switched, even though the first device 402 has recently been switched to the opposite channel.

[0058] For example, along Figure 4BAt approximately 0 ms along the exemplary timeline 426, the first device 402 may switch to or is already in the second channel 408, while the second device 404 may switch to or is already in the first channel 406. At approximately 10 ms along timeline 426, the first device 402 may send a trigger frame 428A to the second device 404 on the second channel 408. If the first device 402 does not receive an ACK frame from the second device 404, the first device 402 may send one or more additional trigger frames 428B to the second device 404 on the second channel 408, wherein each of the one or more additional trigger frames 428B may be sent in response to the lack of an ACK frame for the previous trigger frame 428A or 428B. Trigger frames 428A and 428B are collectively referred to herein as "trigger frame 428". In response to sending a specific number of trigger frames 428 (such as ten trigger frames 428) to the second device 404 on the second channel 408 without receiving any ACK frames, the first device 402 may, as follows: Figure 4B At point 430, approximately 13 ms along timeline 426, the system switches to the first channel 406.

[0059] The first device 402 and the second device 404 can then communicate with each other on the first channel 406, for example, by exchanging third data 432 on the first channel 406. When the first device 402 is a root AP and the second device 404 is a repeater, the data exchange of the third data 432 can be initiated by the second device 404 by sending a data frame with power management bit = 0. Alternatively, this data exchange can be initiated by the first device 402 sending one or more trigger frames to the second device 404 and receiving ACK frames from the second device 404.

[0060] As specified at 434, at approximately 40 ms along timeline 426, the second device 404 may switch back to the second channel 408. For example, the second device 404 may have completed its closed channel dwell time (e.g., its dwell time on the first channel 406), at which point the second device switches to its open channel, such as the second channel 408.

[0061] Some implementations can implement backoff or prioritization based on the channel shutdown trigger frame. In one implementation, a device with a lower MAC address and a Basic Service Set (BSS) can more aggressively switch back to the previous channel than another device to reduce the likelihood of a double handover. Figure 4BIn the example, for instance, the first device and the second device 402 can obtain each other's MAC addresses, and the first device or the second device 402, 404 with the lower MAC address can more aggressively switch back to the previous channel than the other device. For example, if the first device 402 has a lower MAC address and sends a trigger frame 428 to the second device 404 on the second channel 408 but does not receive any ACK frame from the second device 404, then the first device 402 can switch back to the first channel 406 after X seconds. Conversely, if the second device 404 has a higher MAC address and sends a trigger frame to the first device 402 on the first channel 406 but does not receive any ACK frame from the first device 402, then the second device 404 can switch back to the second channel 408 after Y seconds, where Y is greater than or significantly greater than X.

[0062] Alternatively or additionally, a random backoff scheme may be implemented to minimize or at least reduce the probability of a double handover in which the first and second devices 402, 404 miss each other. In this example, the amount of time each device 402, 404 waits before switching back to the previous channel after sending a trigger frame (or multiple trigger frames) to another device but not receiving any ACK frame from the other device may be random, in order to reduce the possibility that the two devices will switch channels simultaneously and miss each other again.

[0063] Consistent with the above content, Figure 5 A flowchart illustrating an exemplary method 300 for optimizing transmission via a trigger-based mechanism is provided. Method 300 can be performed by any suitable system, device, or apparatus. For example, any of the root APs or repeaters described herein can perform or direct the performance of one or more of the operations associated with method 500. Method 500 may include one or more of blocks 502, 504, 506, 508, 510, 512, or 514. Method 500 may begin at block 502.

[0064] At block 502, method 500 may include determining that a first wireless communication device (hereinafter “first device”) intends to transmit a service to a second wireless communication device (hereinafter “second device”) configured to communicate according to the DBVC protocol during a period when the second wireless communication device is not operating on the first channel. For example, Figure 2 The first device 402 can determine that it will transmit traffic to the second device 404 during a period when the second device 404 is not operating on the first channel 406. Block 504 may follow block 502.

[0065] At block 504, method 500 may include switching to a second channel. For example, first device 402 may switch from first channel 406 to second channel 408. Block 506 may follow block 504.

[0066] At block 506, method 500 may include providing a trigger frame to a second device on a second channel. For example, first device 402 may send trigger frame 410 to second device 404 on second channel 408. Block 508 may follow block 506.

[0067] At block 508, method 500 may include receiving an ACK frame from a second device on a second channel, the ACK frame being sent by the second device to the first device in response to the second device receiving a trigger frame. For example, the first device 402 may receive an ACK frame 412 on the second channel 408, wherein the second device 404 sends the ACK frame 412 in response to the second device 404 receiving a trigger frame 410. Block 510 may follow block 508.

[0068] At block 510, method 500 may include transmitting data to a second device on a second channel. For example, first device 402 may transmit first data 414 to second device 404 on second channel 408. Block 512 may follow block 510.

[0069] At block 512, method 500 may include transmitting an end frame to a second device on a second channel. For example, first device 402 may transmit an end frame 416 to second device 404 on second channel 408. Block 514 may follow block 512.

[0070] At block 514, method 500 may include switching to a first channel in response to a transmission end frame. For example, first device 402 may switch back to first channel 406 from second channel 408 in response to transmission end frame 416. Alternatively or additionally, first device 402 may switch back to first channel 406 in response to receiving ACK frame 418 from second device 404, ACK frame 418 being sent by second device 404 in response to receiving end frame 416.

[0071] Although illustrated by separate boxes, steps and operations associated with one or more of the boxes in method 500 may be divided into additional boxes, combined into fewer boxes, or excluded, depending on the specific implementation. Alternatively or additionally, method 500 may include additional boxes, steps, or operations.

[0072] For example, method 500 may further include the first device receiving a second trigger frame from the second device on the first channel, for example, according to the DBVC protocol and / or during a period when the first device is not operating on the second channel; the first device receiving data from the second device on the first channel; and the first device receiving a second end frame from the second device, wherein the second end frame indicates that the second device will switch to the second channel. For example, and referring to Figure 4A The first device 402 may receive a trigger frame 422 from the second device 404 on the first channel 406. The first device 402 may receive second data 420 from the second device 404 on the first channel 406, or more generally exchange second data 420 with the second device. The first device 402 may receive an end frame 424 from the second device 404, wherein the end frame 424 may indicate that the second device 404 is switching back to the second channel 408.

[0073] Alternatively or additionally, method 500 may include receiving a second ACK frame from the second device in response to an end frame. For example, the first device 402 may receive an ACK frame 418 from the second STA 404, which is sent to the first device 404 by the second device 404 in response to the second device 404 receiving an end frame 416 from the first device 402.

[0074] In some specific implementations, method 500 may include providing one or more other trigger frames on a second channel to a second device before providing the trigger frame; and determining that an ACK frame for the one or more other trigger frames has not yet been received from the second device, wherein the first device provides the trigger frame to the second device in response to determining that an ACK frame for the one or more other trigger frames has not yet been received from the second device. For example, suppose in Figure 4A Before sending trigger frame 410, first device 402 sends one or more other trigger frames to second device 404 on second channel 408 and does not receive any ACK frame from second device 404. First device 402 may continue to send trigger frames to second device 404 until first device 402 receives ACK frame 412 from second device 404, or until some other event occurs (e.g., first device 402 sends a certain number of trigger frames but does not receive any ACK frames).

[0075] Alternatively or additionally, method 500 may include switching to a second channel; providing a plurality of trigger frames to a second device on the second channel; determining that an ACK frame for any of the plurality of trigger frames has not yet been received from the second device; switching back to the first channel; and communicating with the second device on the first channel. For example, and referring to… Figure 4BFirst device 402 may switch to second channel 408 and send multiple trigger frames 428 to second device 404 on second channel 408. However, if second device 404 has switched to first channel 406, it will not receive any of the trigger frames 428 and therefore will not send any ACK frames. First device 402 may continue sending trigger frames 428 indefinitely, or it may stop sending trigger frames after sending a certain number of trigger frames (such as 10 trigger frames) without receiving any ACK frames from second device 404. Therefore, first device 402 may switch back to first channel 406. First device 402 may then communicate with second device 404 on first channel 406, for example, by exchanging third data 432 with second device 404 on first channel 406.

[0076] In some embodiments of method 500, the first device may include a root AP, and the second device may include a repeater configured to communicate with the root AP in an upstream network (e.g., on an uplink or closed channel) and with one or more client devices in a downstream network (e.g., on a downlink or open channel) in accordance with the DBVC protocol.

[0077] Some exemplary specific implementations in this article may alternatively or additionally be based on repeaters (such as...) Figure 1 The repeater 104 incorporates a queuing buffer within its hardware to optimize traffic flow. To facilitate understanding of how such specific implementations can be carried out in other operating environments and / or devices, [further details will be provided]. Figure 1 In this context, we describe the optimization of business flow based on buffers that queue within the hardware.

[0078] In this example and others, repeater 104 may have both an upstream buffer and a downstream buffer. The upstream buffer may buffer upstream traffic intended for root AP 102, or more generally for one or more root APs. The downstream buffer may buffer downstream traffic intended for one or more of first client device 106 or second client device 108, or more generally for one or more client devices. Repeater 104 may determine the load on the upstream buffer, which may indicate data to be transmitted to root AP 102 within the upstream network (e.g., on a closed channel on uplink 110). Repeater 104 may also determine the load on the downstream buffer, which may indicate data to be transmitted to one or more client devices (e.g., client devices 106, 108) within the downstream network (e.g., on an open channel on downlink 112). Repeater 104 may then determine the amount of adjustment to the DBVC duty cycle of repeater 104 based on the load on the upstream and downstream buffers, and may adjust the DBVC duty cycle accordingly.

[0079] The DBVC duty cycle may include the duty cycle for the enabled channel (hereinafter referred to as the "enabled channel duty cycle") and the duty cycle for the disabled channel (hereinafter referred to as the "disabled channel duty cycle"). The enabled channel duty cycle may include the ratio of the time spent on the enabled channel to the total time spent on both the enabled and disabled channels. Similarly, the disabled channel duty cycle may include the ratio of the time spent on the disabled channel to the total time spent on both the enabled and disabled channels.

[0080] Using a dynamic (e.g., adjustable) DBVC duty cycle can optimize for different traffic rates of repeater 104 or root AP 102. Traffic / data can be buffered based on each node or each access class (AC), which allows determining the total buffer queue length for both upstream and downstream buffers on repeater 104. Different factors for ACs can be referred to as "f(tid)" and can include f(VI) = 4; f(VO) = ​​3; f(BE) = 2; f(BK) = 1, where VI refers to video traffic / data, VO refers to voice traffic / data, BE refers to best-effort traffic / data, and BK refers to background traffic / data. Each of the f(tid) factors can be associated with or with the priority of the corresponding AC, for example, where the f(tid) factor of the VI AC is larger and therefore assigned a higher priority than the f(tid) factor of the VO AC, and so on, e.g., f(VI) = 4 > f(VO) = ​​3 > f(BE) = 2 > f(BK) = 1. The foregoing provides an example of AC, f(tid) factor, and associated priority. Other examples may include other ACs, other f(tid) factors, and / or other associated priorities.

[0081] If the buffer queue is incomplete, the size of the client-specific transmission buffer for repeater 104 can be determined according to the following formula:

[0082] Client_tx_buf_pkts=f(tid)*tid_pkts_number (Equation 1)

[0083] In Equation 1, Client_tx_buf_pkts can represent the client-specific repeater buffer size at repeater 104. For the purposes of Equation 1, root AP 102 can be considered a client of repeater 104. In Equation 1, f(tid) is defined above and tid_pkts_number is the number of packets of a given AC queued in the buffer at repeater 104 for the corresponding "client" (e.g., root AP 102, first client device 106, or second client device 108). The total downstream buffer size of repeater 104 can be the sum of the client-specific buffer sizes of the clients (e.g., first client device and second client device 106) with which repeater 104 communicates on the open channel. The total upstream buffer size of repeater 104 can be the client-specific buffer size of root AP 102.

[0084] If the buffer queue is full, the counter client_tx_buf_full can be incremented.

[0085] In some implementations, the buffer queue size can be determined whenever repeater 104 is about to send a packet. Alternatively or additionally, the duty cycle can be adjusted every 5 seconds or according to some other schedule, pattern, or arrangement based on the buffer queue size. In these and other implementations, the duty cycle can be determined and adjusted based on a followed algorithm or other suitable algorithm.

[0086] First, if the buffer queue is not full and the downstream and upstream buffers are approximately the same size, the DBVC duty cycle does not need to be adjusted. Otherwise, the DBVC duty cycle can be adjusted. Determining whether the downstream and upstream buffers are approximately the same size can be based on or according to any suitable algorithm. For example, if dividing the size of the upstream buffer by the size of the downstream buffer yields a value between 0.5 and 2, then the downstream and upstream buffers can be considered approximately the same size, and the DBVC duty cycle does not need to be adjusted.

[0087] Secondly, if the buffer queue is full and the downstream and upstream buffers are approximately the same size, the DBVC duty cycle does not need to be adjusted. Otherwise, the DBVC duty cycle can be adjusted. As mentioned above, determining whether the downstream and upstream buffers are approximately the same size can be based on or according to any suitable algorithm. For example, if dividing the size of the upstream buffer by the size of the downstream buffer yields a value between 0.5 and 2, then the downstream and upstream buffers can be considered approximately the same size, and the DBVC duty cycle does not need to be adjusted.

[0088] In some implementations, the DBVC duty cycle of repeater 104 can be changed by adjusting the channel-off dwell time or switching the channel-off frequency. Alternatively or additionally, when determining to adjust the DBVC duty cycle, the DBVC duty cycle can be adjusted to one of the following four duty cycle levels or based on one of the following four duty cycle levels:

[0089] Level 1: Channel switching can occur once every two TBTTs, and the channel shutdown dwell time can be equal to 32ms (maximum NAV).

[0090] Level 2: Each TBTT can have one channel handover, and the channel-off dwell time can be equal to 32ms (maximum NAV).

[0091] Level 3: Each TBTT can have two channel handovers, and the channel shutdown dwell time can be equal to 32ms (maximum NAV).

[0092] Level 4: Each TBTT can undergo three channel switchings, and the channel shutdown dwell time can be equal to 17ms.

[0093] In other words, for Level 1, a channel handover can occur once every two TBTTs, or once every two beacon intervals. Similarly, for Level 2, a channel handover can occur once per TBTT, or once per beacon interval. Similarly, for Level 3, two channel handovers can occur per TBTT, or twice per beacon interval. Similarly, for Level 4, three channel handovers can occur per TBTT, or three times per beacon interval. Compared to Levels 1-3, Level 4 significantly reduces the round-trip time (RTT) of communication.

[0094] Each of levels 1-4 has a specific off-channel duty cycle and an on-channel duty cycle. Generally, each successive level from levels 1-3 increases the off-channel duty cycle and decreases the on-channel duty cycle, while level 4 decreases the RTT. The DBVC duty cycle of repeater 104 can be adjusted in the desired direction by moving from one level to another in the appropriate direction. Therefore, if the downstream buffer is substantially larger than the upstream buffer (e.g., if the size of the upstream buffer divided by the size of the downstream buffer is less than 0.5), an increase in the on-channel duty cycle can help clear the downstream buffer, and thus the DBVC duty cycle of repeater 104 can be adjusted by moving down the level, for example, from level 3 to level 2, from level 3 to level 1, or from level 2 to level 1. On the other hand, if the downstream buffer is substantially smaller than the upstream buffer (e.g., if the size of the upstream buffer divided by the size of the downstream buffer is greater than 2), increasing the shut-off channel duty cycle can help clear the upstream buffer, and thus the DBVC duty cycle of repeater 104 can be adjusted by moving the level up, for example from level 1 to level 2, from level 1 to level 3, or from level 2 to level 3.

[0095] Consistent with the above content, Figure 6 A flowchart illustrating an exemplary method 600 for optimizing traffic flow based on buffers queued within the hardware of a repeater or other STA configured to communicate according to the DBVC protocol is provided. Method 600 can be performed by any suitable system, device, or apparatus. For example, any of the root APs or repeaters described herein may perform or direct the performance of one or more of the operations associated with method 600. Method 600 may include one or more of blocks 602, 604, 606, or 608. Method 600 may begin at block 602.

[0096] At block 602, method 600 may include determining the load on an upstream buffer within a repeater configured to communicate according to the DBVC protocol. The load on the upstream buffer may include or correspond to data to be transmitted within the upstream network to, for example, the root AP. The load on the upstream buffer may include the size of the upstream buffer. In some implementations, block 602 may include... Figure 1Repeater 104 determines the load on its upstream buffer, such as the load of data intended for root AP 102. Repeater 104 may determine the load of its upstream buffer for root AP 102 according to Equation 1 above or by any other suitable means. Determining the load on the upstream buffer may include: identifying the priority of data within the upstream buffer (e.g., f(VI), f(VO), f(BE), f(BK)); and calculating the load on the upstream buffer (e.g., according to Equation 1) based on the identified priority of the data within the upstream buffer, wherein a given amount of data with higher priority contributes more to the determined load than the same amount of data with lower priority. Therefore, the priority of data within the upstream buffer may be determined based on the AC associated with the data within the upstream buffer. Box 604 may follow box 602.

[0097] At box 604, method 600 may include determining the load on a downstream buffer within the repeater. The load on the downstream buffer may include or correspond to data to be transmitted within a downstream network to, for example, one or more client devices of the repeater. Figure 1 Repeater 104 can determine the load on its downstream buffer, such as the load of data intended for a first client device or a second client device 106, 108, or other client devices served by repeater 104 during its open channel. Repeater 104 can determine the load on its downstream buffer for client devices (e.g., the first client device and the second client devices 106, 108) served by the repeater on its open channel according to Equation 1 above and by summing over all corresponding client-specific buffer sizes or by any other suitable means. Determining the load on the downstream buffer may include: identifying the priority of data within the downstream buffer (e.g., f(VI), f(VO), f(BE), f(BK)); and calculating the load on the downstream buffer based on the identified priority of the data within the downstream buffer (e.g., according to Equation 1), wherein a given amount of data with a higher priority contributes more to the determined load than the same amount of data with a lower priority. Therefore, the priority of data within the downstream buffer can be determined based on the AC associated with the data within the downstream buffer. Box 606 can follow box 604.

[0098] At block 606, method 600 may include determining whether to adjust the DBVC duty cycle of the repeater based on the load on the upstream buffer and the load on the downstream buffer. For example, repeater 104 may compare the load on the upstream buffer with the load on the downstream buffer and make no adjustment if the loads are approximately the same, or repeater 104 may determine, as described above, to move up or down between levels 1-4 to adjust the DBVC duty cycle, depending on whether the upstream or downstream buffer is larger than the other. Levels 1-4 described above are provided as examples only, and other specific implementations may have other levels and / or corresponding DBVC duty cycles different from those of levels 1-4.

[0099] In this and other embodiments, determining whether to adjust the repeater's DBVC duty cycle based on the load on the upstream buffer and the load on the downstream buffer at block 606 may include determining a ratio of the load on the upstream buffer to the load on the downstream buffer, for example, dividing the load on the upstream buffer by the load on the downstream buffer. If this ratio is within a predetermined range where the loads on the upstream and downstream buffers are considered to be approximately the same, it can be determined that the repeater's DBVC duty cycle will not be adjusted. In this example, this predetermined range may be 0.5 to 2, or some other range. If the ratio is outside this predetermined range, it can be determined that the repeater's DBVC duty cycle will be adjusted.

[0100] Alternatively or additionally, box 606 may include determining the amount by which to adjust the DBVC duty cycle of the repeater. This amount may depend on the difference between the loads on the upstream and downstream buffers. For example, if the ratio of the load or size of the upstream buffer to the load or size of the downstream buffer is exactly outside the range where the loads are considered substantially the same (e.g., 0.5 to 2 in this example), repeater 104 may determine to adjust the DBVC duty cycle by a single level, for example, by moving it up or down. On the other hand, if the ratio of the load or size of the upstream buffer to the load or size of the downstream buffer is substantially outside the range where the loads are considered substantially the same, such as less than 0.25 or greater than 4 (indicating that the load on either the upstream or downstream buffer is four times or more than the other), repeater 104 may determine to adjust the DBVC duty cycle by two or more levels, for example, by moving it up or down. Box 608 may follow box 606.

[0101] At box 608, method 600 may include adjusting the DBVC duty cycle of the repeater. For example, as described above and as determined at box 606, repeater 104 may adjust the DBVC duty cycle of the repeater by moving it up and down between levels 1-4. Alternatively or additionally, repeater 104 may adjust the DBVC duty cycle of the repeater by adjusting at least one of the following: the number of times repeater 104 switches communication between the downstream network (e.g., open channel) and the upstream network (e.g., closed channel) for each TBTT; or the duration of the closed channel dwell time.

[0102] Although illustrated by separate boxes, steps and operations associated with one or more of the boxes in method 600 may be divided into additional boxes, combined into fewer boxes, or excluded, depending on the specific implementation. Alternatively or additionally, method 600 may include additional boxes, steps, or operations.

[0103] Some of the exemplary specific implementations in this article may alternatively or additionally utilize repeaters (such as...) Figure 1 TCP throughput is optimized by adjusting the DPI and priority ordering of TCP ACK packets at repeater 104 or other STAs. To facilitate understanding of how such specific implementations can be carried out in other operating environments and / or devices, [further details will be provided]. Figure 1 This describes optimizations for TCP throughput within the context of [the specific context].

[0104] In these and other specific implementations, the initial TCP handshake can be observed, for example, by repeater 104, and the TCP window size or scaling factor can be determined based on this TCP handshake. Furthermore, repeater 104 can adjust one or both of the open channel dwell time and the close channel dwell time (hereinafter generally referred to as "open / close channel dwell time") based on one or both of the TCP window size and the application used (e.g., based on the TCP window itself). Alternatively or additionally, repeater 104 can adjust the open / close channel dwell time based on other parameters, such as the average and standard deviation of multiple TCP window sizes observed across different TCP streams.

[0105] For example, for bulk file uploads, the TCP window can be large. Due to the larger TCP window size, the link can have a larger tolerance for latency. Therefore, a longer on / off channel dwell time can be determined and used to provide optimal throughput. As another example, for web browsing, the TCP window can be small, for example, less than or equal to 64K, and therefore there can be a lower tolerance for latency. Therefore, a shorter on / off channel dwell time can be determined and used to improve the responsiveness of the TCP stream and reduce the latency of the TCP stream.

[0106] In some implementations, TCP ACK packets can be critical for reliable and fast transmission because they can impact the overall RTT and throughput of the TCP stream. In these and other implementations, TCP ACK packets can be reduced, for example, by merging multiple TCP ACK packets to decrease transmission overhead. For instance, eight TCP ACK packets can be compressed into a single TCP ACK packet. In some implementations, TCP ACK packets can be buffered, for example at repeater 104, during ongoing channel opening or closing, and then merged, with the merged TCP ACK packet transmitted as the last transmission before channel switching. In this way, merging TCP ACK packets provides feedback about the corresponding TCP stream to entities waiting for TCP ACK packets, such as root AP 102, repeater 104, first client device 106, or second client device 108, without waiting for subsequent duty cycles to receive TCP ACK packets. In one example, TCP ACK packets can be buffered during the current channel period; if only a short time remains on the current channel (e.g., 2 milliseconds or less) and the TCP ACK packet is buffered, TCP packets can be stopped and the TCP ACK packet can be transmitted during the remaining time on the current channel before channel switching. In these and other specific implementations, packet length can be measured to identify TCP ACK packets.

[0107] Consistent with the above content, Figure 7 A flowchart illustrating an exemplary method 700 for optimizing TCP throughput through DPI and priority ordering of TCP ACK packets is provided. Method 700 can be performed by any suitable system, device, or apparatus. For example, any root AP, repeater, or other STA configured to communicate according to the DBVC protocol may perform or direct the performance of one or more of the operations associated with method 700. Method 700 may include one or more of blocks 702 or 704. Method 700 may begin at block 702.

[0108] At box 702, method 700 may include performing DPI to observe the TCP connection and the TCP window size of that TCP connection, for example, at a repeater configured to communicate according to the DBVC protocol. Figure 1 Repeater 104 can perform DPI to observe TCP connections through the repeater and the TCP window size of that TCP connection. Box 704 can follow box 702.

[0109] At box 704, the method may include setting or adjusting the channel open / close dwell time based on the TCP window size of the TCP connection. For example, Figure 1 The repeater 104 can set or adjust the channel open / close dwell time based on the TCP window size of the TCP connection. In some implementations, when the TCP window size is relatively large, the channel open / close dwell time can be set or adjusted to be relatively high. Alternatively or additionally, when the TCP window size is relatively small, the channel open / close dwell time can be set or adjusted to be relatively low.

[0110] Although illustrated by separate boxes, steps and operations associated with one or more of the boxes in method 700 may be divided into additional boxes, combined into fewer boxes, or excluded, depending on the specific implementation. Alternatively or additionally, method 700 may include additional boxes, steps, or operations.

[0111] For example, method 700 may include determining an average TCP window size for the TCP window size of a TCP connection. In this and other embodiments, setting or adjusting the repeater's on / off channel dwell time based on the TCP window size may include setting or adjusting the repeater's on / off channel dwell time based on the average TCP window size. Setting or adjusting the repeater's on / off channel dwell time based on the average TCP window size may include: setting or adjusting the repeater's on / off channel dwell time to a relatively long on / off channel dwell time in response to a relatively large average TCP window size; or setting or adjusting the repeater's on / off channel dwell time to a relatively short on / off channel dwell time in response to a relatively small average TCP window size. Alternatively or additionally, setting or adjusting the repeater's on / off channel dwell time based on the average TCP window size may include setting or adjusting the repeater's on / off channel dwell time to a relatively short on / off channel dwell time in response to a relatively large average TCP window size, in order to control TCP flow.

[0112] In some implementations, method 700 may include performing a DPI to inspect upstream and downstream packets containing TCP ACK packets. Method 700 may also include reducing overhead by merging TCP ACK packets. Reducing overhead by merging TCP ACK packets may include compressing multiple TCP ACK packets into a single TCP ACK packet. In some implementations, method 700 may also include sending the single TCP ACK packet, compressed from multiple TCP ACK packets, as a final transmission before switching from a closed channel to an open channel or vice versa.

[0113] Some parts of the specific implementation are presented based on algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are means used by those skilled in the art of data processing to communicate their innovative essence to others skilled in the art. An algorithm is a series of configured operations that produce a desired ending state or result. In exemplary implementations, the operations performed require a tangible number of physical manipulations to achieve a tangible result.

[0114] Unless otherwise specified, it is obvious from the discussion that the use of terms such as detection, determination, analysis, identification, and scanning throughout the description may include the actions and processes of a computer system or other information processing device that manipulates and transforms data representing physical (electronic) quantities in the registers and memories of the computer system into other data representing physical quantities in the memory or registers or other information storage, transmission, or display devices of the computer system.

[0115] The example implementation may also involve means for performing the operations described herein. This means may be specifically constructed for the desired purpose, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. Computer-executable instructions may include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device (e.g., one or more processors) to perform or control the performance of certain functions or groups of functions.

[0116] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter configured in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

[0117] Exemplary devices may include a wireless access point (WAP) or site and incorporate a VLSI processor and program code for support. Example transceivers are coupled via an integrated modem to one of a cable, fiber optic, or digital subscriber backbone connection to the Internet to support wireless communication over a wireless local area network (WLAN), such as IEEE 802.11 compliant communication. The Wi-Fi phase includes a baseband phase, as well as analog front-end (AFE) and radio frequency (RF) phases. In the baseband section, wireless communication transmitted to or received from each user / client / site is processed. The AFE and RF sections process up-conversion on each transmit path of the wireless transmission initiated in the baseband. The RF section also processes down-conversion of signals received on the receive path and passes them to the baseband for further processing.

[0118] An exemplary device may be a Multiple-Input Multiple-Output (MIMO) device that supports up to N×N discrete communication streams on N antennas. In the example, the MIMO device signal processing unit may be implemented as N×N. In various specific implementations, the value of N can be 4, 6, 8, 12, 16, etc. Extended MIMO operation enables the use of up to 2N antennas to communicate with another similarly equipped wireless system. It should be noted that even if the system does not have the same number of antennas, an extended MIMO system can communicate with other wireless systems, but may not utilize some antennas of one station, thus reducing optimal performance.

[0119] Channel state information (CSI) from any device described herein can be extracted independently of changes in channel state parameters and used for spatial diagnostic services of the network, such as motion detection, proximity detection, and location. These spatial diagnostic services can be used for applications such as WLAN diagnostics, home security, health monitoring, smart home facility control, elderly care, vehicle tracking and monitoring, home or mobile entertainment, and automotive infotainment.

[0120] Unless the specific arrangements described herein are mutually exclusive, the various embodiments described herein can be combined, in whole or in part, to enhance system functionality and / or create complementary functions. Similarly, aspects of the embodiments can be implemented through independent arrangements. Therefore, the above description has been given by way of example only and can be modified in detail within the scope of this invention.

[0121] The subject matter of the present invention is illustrated, for example, according to various aspects described below. For convenience, various examples of aspects of the subject matter are described as examples. These are provided by way of example and do not limit the subject matter. Unless the context otherwise requires, aspects of various embodiments described herein may be omitted, substituted for aspects of other embodiments, or combined with aspects of other embodiments. For example, one or more aspects of one example may be omitted, substituted for one or more aspects of another example or other examples, or combined with aspects of another example. The following is a non-limiting overview of some exemplary embodiments presented herein.

[0122] An exemplary method may include: receiving a transmission from a root AP via a repeater configured to communicate according to the DBVC protocol; obtaining from the transmission the next root AP TBTT of the next beacon to be sent by the root AP; determining an amount of time to delay the next repeater TBTT of the next beacon to be sent by the repeater to avoid a conflict between the next root AP TBTT and the next repeater TBTT; and delaying the next repeater TBTT based on the determined amount of time.

[0123] An exemplary repeater configured to communicate according to the DBVC protocol may include a repeater STA interface and a repeater AP interface. The repeater may be configured to perform operations including: receiving a transmission from a root AP; obtaining from the transmission the next root AP TBTT for the next beacon to be transmitted by the root AP; determining an amount of time to delay the next repeater TBTT for the next beacon to be transmitted by the repeater to avoid a conflict between the next root AP TBTT and the next repeater TBTT; and delaying the next repeater TBTT based on the determined amount of time.

[0124] Another exemplary method may include: determining the load on an upstream buffer within a repeater configured to communicate according to the DBVC protocol, wherein the load on the upstream buffer corresponds to data to be transmitted in an upstream network; determining the load on a downstream buffer within the repeater, the load corresponding to data to be transmitted in a downstream network; determining whether to adjust the DBVC duty cycle of the repeater based on the load on the upstream buffer and the load on the downstream buffer; and adjusting the DBVC duty cycle of the repeater.

[0125] In some implementations, the load on the downstream buffer includes data that will be transmitted by the repeater to one or more client devices within the downstream network.

[0126] In some implementations, determining the load on the upstream buffer includes identifying the priority of data within the upstream buffer based on the type of data therein; and calculating the load on the upstream buffer based on the identified priorities of the data within the upstream buffer, where a given amount of data with higher priority contributes more to the determined load than the same amount of data with lower priority. In some implementations, determining the load on the downstream buffer includes identifying the priority of data within the downstream buffer based on the type of data therein; and calculating the load on the downstream buffer based on the identified priorities of the data within the downstream buffer, where a given amount of data with higher priority contributes more to the determined load than the same amount of data with lower priority. In some implementations, the priorities of data within the upstream and downstream buffers are determined based on the access class associated with the data.

[0127] In some specific implementations, determining whether to adjust the DBVC duty cycle of a repeater based on the load on the upstream buffer and the load on the downstream buffer includes: determining the ratio of the load on the upstream buffer to the load on the downstream buffer; and performing one of the following operations: if the ratio is within a predetermined range, determining not to adjust the DBVC duty cycle of the repeater; or if the ratio is outside the predetermined range, determining to adjust the DBVC duty cycle of the repeater.

[0128] In some specific implementations, determining the load on the upstream buffer includes calculating the buffer size of the upstream buffer based on the access class factor associated with the data and the number of packets within the load on the upstream buffer; and determining the load on the downstream buffer includes calculating the buffer size of the downstream buffer based on the access class factor associated with the data and the number of packets within the load on the downstream buffer.

[0129] In some specific implementations, adjusting the repeater's DBVC duty cycle includes adjusting at least one of the following: the number of times each TBTT switches between communications in the downstream and upstream networks; or the repeater's closed channel dwell time.

[0130] A third exemplary method may include determining that a first wireless communication device will transmit a service to a second wireless communication device during a period when the second wireless communication device, configured to communicate according to the DBVC protocol, is not operating on a first channel; switching to a second channel; providing a trigger frame to the second wireless communication device on the second channel; receiving an ACK frame from the second wireless communication device, the ACK frame being sent by the second wireless communication device to the first wireless communication device in response to the second wireless communication device receiving the trigger frame; transmitting data to the second wireless communication device on the second channel; transmitting an end frame to the second wireless communication device on the second channel; and switching back to the first channel in response to transmitting the end frame.

[0131] In some specific implementations, the method further includes: receiving a second trigger frame from the second wireless communication device on the first channel according to the DBVC protocol during a period when the first wireless communication device is not performing operations on the second channel; receiving data from the second wireless communication device on the first channel; and receiving a second end frame from the second wireless communication device, wherein the second end frame indicates that the second wireless communication device will switch to the second channel.

[0132] In some implementations, the method also includes receiving a second ACK frame from a second wireless communication device in response to the end frame.

[0133] In some specific implementations, the method further includes: providing one or more other trigger frames on a second channel to a second wireless communication device before providing the trigger frame; and determining that an ACK frame for the one or more other trigger frames has not yet been received from the second wireless communication device, wherein the first wireless communication device provides the trigger frame to the second wireless communication device in response to determining that an ACK frame for the one or more other trigger frames has not yet been received from the second wireless communication device.

[0134] In some specific implementations, the method further includes: switching to a second channel; providing a plurality of trigger frames to a second wireless communication device on the second channel; determining that an ACK frame for any of the plurality of trigger frames has not yet been received from the second wireless communication device; switching back to the first channel; and communicating with the second wireless communication device on the first channel.

[0135] In some specific implementations, the first wireless communication device includes a root access point (AP), and the second wireless communication device includes a repeater that communicates with the root AP in the upstream network and with the client device in the downstream network according to the DBVC protocol.

[0136] The fourth exemplary method may include performing DPI to observe the TCP connections through the repeater and the TCP window size of the TCP connections at a repeater configured to communicate according to the DBVC protocol; and setting or adjusting the channel dwell time of the repeater to open / close based on the TCP window size of the TCP connections.

[0137] In some specific implementations, the method also includes determining the average TCP window size of the TCP window for the TCP connection, wherein setting or adjusting the channel open / close dwell time of the repeater based on the TCP window size includes setting or adjusting the channel open / close dwell time of the repeater based on the average TCP window size.

[0138] In some specific implementations, setting or adjusting the repeater's channel open / close dwell time based on the average TCP window size includes: setting or adjusting the repeater's channel open / close dwell time to a relatively long time in response to a relatively large average TCP window size; and setting or adjusting the repeater's channel open / close dwell time to a relatively short time in response to a relatively small average TCP window size.

[0139] Alternatively, in response to a relatively large average TCP window size, the channel open / close dwell time of the repeater may be set or adjusted to a relatively short channel open / close dwell time to control TCP flow.

[0140] In some specific implementations, the method also includes: performing DPI to inspect upstream and downstream packets containing TCP acknowledgment (ACK) packets; and reducing overhead by merging TCP ACK packets.

[0141] In some implementations, reducing overhead by merging TCP ACK packets includes compressing multiple TCP ACK packets into a single TCP ACK packet. In some implementations, the method also includes sending the single TCP ACK packet, compressed from multiple TCP ACK packets, as a final transmission before switching from a closed channel to an open channel or vice versa.

[0142] Regarding the use of virtually any plural or singular terminology herein, those skilled in the art can convert from plural to singular or vice versa, depending on the context or application to which it applies. For clarity, various singular / plural arrangements may be explicitly described herein. Unless otherwise stated, references to elements in singular form are not intended to mean "one and only one," but rather "one or more." Furthermore, nothing disclosed herein is intended for public use, whether or not such disclosure is explicitly stated in the foregoing description.

[0143] Generally, the terms used herein, and especially in the appended claims (e.g., the body of the appended claims), are generally expected to be “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “includes” should be interpreted as “including but not limited to,” etc.). Furthermore, in cases where conventions such as “at least one of A, B, and C” are used, such constructs generally imply the conventions that should be understood by one of those skilled in the art (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems including A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc.). Additionally, phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to include one term, any one of the terms, or both terms. For example, the phrase “A or B” would be understood to include the possibility of “A” or “B” or “A and B.”

[0144] The invention may be embodied in other specific forms without departing from the spirit or essential characteristics of the invention. The specific embodiments described are to be considered exemplary in all respects only and not restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the meaning and scope of the equivalents of the claims are covered within the scope of the claims.

Claims

1. A method for avoiding TBTT collisions, the method comprising: Transmissions are received from the root access point (AP) via a repeater configured to communicate according to the dual-band virtual parallel DBVC protocol. The next root AP target beacon transmission time (TBTT) to be sent by the root AP is obtained from the transmission. Determine the delay time amount of the next repeater TBTT of the next beacon to be sent by the repeater in order to avoid a conflict between the next root AP TBTT and the next repeater TBTT; as well as The next repeater TBTT is delayed based on the aforementioned delay time. Determining the amount of delay time includes: Determine the next repeater TBTT; Determine the repeater beacon interval of the repeater; Determine the first time value for the repeater to perform the DBVC channel shut-off operation; Determine the second time amount that will cause the next repeater TBTT to avoid occurring during the repeater's DBVC channel shutdown operation; The next root AP TBTT is summed with the repeater beacon interval to generate an intermediate sum; and The difference is generated by subtracting the first time amount, the second time amount, and the next repeater TBTT from the intermediate sum, where the difference is the delay time amount.

2. The method of claim 1, further comprising setting the repeater beacon interval to be equal to the root AP beacon interval of the root AP, such that the repeater TBTT after the next repeater TBTT is out of phase with the root AP TBTT after the next root AP TBTT.

3. The method of claim 1, further comprising setting the repeater beacon interval to a value different from the root AP beacon interval of the root AP, such that at least some repeater TBTTs after the next repeater TBTT are out of phase with the root AP TBTT after the next root AP TBTT.

4. The method of claim 1, wherein delaying the next repeater TBTT based on the delay time amount comprises delaying the next repeater TBTT by the delay time amount.

5. The method of claim 1, wherein delaying the next repeater TBTT based on the delay time amount comprises delaying the next repeater TBTT by a portion of the delay time amount, the method further comprising delaying each of a plurality of subsequent repeater TBTTs following the next repeater TBTT by a portion of the delay time amount, wherein the sum of the portions of the delay time amount is equal to the delay time amount.

6. A repeater configured to communicate according to a dual-band virtual parallel DBVC protocol, the repeater comprising: Repeater wireless station STA interface; and Repeater access point AP interface, The repeater device is configured to perform operations including: Receive transmissions from the root AP; The next root AP target beacon transmission time (TBTT) to be sent by the root AP is obtained from the transmission. Determine the delay amount of the next repeater TBTT for the next beacon to be transmitted by the repeater, in order to avoid a conflict between the next root AP TBTT and the next repeater TBTT; and The next repeater TBTT is delayed based on the aforementioned delay time. Determining the amount of delay time includes: Determine the next repeater TBTT; Determine the repeater beacon interval of the repeater; Determine the first time value for the repeater to perform the DBVC channel shut-off operation; Determine the second time amount that will cause the next repeater TBTT to avoid occurring during the repeater's DBVC channel shutdown operation; The next root AP TBTT is summed with the repeater beacon interval to generate an intermediate sum; and The difference is generated by subtracting the first time amount, the second time amount, and the next repeater TBTT from the intermediate sum, where the difference is the delay time amount.

7. The repeater of claim 6, wherein the operation further comprises one of the following: Set the repeater beacon spacing to be equal to the root AP beacon spacing of the root AP, such that the repeater TBTT after the next repeater TBTT is out of phase with the root AP TBTT after the next root AP TBTT; or The repeater beacon interval is set to a value different from the root AP beacon interval of the root AP, such that at least some repeater TBTTs after the next repeater TBTT are out of phase with the root AP TBTT after the next root AP TBTT.

8. The repeater of claim 6, wherein delaying the next repeater TBTT based on the delay time amount comprises delaying the next repeater TBTT by the delay time amount.

9. The repeater of claim 6, wherein delaying the next repeater TBTT based on the delay time amount comprises delaying the next repeater TBTT by a portion of the delay time amount, the operation further comprising delaying each of a plurality of subsequent repeater TBTTs following the next repeater TBTT by a portion of the delay time amount, wherein the sum of the portions of the delay time amount is equal to the delay time amount.

Images