Coexistence solution for 802.11 operation

Abstract

The present disclosure relates to a coexistence solution for 802.11 operation. An apparatus configured to: determine a transmission opportunity (TXOP) for transmission to a station; processing an indication including an unavailability start time and an unavailability duration occurring during the TXOP based on the signaling received from the station; and performing an operation related to the TXOP based on the indication.

Description

[0001] Priority / Accommodation

[0002] This application claims priority to U.S. Provisional Application Serial No. 63 / 699,299, filed September 26, 2024, entitled “Coexistence Solutions for 802.11 Operations,” which is incorporated by reference herein in its entirety. BACKGROUND

[0003] IEEE 802.11 networks can experience coexistence (COEX) scenarios with other communication protocols, such as Bluetooth, cellular, ultra-wideband (UWB), etc. These COEX scenarios can cause problems for stations attempting to transmit or receive signals via the 802.11 network. Solving various COEX scenarios would mitigate problems that can arise, such as interference. SUMMARY

[0004] Some example embodiments relate to an apparatus having processing circuitry coupled to a memory, where the processing circuitry is configured to: determine a transmission opportunity (TXOP) for transmission to a station; process, based on signaling received from the station, an indication including an unavailability start time and an unavailability duration that occur during the TXOP; and perform an operation related to the TXOP based on the indication.

[0005] Other example embodiments relate to an apparatus having processing circuitry coupled to a memory, where the processing circuitry is configured to: process, based on signaling received from a station, an initial control frame (ICF) including information related to a transmission opportunity (TXOP) for the station; determine unavailability information including an unavailability start time and an unavailability duration that occur during the TXOP; and generate an indication including the unavailability information for transmission to the station. BRIEF DESCRIPTION OF DRAWINGS

[0006] Figure 1 An example arrangement of a wireless communication device and wirelessly locatable tag is shown in accordance with various example embodiments.

[0007] Figure 2 An example wireless communication device is shown in accordance with various example embodiments.

[0008] Figure 3 A first example signaling diagram for transmission opportunity (TXOP) operations is shown in accordance with various example embodiments.

[0009] Figure 4An example signaling diagram in which a TXOP holder dynamically adjusts a TXOP upon receiving unavailability information from a TXOP responder is shown, in accordance with various example embodiments.

[0010] Figure 5 An example signaling diagram in which a TXOP holder dynamically ends a TXOP upon receiving unavailability information from a TXOP responder is shown, in accordance with various example embodiments.

[0011] Figure 6 An example signaling diagram in which a TXOP holder transmits data during a TXOP upon receiving unavailability information from a TXOP responder is shown, in accordance with various example embodiments.

[0012] Figure 7 A first example signaling diagram in which a TXOP responder communicates a frame to a TXOP holder indicating a power mode / state in which the TXOP responder is placed after an unavailability period, in accordance with various example embodiments, is shown.

[0013] Figure 8 A second example signaling diagram in which a TXOP responder communicates a frame to a TXOP holder indicating a power mode / state in which the TXOP responder is placed after an unavailability period, in accordance with various example embodiments, is shown.

[0014] Figure 9 An example signaling diagram in which a TXOP holder determines an unavailability start time based on information communicated by a TXOP responder, in accordance with various example embodiments, is shown. DETAILED DESCRIPTION

[0015] Example embodiments can be further understood with reference to the following description and

[0016] Example embodiments are described with reference to the IEEE 802.11 communication protocol for devices to communicate via wireless connections. There are multiple versions of the 802.11 protocol (e.g., 802.11ax, 802.11be, 802.11bn, etc.). Unless a specific version is identified in the description, references to 802.11 in the example embodiments can refer to any version of the 802.11 protocol.

[0017] Example implementations are described with respect to wireless communication devices. Generally, a wireless communication device in an 802.11 network can be referred to as a station (or STA). In example implementations, a station can refer to an end-point device such as a mobile phone, tablet computer, desktop computer, smart phone, embedded device, wearable device, Internet of Things (IoT) device, video game console, media player, entertainment device, smart speaker, smart TV, streaming device, etc. A station can also refer to an intermediate point in an 802.11 network including an access point (AP), router, switch, etc. Thus, unless otherwise noted, any reference in example implementations to a station or wireless communication device can refer to any device capable of wireless communication using 802.11 protocols.

[0018] Example implementations are described with respect to a TXOP responder station transmitting unavailability information in an initial control response (ICR). The TXOP responder station can transmit unavailability information to a TXOP holder in one or more other messages in addition to the ICR. Example implementations are not limited to unavailability information being provided in the ICR, but can be implemented regardless of the manner in which unavailability information is reported.

[0019] Example implementations provide various aspects for handling COEX scenarios for TXOP holders and TXOP responders. These aspects include TXOP holder behavior based on availability / unavailability information received from TXOP responders, blindness of TXOP responders due to COEX, triggered uplink (UL) acknowledgement (Ack) policies, and failures due to COEX. Each of these example aspects will be described in greater detail below.

[0020] Figure 1 An example arrangement 100 is shown of a wireless communication device 110 (e.g., a non-AP station) in communication with an AP station 120 to access an 802.11 network 130. The wireless communication device 110 can represent any type of electronic component capable of communicating with the AP 120. Specific examples of the wireless communication device 110 include, but are not limited to, a mobile phone, tablet computer, desktop computer, smart phone, embedded device, wearable device, Internet of Things (IoT) device, video game console, media player, entertainment device, smart speaker, smart TV, streaming device, etc.

[0021] Wireless communication device 110 can be configured to communicate with one or more networks. In an example of network arrangement 100, the network with which wireless communication device 110 can wirelessly communicate is 802.11 network 130. Wireless communication device 110 can also communicate with other types of networks (e.g., 5G networks, 5G cloud RAN, next-generation RAN (NG-RAN), traditional cellular networks, etc.), and wireless communication device 110 can also communicate with the network via a wired connection. Regarding the example implementation, wireless communication device 110 can establish a connection with 802.11 network 130. Therefore, wireless communication device 110 may have an industrial, scientific, and medical (ISM) chipset to communicate with 802.11 network 130.

[0022] Any association procedure can be performed to connect the wireless communication device 110 to the 802.11 network 130. The wireless communication device 110 can be associated with the AP 120 to access the 802.11 network 130.

[0023] Figure 2 An example station 200 according to various example implementations is shown. Example station 200 may represent a wireless communication device 110 or an access point (AP) 120 in network arrangement 100. Although various components are described below with respect to station 200, it is not required that the station have all the described components. For example, an AP typically will not include a display device.

[0024] Station 200 may include processor 205, memory arrangement 210, display device 215, input / output (I / O) device 220, transceiver 225, and other components 230. Other components 230 may include, for example, audio input device, audio output device, power supply, data acquisition device, ports for electrically connecting station 200 to other electronic devices, etc.

[0025] Processor 205 may be configured to execute multiple engines of station 200. For example, an engine may include TXOP unavailability engine 235. TXOP unavailability engine 235 may be configured to perform operations related to the unavailability of the station during a TXOP. These operations may include those performed by the TXOP holder or TXOP responder. These operations will be described in detail below.

[0026] The engines cited above, as applications (e.g., programs) executed by processor 205, are merely examples. The functionality associated with these engines can also be represented as separate integrated components of station 200, or as modular components coupled to station 200, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engine can also be embodied as one or more separate applications. Furthermore, in some stations, the functionality described for processor 205 is split among two or more processors, such as a baseband processor and an application processor. Example implementations can be implemented according to any of these or other configurations of the wireless communication device.

[0027] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by station 200. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling the user to input data. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen).

[0028] Transceiver 225 may be a hardware component configured to establish a connection with a wirelessly locatable tag or any other wireless communication device. Therefore, transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). For example, the transceiver may be configured to operate on frequencies associated with the IEEE 802.11 protocol to exchange signals with other stations operating on these protocols. Transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded with information used to implement any of the methods described herein. Processor 205 may be operatively coupled to transceiver 225 and configured to receive signals from and / or transmit signals to transceiver 225. Processor 205 may be configured to encode and / or decode signals for use in implementing any of the methods described herein.

[0029] The first aspect of the example implementation involves an operation performed by a Transmission Opportunity (TXOP) holder based on availability / unavailability information provided by a TXOP responder. A TXOP enables a station to continuously transmit multiple frames within a burst after acquiring a channel.

[0030] Figure 3 Example signaling diagram 300 for Transport Opportunity (TXOP) operation is shown according to various example implementations. Figure 3 In the example, signaling is performed between the TXOP holder (e.g., station 305) and the TXOP responder (e.g., station 310).

[0031] exist Figure 3 In the example, station 305 may gain access to the channel for the duration of TXOP 320. Station 305 may then transmit an Initial Control Frame (ICF) 330. Information included in the ICF 330 may include the duration of TXOP 320, such as a Network Allocation Vector (NAV) that signals to other stations regarding the duration of TXOP 320, causing other stations not to attempt to access the channel during this duration. Other information that may be defined by the standard may also be included in the ICF 330, but will not be described further herein.

[0032] Station 310 can receive ICF 330 and respond with an Initial Control Response (ICR) 340. ICR 340 may include the start time and duration of unavailability of station 310 that occurs during TXOP 320. For example, station 310 may have Bluetooth communication scheduled during TXOP 320. Figure 3 In the example, the unavailability start time is shown at 350, and the unavailability duration is shown as 360. The unavailability duration used by the TXOP responder station in ICR 340 can be as short as the availability duration, or it can be set based on the ICF duration (e.g., the TXOP duration).

[0033] Station 305 receives ICR 340 with unavailability information from station 310. Station 305 can then determine how to handle TXOP 320 if station 310 is not available to receive communication from station 305 for at least a portion of TXOP 320. The example implementation provides various operations that TXOP holder station 305 can perform in this scenario.

[0034] In some example implementations, the TXOP holder can dynamically adjust the TXOP. Figure 4 An example signaling diagram 400 is shown, illustrating how a TXOP holder dynamically adjusts the TXOP upon receiving unavailability information from a TXOP responder, according to various example implementations. Signaling diagram 400 is similar to signaling diagram 300. TXOP holder station 405 transmits an ICF 430 including the duration of TXOP 420. TXOP responder station 410 responds to the ICF 430 by transmitting an ICR 440 including an unavailability start time 450 and an unavailability duration 460 during TXOP 420.

[0035] As stated above, in some example implementations, TXOP holder station 405 may dynamically adjust TXOP 420 based on the unavailability start time 450 and / or unavailability duration 460 provided in ICR 440. For example, asFigure 4 As shown, TXOP holder station 405 can generate a truncated physical layer protocol data unit (PPDU) 470 to be transmitted to TXOP responder station 410. The truncated data PPDU 470 can be transmitted during TXOP 420, such that the truncated data PPDU is completed before the unavailability start time 450, and such that the truncated data PPDU allows TXOP responder station 410 sufficient time to transmit a block acknowledgment (BA) 480 confirming the truncated data PPDU 470.

[0036] Figure 5 An example signaling diagram 500 is shown, illustrating a scenario where a TXOP holder dynamically terminates a TXOP upon receiving an unavailability message from a TXOP responder, according to various example implementations. Signaling diagram 500 is similar to signaling diagram 300. TXOP holder station 505 transmits an ICF 530 including the duration (e.g., NAV) of TXOP 520. TXOP responder station 510 responds to ICF 530 by transmitting an ICR 540 including an unavailability start time 550 and an unavailability duration 560 during TXOP 520.

[0037] In this example implementation, the TXOP holder station 505 may transmit a contention-free (CF) end transmission 570 indicating that the NAV has been reset (e.g., another station has a contentionable channel).

[0038] In some example implementations, when TXOP holder station 505 is an AP, that AP can schedule other stations (e.g., not TXOP responder 510) in TXOP 520.

[0039] Figure 6 An example signaling diagram 600 is shown, illustrating how a TXOP holder transmits data during a TXOP when receiving unavailability information from a TXOP responder, according to various example implementations. Signaling diagram 600 is similar to signaling diagram 300. TXOP holder station 605 transmits an ICF 630 including the duration (e.g., NAV) of TXOP 620. TXOP responder station 610 responds to ICF 630 by transmitting an ICR 640 including an unavailability start time 650 and an unavailability duration 660 during TXOP 620.

[0040] In this example implementation, TXOP holder station 605 transmits data PPDU 670 to TXOP responder station 610, even if some or all of this transmission occurs during the unavailability duration 660. Since TXOP responder station 610 is unavailable during the unavailability duration 660, TXOP responder station 610 may not transmit the BA acknowledgment for data PPDU 670. In conventional operation, when TXOP holder station 605 does not receive the BA corresponding to the data PPDU transmission, TXOP holder station 605 may assume there is a problem with the channel. Therefore, in response, TXOP holder station 605 may perform operations designed to make the transmission of data PPDU 670 more likely to succeed. These operations may include, for example, reducing the transmission rate, increasing the contention window (CW) size of the PPDU's access class (AC), or the QoS retry counter (QSRC) of the PPDU's AC. These operations may make the data PPDU transmission more likely to succeed, but may incur performance penalties for TXOP holder station 605, such as lower transmission rates leading to lower throughput.

[0041] However, in the current scenario, TXOP holder station 605 can determine that the BA was not received because TXOP responder 610 is unavailable, not because of a channel problem. Therefore, in these example implementations, TXOP holder station 605 may not perform any operations related to making the transmission of data PPDU 670 more likely to succeed; for example, rate, CW, and QSRC may remain the same. This is because the lack of BA is based on the unavailability of TXOP responder station 610, not channel conditions. Therefore, TXOP holder station 605 will not experience a performance penalty.

[0042] The second aspect of the example implementation involves the indication by which a TXOP responder station indicates that its power-saving operation is unavailable. The station can operate in various power modes. These modes include active mode and power-saving mode. Power-saving mode includes two states: wake-up state and sleep state. The operations performed by the station while in these different modes / states are defined by the standard and will not be described further herein.

[0043] The example implementation addresses an issue associated with a TXOP responder station indicating unavailability. For instance, when a TXOP holder station receives an unavailability indication from a TX responder station, the TXOP holder station may not know the power mode / state that the TX responder station will be in when it becomes available again after the TXOP responder station has become unavailable.

[0044] In some example implementations, a TXOP holder receiving an unavailability indication from a TXOP responder (e.g., in an ICR) can determine that the TXOP responder is unavailable, for example, placed in a power-saving mode or dormant state, or unavailable to receive transmissions from the TXOP holder at the start of the unavailability duration. For example, see reference... Figure 3 Regardless of the power mode / state of TXOP responder station 310 before the start of unavailability 350, the TXOP holder may assume that TXOP responder station 310 is unavailable while TXOP responder station 310 is in the unavailability duration 360. When TXOP responder station 310 exits the unavailability duration 360, TXOP holder station 305 may determine that TXOP responder station 310 is placed in the power mode / state it was in before the start of unavailability 350, for example, after the unavailability duration, the TXOP responder station is placed in the power mode / state it was in before the unavailability duration.

[0045] In other example implementations, the TXOP responder station may transmit frames to the TXOP holder during the unavailability duration. Such frames may include power mode / state information describing the power mode / state the TXOP responder will be placed in when the unavailability duration ends; for example, the TXOP holder may receive an explicit indication of the power mode / state the TXOP responder will be placed in after the unavailability duration. See below for reference. Figure 7 and Figure 8 These implementation schemes will be described in further detail.

[0046] The example implementations of providing frames that provide power mode / state information or determining the power mode / state that the TXOP responder will be placed in before the TXOP holder's power mode / state prior to the duration of unavailability are not mutually exclusive. For example, unless the TXOP holder receives a frame with different information from the TXOP responder, the TXOP holder can determine that the TXOP responder will be placed in the power mode / state that the TXOP holder was in before the duration of unavailability.

[0047] Figure 7A first example signaling diagram 700 is shown, according to various example embodiments, in which a TXOP responder transmits a frame to a TXOP holder instructing the TXOP responder to be placed in a power mode / state after an unavailability period. Signaling diagram 700 is similar to signaling diagram 300. TXOP holder station 705 transmits an ICF 730 including the duration (e.g., NAV) of TXOP 720. TXOP responder station 710 responds to ICF 730 by transmitting an ICR 740 including an unavailability start time 750 and an unavailability duration 760 during TXOP 720. Based on receiving the ICR 740 with unavailability information, TXOP holder station 705 can perform action 770. For example, the action can be any of the example operations described above with reference to the first aspect of the example embodiments. However, action 770 is not limited to these example operations.

[0048] In this example implementation, TXOP responder station 710 is in active power mode until the inaccessibility start time 750. At the beginning of the inaccessibility duration 760, TXOP responder station 710 is placed into a power-saving sleep state. However, TXOP responder station 710 may transmit frame 780 during the inaccessibility duration 760. Frame 780 may indicate that TXOP responder station 710 is available (e.g., TXOP responder station 710 may have completed its Bluetooth communication before the end of the inaccessibility duration 760). Frame 780 may also indicate the power mode / state of TXOP responder station 710. This power mode / state can be any of the power modes described above, such as active mode, power-saving wake-up state, power-saving sleep state. When TXOP holder station 705 receives frame 780 with power mode / state information, TXOP holder station 705 can determine that TXOP responder station 710 will be in the power mode / state indicated in frame 780 from the time frame 780 is received, such as... Figure 7 As shown.

[0049] Figure 8A second example signaling diagram 800 is shown, according to various example embodiments, in which a TXOP responder transmits a frame to a TXOP holder instructing the TXOP responder to be placed in a power mode / state after an unavailability period. Signaling diagram 800 is similar to signaling diagram 300. TXOP holder station 805 transmits an ICF 830 including the duration (e.g., NAV) of TXOP 820. TXOP responder station 810 responds to ICF 830 by transmitting an ICR 840 including an unavailability start time 850 and an unavailability duration 860 during TXOP 820. Based on receiving the ICR 840 with unavailability information, TXOP holder station 805 can perform action 870. For example, the action can be any of the example operations described above with reference to the first aspect of the example embodiments. However, action 870 is not limited to these example operations.

[0050] In this example implementation, TXOP responder station 810 is in power-saving mode and wake-up state until the inaccessibility start time 850. At the beginning of the inaccessibility duration 860, TXOP responder station 810 is placed into a power-saving sleep state. However, TXOP responder station 810 may transmit frame 880 during the inaccessibility duration 860. Frame 880 may indicate that TXOP responder station 810 is available (e.g., TXOP responder station 810 may have completed its Bluetooth communication before the end of the inaccessibility duration 860). Frame 880 may also indicate the power mode / state of TXOP responder station 810. This power mode / state can be any of the power modes described above, such as wake-up mode, power-saving mode active state, power-saving mode sleep state. When TXOP holder station 805 receives frame 880 with power mode / state information, TXOP holder station 805 can determine that TXOP responder station 810 will be in the power mode / state indicated in frame 880 from the time frame 880 is received, such as... Figure 8 As shown.

[0051] In a third aspect, the example implementations involve maintaining unavailability information. In these example implementations, a station (e.g., an AP) may maintain the unavailability state of its peer stations (e.g., non-AP stations). In some example implementations, when the AP is a multi-link device (MLD), the unavailability state may apply at the link level (e.g., an unavailability state exists for each individual link of the MLD). In other example implementations, when the AP is an MLD, the unavailability state may apply at the MLD level (e.g., the unavailability state applies to all links of the MLD).

[0052] In some example implementations, the link to which the unavailability information applies can be identified during ICF / ICR exchange. In other example implementations, the unavailability information may apply to the link on which the frame carrying the unavailability information resides (e.g., the link on which ICR is transmitted).

[0053] In some example implementations, as referenced above Figure 7 and Figure 8 As described, a station may transmit frames during the period overlapping with the unavailability duration to indicate that the station is available. As described above, a station may determine that communication on the COEX protocol is complete and thus cancel the remainder of the unavailability duration. For example, a station may transmit a frame that sets the unavailability duration field to 0, indicating that the unavailability has been canceled. Similarly, a station may also transmit frames that update previously indicated unavailability information, such as extending or shortening the unavailability duration.

[0054] In the fourth aspect of the example implementation, issues related to station blindness are addressed. Station blindness can be a situation where a station loses synchronization with the medium. This can occur because the station experiences unavailability (e.g., the station experiences an internal COEX). The example implementation provides operations for handling station blindness.

[0055] In some example implementations, a station may implement a NAV synchronization delay when exiting an unavailability duration. In the absence of detected frames through which the NAV can be set, the NAV synchronization delay can be a delay to be used before transmission upon exiting the unavailability duration. This delay can be, for example, the maximum duration of a PPDU. For example, refer to... Figure 3 At the end of the unavailability duration 360, the TXOP responder station 310 can determine whether it has detected a frame that can be used to set the NAV. If no such frame has been detected, the TXOP responder station 310 can transmit over the medium after waiting for the duration of the NAV synchronization delay. The value of the NAV synchronization delay can be set via the Master Information Block (MIB) broadcast by the network.

[0056] In other example implementations, a station exiting the unavailability duration may perform a media access recovery procedure. A media access recovery procedure typically includes sending a transmission to the network and determining whether a response has been received. In some example implementations, the media access recovery procedure defined in IEEE 802.11be can be used as the media access recovery procedure. However, this is not the only type of media access recovery procedure that can be used with the example implementations. A general overview of media access recovery procedures is provided below.

[0057] A station can perform a transfer on the medium when exiting the unavailability period. A station can start a timer. In some examples, if the transfer duration exceeds a threshold, the timer can start from the end of the transfer, unless the timer has not yet expired. In other examples, if the duration of the medium synchronization loss exceeds a threshold, the timer can be started when the station returns to the listening operation.

[0058] In some examples, the STA may not (re)start the timer if the transmission duration is less than or equal to a threshold. The threshold could be, for example, 72 μs, but this is just an example. The value of 72 μs can be chosen to at least cover the PPDU length of Request to Send (RTS) / Certified to Send (CTS) / Ack frames using a non-high throughput (non-HT) or non-HT repeating PPDU format at a data rate of 6 Mb / s, as well as the PPDU length of most typical BlockAck frames. The timer value can be set to any duration. In some examples, the timer value is set to dot11MSDTimerDuration as defined by the standard.

[0059] If a station acquires a TXOP when its timer has a non-zero value (e.g., the timer is still running), the station can perform various operations for synchronization. If the station is a non-AP station, it can transmit an RTS frame to the associated AP as the initial frame in the acquired TXOP. A threshold can be set for CCA sensitivity in response to the RTS. The threshold can be, for example, dot11MSDOFDMEDthreshold as defined by the standard. However, other thresholds can be used. If the timer has a non-zero value, this allows the station to detect channel busy conditions in the primary 20MHz channel.

[0060] If the station is an AP attached to a Non-Simultaneous Transmit and Receive (NSTR) Mobile AP MLD, the AP may transmit an RTS frame as the initial frame in a TXOP to an associated non-AP station. Since the timer started, the station may not attempt to initiate a TXOP more than a predetermined number of times.

[0061] In other cases, the station may perform a CCA before initiating a transmission, until the timer has expired.

[0062] In the fifth aspect, the example implementation relates to a triggered uplink (UL) Ack policy. For example, a non-AP station may transmit a High Efficiency (HE) triggered (TB) PPDU in response to a trigger frame transmitted by an AP. The station may set the Ack policy indicator subfield of a QoS data frame or QoS empty frame to indicate that the AP should return a normal Ack (e.g., BA) or an implicit BA response (BAR). However, when the station has an internal COEX (e.g., the station is unavailable for a period of time), the station may not receive a BA or BAR because it is unavailable. In this case, the station does not need to request a BA or BAR. This can be expressed as a non-AP STA transmitting an HE TB PPDU in response to a basic trigger frame may set the Ack policy indicator subfield of a QoS data frame or QoS empty frame to a normal Ack or an implicit BAR, or for example, not need to set the Ack policy indicator subfield. In another example, the following rule can be defined: if a station does not have an unavailability duration, the station can set the Ack policy indicator subfield to normal Ack or implicit BAR; or if a station has an unavailability duration, the station can choose not to set the Ack policy indicator subfield to normal Ack or implicit BAR.

[0063] In the sixth aspect, the example implementations address transmission delays due to COEX. In these example implementations, a TXOP holder station in the process of transmitting may determine that the transmission cannot be performed due to COEX. However, if the TXOP holder station's backoff expires and the TXOP holder does not transmit due to the COEX event, the TXOP holder station can postpone the transmission by selecting a new random backoff counter using the current CW instead of advancing to the next value of the CW. The QSRC of the MAC Service Data Unit (MSDU) or the Aggregated MSDU (A-MSDU) is unaffected. These example implementations prevent transmission conflicts because multiple backoffs may have expired simultaneously when a COEX issue exists.

[0064] In the seventh aspect, the example implementation involves an operation performed by a TXOP holder station, where the TXOP holder has not received a response frame due to an unavailability duration indicated by the TXOP responder. (Refer to the above...) Figure 6 The described examples depict actions performed by the TXOP holder when it does not receive a BA from the TXOP responder. In these example implementations, these actions can be extended to any response frames not received due to the duration of unavailability. These actions include the TXOP holder station not reducing the transmission rate and keeping the CW and QSRC of the Access Class (AC) unchanged.

[0065] In the eighth aspect, the example implementation involves operations performed by the TXOP holder station to determine the start time of unavailability for the TXOP responder. (Reference) Figure 9 This section describes the problems associated with the start time of unavailability and provides example solutions.

[0066] Figure 9 An example signaling diagram 900 is shown according to various example implementations, where the TXOP holder determines the unavailability start time based on information transmitted by the TXOP responder. Signaling diagram 900 is similar to signaling diagram 300. TXOP holder station 905 transmits ICF 930. TXOP responder station 910 responds to ICF 930 by transmitting ICR 940, which includes an unavailability start time 950 and an unavailability duration 960. Based on the received ICR 940 with unavailability information, TXOP holder station 905 can determine the unavailability start time 950 in operation 970. However, when TXOP holder station 905 constructs the unavailability start time 950, problems may occur during operation 970.

[0067] For example, such as Figure 9 As shown, ICF 930 and ICR 940 can occur during the first timing synchronization function (TSF) 980, but are unavailable at start time 950 during the second TSF 985. Figure 9 As shown, a 64-bit field is used to signal the value associated with the TSF, which can be broken down into various subfields. The first subfield identifies the TSF. The value identifying the TSF 980 includes... Figure 9 It is shown as Current_TSF B63-B15 = (000000…000)2, bits 15-63. The value identifying TSF 985 includes... Figure 9 It is shown as Current_TSF B63-B15 = (000000…001)2 bits 15-63, for example, in this example, the 15th bit has been incremented to indicate the next TSF.

[0068] The second subfield can provide the unavailability start time 950 as signaled in ICR 940, and can include 9 bits, for example, bits 6-14 of a 64-bit field. The use of 9 bits allows the unavailability start time 950 to be identified in 64-microsecond granularity (0 microseconds, 64 microseconds, 128 microseconds, ...). This allows the unavailability start time subfield to indicate an unavailability start time up to 32.768 ms (which is the length of the TSF). This number of bits and granularity is merely an example, and other numbers of bits can be used in the subfield.

[0069] When TXOP responder station 910 transmits ICR 940 including the unavailability start time 950, TXOP responder station 910 may not transmit the entire 64-bit field, but may only transmit the bits associated with the unavailability start time subfield, for example, to save overhead. Therefore, as Figure 9 As shown, the unavailability start time subfield in ICR 940 can be signaled in 9 bits (000110010)2. ICR 940 can transmit a value of 30ms, and therefore TXOP responder station 910 intends to set the unavailability start time 950 to be... Figure 9 The time shown.

[0070] However, when TXOP holder 905 constructs the unavailability start time from the information in ICR 940, the TXOP holder may assume the unavailability start time is in TSF 980 and will calculate past times (e.g., before ICR 940). Therefore, TXOP holder 905 may not understand that the unavailability start time is in TSF 985, and may therefore fail to perform the appropriate actions associated with the duration of unavailability.

[0071] In some example implementations, the TXOP holder station 905 can determine whether the unavailability start time is in the current TSF 980 or in the next TSF 985. For example, the TXOP holder station 905 can compare the value (e.g., bits 6-14) in the unavailability start time subfield of ICR 940 with the value (e.g., bits 6-14) in the current TSF 980. If the unavailability start time is greater than or equal to the current value in TSF 980, the TXOP holder station 905 can determine that the unavailability start time is in the current TSF 980. On the other hand, if the unavailability start time is less than the current value in TSF 980, the TXOP holder station 905 can determine that the unavailability start time is in the next TSF 985. In this way, the TXOP holder station 905 can determine the unavailability start time 950 corresponding to ICR 940.

[0072] In other example implementations, ICR 940 may include additional indication of whether the unavailability start time applies to the current TSF or the next TSF. For example, ICR 940 may include a next window bit that has a value of 0 when the unavailability start time applies to the current TSF, or a value of 1 when the unavailability start time applies to the next TSF. In this way, TXOP responder station 910 explicitly indicates to TXOP holder station 905 the TSF in which the unavailability duration 960 begins. The next window bit may be a new bit added to ICR 940, or it may be a reused bit from the current ICR.

[0073] Therefore, the example implementation provides various operations that can be performed by the TXOP holder or TXOP responder to handle scenarios where the TXOP responder may not be available for a portion of the TXOP.

[0074] Example

[0075] In a first embodiment, a method includes: determining a transmission opportunity (TXOP) for transmitting to a station; processing an indication including an unavailability start time and unavailability duration occurring during the TXOP based on signaling received from the station; and performing operations related to the TXOP based on the indication.

[0076] In a second embodiment, according to the method of the first embodiment, the operation includes: generating a truncated physical layer protocol data unit (PPDU) for transmission to the station, the truncated physical layer protocol data unit (PPDU) including less data than all data to be transmitted to the station, wherein the truncated PPDU is transmitted to the station before the unavailability start time.

[0077] In the third embodiment, according to the method of the second embodiment, the truncated PPDU is transmitted in a timely manner for the station to transmit block acknowledgment (BA) before the unavailability start time.

[0078] In the fourth embodiment, according to the method of the first embodiment, the operation includes: generating a contention-free (CF) end message to terminate the TXOP for transmission to the station.

[0079] In a fifth embodiment, according to the method of the first embodiment, the operation includes: generating a Physical Layer Protocol Data Unit (PPDU) including data to be transmitted to the station for transmission to the station, wherein at least a portion of the PPDU is transmitted during the unavailability duration; determining that the station has not acknowledged the PPDU; and skipping the transmission parameters for retransmission of the PPDU or another PPDU.

[0080] In the sixth embodiment, according to the method of the fifth embodiment, the transmission parameters include one of the following: transmission rate, contention window (CW) size, or quality of service (QoS) retry counter (QSRC).

[0081] In a seventh embodiment, according to the method of the first embodiment, the operation includes: scheduling a transmission to a second station during the unavailability duration.

[0082] In the eighth embodiment, according to the method of the first embodiment, the method further includes: determining the power mode or power state of the station before the unavailability start time, and determining whether a frame including power information is received from the station during the unavailability duration.

[0083] In the ninth embodiment, according to the method of the eighth embodiment, the method further includes: when no frame is received, determining that the power mode or power state of the station at the end of the unavailability duration is the power mode or power state of the station before the start time of the unavailability.

[0084] In the tenth embodiment, according to the method of the eighth embodiment, the method further includes: when the frame is received, determining that the station is in the power mode or power state indicated in the power information when the frame is received.

[0085] In the eleventh embodiment, according to the method of the tenth embodiment, the power mode indicated in the power information includes an active power mode or a power saving mode, and the power state indicated in the power information includes a wake-up state or a sleep state.

[0086] In the twelfth embodiment, according to the method of the eighth embodiment, the apparatus includes a multi-link device (MLD) configured to maintain two or more links with the station.

[0087] In the thirteenth embodiment, according to the method of the twelfth embodiment, the method further includes: maintaining unavailability information of the station, wherein the unavailability status of the unavailability information applies to all links with the station among the two or more links.

[0088] In the fourteenth embodiment, according to the method of the twelfth embodiment, the method further includes: maintaining unavailability information of the station, wherein the unavailability information includes an unavailability state corresponding to each of the two or more links.

[0089] In the fifteenth embodiment, the method according to the fourteenth embodiment, including the indication of the unavailability start time and the unavailability duration, further includes an indication of the unavailability state of one of the two or more links to which the indication applies.

[0090] In a sixteenth embodiment, according to the method of the fourteenth embodiment, the method further includes: determining the unavailability state of one of the two or more links based on receiving the indication on one of the links.

[0091] In the seventeenth embodiment, according to the method of the first embodiment, the method further includes: processing an indication that the duration of the unavailability duration has been changed based on signaling received from the station during the unavailability duration.

[0092] In the eighteenth embodiment, according to the method of the seventeenth embodiment, the indication that the duration of the unavailability duration is changed indicates that the unavailability duration is canceled and the station is available.

[0093] In the nineteenth embodiment, according to the method of the first embodiment, the method further includes: processing a physical layer protocol data unit (PPDU) received in response to a trigger frame based on signaling received from the station, wherein the PPDU indicates that the device does not need to transmit an acknowledgment in response to the PPDU.

[0094] In a twentieth embodiment, according to the method of the first embodiment, the method further includes: determining that a transmission backoff for the TXOP has expired during the unavailability duration; and selecting a new transmission backoff to be applied after the unavailability duration, wherein the new transmission backoff is selected based on the current contention window of the TXOP.

[0095] In the twenty-first embodiment, according to the method of the first embodiment, the operation includes: generating a frame to be transmitted to the station for transmission to the station, wherein at least a portion of the frame was transmitted during the unavailability duration; determining that the station has not acknowledged the frame; and skipping changes to transmission parameters for retransmission of the frame or another frame.

[0096] In the twenty-second embodiment, according to the method of the twenty-first embodiment, the transmission parameters include one of the following: transmission rate, contention window (CW) size, or quality of service (QoS) retry counter (QSRC).

[0097] In the twenty-third embodiment, according to the method of the first embodiment, the indication includes a plurality of bits indicating the unavailability start time, and the method further includes: comparing the time indicated by the plurality of bits of the indication with the time of the current timing synchronization function (TSF); determining that the unavailability start time is in the current TSF when the time indicated by the plurality of bits is greater than or equal to the time of the current TSF; and determining that the unavailability start time is in the next TSF when the time indicated by the plurality of bits is less than the time of the current TSF.

[0098] In the 24th embodiment, according to the method of the first embodiment, the indication includes a plurality of bits indicating the start time of the unavailability and additional bits indicating whether the start time of the unavailability is in the current timing synchronization function (TSF) or in the next TSF.

[0099] In the twenty-fifth embodiment, according to the method of the first embodiment, the indication of the unavailability start time and the unavailability duration is received in the initial control response (ICR).

[0100] In the twenty-sixth embodiment, according to the method of the twenty-fifth embodiment, the ICR is received in response to an initial control frame (ICF) transmitted by the device that includes information related to the TXOP.

[0101] In the twenty-seventh embodiment, according to the method of the first embodiment, the device includes an access point (AP) station or a non-AP station.

[0102] In the twenty-eighth embodiment, according to the method of the first embodiment, the station includes a non-access point (AP) station.

[0103] In the twenty-ninth embodiment, a processor is configured to perform any one of the methods described according to the first to twenty-eighth embodiments.

[0104] In the thirtieth embodiment, a wireless communication device is configured to perform any one of the methods described according to the first to the twenty-eighth embodiments.

[0105] In a thirty-first embodiment, a method includes: processing an initial control frame (ICF) containing information related to a transmission opportunity (TXOP) for the station based on signaling received from a slave station; determining unavailability information including an unavailability start time and unavailability duration occurring during the TXOP; and generating an indication including the unavailability information for transmission to the station.

[0106] In the thirty-second embodiment, according to the method of the thirty-first embodiment, the unavailability duration includes a value up to the availability duration or a value based on the duration of the TXOP in the ICF.

[0107] In the thirty-third embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a contention-free (CF) end message terminating the TXOP based on signaling received from the station, wherein the CF end message resets the network allocation vector (NAV).

[0108] In the thirty-fourth embodiment, according to the method of the thirty-first embodiment, the method further includes: generating a frame including the power mode or power state of the device for transmission to the station during the unavailability duration.

[0109] In the thirty-fifth embodiment, according to the method of the thirty-fourth embodiment, the power mode includes an active power mode or a power saving mode, and the power state includes a wake-up state or a sleep state.

[0110] In the thirty-sixth embodiment, according to the method of the thirty-first embodiment, wherein the station maintains two or more links with the device, and the indication including the unavailability start time and unavailability duration also includes an indication of the unavailability status of one of the two or more links to which the indication applies.

[0111] In the thirty-seventh embodiment, according to the method of the thirty-first embodiment, the method further includes: generating an indication that the duration of the unavailability duration has been changed for transmission to the station during the unavailability duration.

[0112] In the thirty-eighth embodiment, according to the method of the thirty-seventh embodiment, the indication that the duration of the unavailability duration is changed indicates that the unavailability is cancelled.

[0113] In the thirty-ninth embodiment, according to the method of the thirty-first embodiment, the method further includes: determining that synchronization with the medium has been lost based on the fact that the device is unavailable during the unavailability duration; and performing a synchronization recovery operation, the synchronization recovery operation including performing a transmission with the network via the medium.

[0114] In the fortieth embodiment, according to the method of the thirty-ninth embodiment, the transmission is delayed by a predetermined amount after the end of the unavailability duration when no frame to the network allocation vector (NAV) is detected.

[0115] In the forty-first embodiment, according to the method of the thirty-ninth embodiment, the synchronization recovery operation includes a media access recovery process defined by IEEE 802.11be.

[0116] In the forty-second embodiment, according to the method of the thirty-first embodiment, the method further includes: processing a trigger frame based on signaling received from the station; and generating a physical layer protocol data unit (PPDU) in response to the trigger frame for transmission to the station, wherein the PPDU indicates that the station does not need to transmit an acknowledgment in response to the PPDU.

[0117] In the forty-third embodiment, according to the method of the thirty-first embodiment, the indication includes a plurality of bits indicating the start time of the unavailability and additional bits indicating whether the start time of the unavailability is in the current timing synchronization function (TSF) or in the next TSF.

[0118] In the forty-fourth embodiment, according to the method of the thirty-first embodiment, the apparatus includes an access point (AP) station or a non-AP station.

[0119] In the forty-fifth embodiment, according to the method of the thirty-first embodiment, the station includes an access point (AP) station.

[0120] In the forty-sixth embodiment, a processor is configured to perform any one of the methods described according to the thirty-first to forty-fifth embodiments.

[0121] In the forty-seventh embodiment, a wireless communication device is configured to perform any one of the methods described according to the thirty-first to forty-fifth embodiments.

[0122] Those skilled in the art will understand that the example embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Example hardware platforms for implementing the example embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Example embodiments of the methods described above may be embodied as programs containing lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0123] Although this application describes various embodiments that have different features in various combinations, those skilled in the art will understand that any feature of one embodiment can be combined with features of other embodiments in any way that is not expressly denied or that is not functionally or logically inconsistent with the operation of the device or the specified function of the disclosed embodiment.

[0124] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0125] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover modifications and variations thereof, provided they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus including processing circuitry coupled to a memory, wherein the processing circuitry is configured to: Determine the transfer opportunity (TXOP) to be used for transmission to the station; The processing includes indications of the start time and duration of unavailability that occur during the TXOP, based on signaling received from the station. as well as Perform operations related to the TXOP based on the instructions.

2. The apparatus of claim 1, wherein the operation includes the processing circuit being configured to: A truncated Physical Layer Protocol Data Unit (PPDU) is generated for transmission to the station. The truncated PPDU includes less data than all the data to be transmitted to the station, and the truncated PPDU is transmitted to the station before the unavailability start time.

3. The apparatus of claim 1, wherein the operation includes the processing circuit being configured to: Generate a contention-free CF end message to terminate the TXOP for transmission to the station.

4. The apparatus of claim 1, wherein the operation includes the processing circuit being configured to: A Physical Layer Protocol Data Unit (PPDU) is generated, comprising data to be transmitted to the station, for transmission to the station, wherein at least a portion of the PPDU is transmitted during the unavailability duration; It was determined that the station did not acknowledge the PPDU; as well as Skip the changes to the transmission parameters used for retransmission of the PPDU or another PPDU.

5. The apparatus of claim 4, wherein the transmission parameters include one of the following: transmission rate, contention window size (CW), or quality of service (QoS) retry counter (QSRC).

6. The apparatus of claim 1, wherein the operation includes the processing circuit being configured to: Transmissions scheduled to the second station during the duration of the unavailability.

7. The apparatus of claim 1, wherein the processing circuit is further configured to: Determine the power mode or power state of the station prior to the start time of the unavailability; and Determine whether a frame including power information is received from the station during the duration of the unavailability.

8. The apparatus of claim 7, wherein the processing circuit is further configured to: When no frame is received, it is determined that the power mode or power state of the station at the end of the unavailability duration is the same as the power mode or power state of the station before the start time of the unavailability.

9. The apparatus of claim 7, wherein the processing circuit is further configured to: When the frame is received, it is determined that the station is in the power mode or power state indicated in the power information at the time the frame is received.

10. The apparatus of claim 1, wherein the apparatus includes a multi-link device (MLD) configured to maintain two or more links with the station.

11. The apparatus of claim 10, wherein the processing circuit is further configured to: Maintain the unavailability information of the station, wherein the unavailability status of the unavailability information applies to all links with the station in the two or more links.

12. The apparatus of claim 10, wherein the processing circuit is further configured to: Maintain unavailability information for the station, wherein the unavailability information includes the unavailability status corresponding to each of the two or more links.

13. An apparatus including processing circuitry coupled to a memory, wherein the processing circuitry is configured to: The initial control frame (ICF) is processed based on the signaling received from the slave station. The ICF includes information related to the transmission opportunity (TXOP) for the slave station. Determine unavailability information including the start time and duration of unavailability during the TXOP; and Generate an indication including the unavailability information for transmission to the station.

14. The apparatus of claim 13, wherein the unavailability duration includes a value up to the availability duration or a value based on the duration of the TXOP in the ICF.

15. The apparatus of claim 13, wherein the processing circuit is further configured to: The contention-free CF end message terminating the TXOP is processed based on signaling received from the station, wherein the CF end message resets the network allocation vector NAV.

16. The apparatus of claim 13, wherein the processing circuit is further configured to: A frame including the power mode or power state of the device is generated for transmission to the station during the unavailability duration.

17. The apparatus of claim 13, wherein the station maintains two or more links with the apparatus, and the indication including the unavailability start time and unavailability duration further includes an indication of the unavailability status of one of the two or more links to which the indication applies.

18. The apparatus of claim 13, wherein the processing circuit is further configured to: An indication is generated that the duration of the unavailability period has been changed for transmission to the station during the unavailability period.

19. The apparatus of claim 13, wherein the processing circuit is further configured to: Based on the fact that the device is unavailable during the unavailability period, it is determined that synchronization with the medium has been lost; and Perform a synchronization recovery operation, which includes performing a transmission with the network via the medium.

20. The apparatus of claim 13, wherein the processing circuit is further configured to: The trigger frame is processed based on the signaling received from the station; and In response to the trigger frame, a Physical Layer Protocol Data Unit (PPDU) is generated for transmission to the station, wherein the PPDU indicates that the station does not need to transmit an acknowledgment in response to the PPDU.

Images