Access point (AP) assisted anchor channel medium synchronization

Abstract

A first station (STA) receives, from a second STA and via a primary channel, a first frame including an indication of a frame type of the first frame and an indication of a duration of a transmission following the first frame. After receiving the first frame, the first STA switches an operating channel from the primary channel to a secondary channel based on the frame type. The first STA transmits a second frame via the secondary channel at a transmission start time based on the duration of the transmission. The first STA switches from the secondary channel to the primary channel after the duration.

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. Provisional Application No. 63 / 616,112, filed December 29, 2023, the entire contents of which are incorporated herein by reference. Attached Figure Description

[0002] Examples of several embodiments of the various embodiments of this disclosure are described herein with reference to the accompanying drawings.

[0003] Figure 1 An example wireless communication network in which embodiments of the present disclosure may be implemented is shown.

[0004] Figure 2 This is a block diagram illustrating an example implementation of a station (STA) and an access point (AP).

[0005] Figure 3 An example of the Media Access Control (MAC) frame format is shown.

[0006] Figure 4 An example trigger frame is shown.

[0007] Figure 5 An example Multi-User Request Sending (MU-RTS) trigger frame is shown.

[0008] Figure 6 An example public information field is shown.

[0009] Figure 7 An example of a Request to Send (RTS) / Certify to Send (CTS) procedure is shown.

[0010] Figure 8 An example of a broadband RTS / CTS program is shown.

[0011] Figure 9 An example of a wideband RTS / CTS procedure using bandwidth signaling RTS frames is shown.

[0012] Figure 10 This is an example showing the MU-RTS / CTS program.

[0013] Figure 11 This is an example illustrating Multi-Master Channel (MPC) / Non-Master Channel Access (NPCA) STA operation.

[0014] Figure 12 The virtual and physical carrier sensing (CS) functions associated with the primary and secondary channels for MPC / NPCA STA and non-MPC / non-NPCA STA are shown.

[0015] Figure 13This is an example comparing the operations of concurrent CCA MPC / NPCA STA with those of non-concurrent CCA MPC / NPCA STA.

[0016] Figure 14 This is another example comparing the operations of concurrent CCA MPC / NPCA STA with those of non-concurrent CCA MPC / NPCA STA.

[0017] Figure 15 Example programs that can be executed by the AP in some cases are shown.

[0018] Figure 16 A sample program is shown, illustrating problems that may arise in some cases due to the operation of MPC / NPCA STA and non-MPC / non-NPCA STA.

[0019] Figure 17 An example program that can be executed by the implementation scheme in a system with MPC / NPCA components is shown.

[0020] Figure 18 An example program that can be executed by the MPC / NPCA component according to the implementation scheme is shown.

[0021] Figure 19 An example program is shown that coordinates the interaction between MPC / NPCA components in a wireless network according to an implementation scheme.

[0022] Figure 20 Additional example programs are shown for interactions between MPC / NPCA components in a coordinateable wireless network according to the implementation scheme.

[0023] Figure 21 An example process according to the implementation plan is shown.

[0024] Figure 22 Another example process according to the implementation scheme is shown.

[0025] Figure 23 Another example process according to the implementation scheme is shown. Detailed Implementation

[0026] In this disclosure, various embodiments are presented in the form of examples of how the disclosed techniques can be implemented and / or how the disclosed techniques can be practiced in environments and scenarios. It will be apparent to those skilled in the art that various changes in form and detail can be made therein without departing from the scope of the invention. After reading this specification, it will be apparent to those skilled in the art how to implement alternative embodiments. Embodiments of the invention are not to be limited to any of the described exemplary embodiments. Embodiments of this disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed exemplary embodiments can be combined to create additional embodiments within the scope of this disclosure. Any diagrams highlighting functionality and advantages are given for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in ways other than those shown. For example, actions listed in any flowchart can be reordered or optionally used only in certain embodiments.

[0027] The implementation scheme can be configured to operate as needed. When certain criteria are met, the disclosed mechanisms can be executed, for example, in stations, access points, radio environments, networks, or combinations thereof. Example standards may be based at least in part on, for example, wireless device or network node configuration, traffic load, initial system settings, packet size, service characteristics, or combinations thereof. Various example implementation schemes can be applied when one or more criteria are met. Therefore, example implementation schemes that selectively implement the disclosed protocols can be implemented.

[0028] In this disclosure, the terms “a” and “an” and similar phrases will be interpreted as “at least one” and “one or more”. Similarly, any term ending with the suffix “(s)” will be interpreted as “at least one” and “one or more”. In this disclosure, the term “may” is interpreted as “may, for example”. In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a variety of suitable possibilities that may or may not be used in one or more of the various embodiments. As used herein, the terms “comprises” and “composes of” enumerate one or more components of the element being described. The terms “comprises” and “includes” are interchangeable and do not exclude the inclusion of unlisted components in the element being described. In contrast, “composes of” provides a complete enumeration of the one or more components of the element being described. As used herein, the term “based on” can be interpreted as “at least partially based on” rather than, for example, “based on only”. As used herein, the term “and / or” indicates any possible combination of the enumerated elements. For example, "A, B and / or C" can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0029] If A and B are sets, and every element of A is also an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1, STA2} are: {STA1}, {STA2}, and {STA1, STA2}. The phrase “based on” (or equivalently “at least based on”) indicates that the phrase following the term “based on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more of the various embodiments. The phrase “in response to” (or equivalently “at least in response to”) indicates that the phrase following the phrase “in response to” is an example of one of a variety of suitable possibilities that may or may not be used in one or more different embodiments. The phrase “depends on” (or equivalently “at least depends on”) indicates that the phrase following the phrase “depends on” is an example of one of a variety of suitable possibilities that may or may not be used in one or more different embodiments. The phrase “adopt / use” (or equivalently “at least adopt / use”) indicates that the phrase following the phrase “adopt / use” is an example of one of a variety of suitable possibilities that may or may not be used in one or more different embodiments.

[0030] The term "configured" can refer to the capabilities of a device, whether the device is in an operational or non-operational state. "Configured" can refer to specific settings within the device that affect its operational characteristics, regardless of whether the device is in an operational or non-operational state. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within the device to provide specific characteristics to the device, whether the device is in an operational or non-operational state. Similarly, the term "control messages generated in the device" can mean that the control messages have parameters that can be used to configure specific characteristics in the device or to perform certain actions in the device, regardless of whether the device is in an operational or non-operational state.

[0031] In this disclosure, a parameter (or equivalently referred to as a field or information element: IE) may include one or more information objects, and an information object may include one or more other objects. For example, if parameter (IE)N includes parameter (IE)M, and parameter (IE)M includes parameter (IE)K, and parameter (IE)K includes parameter (information element)J, then, for example, N includes K, and N includes J. In the example implementation, when one or more messages / frames include multiple parameters, this means that a parameter among the multiple parameters is in at least one of the one or more messages / frames, but not necessarily in every one of the one or more messages / frames.

[0032] Many of the proposed features are described as optional using the word "may" or parentheses. For brevity and readability, this disclosure does not explicitly describe every permutation that can be obtained by selecting from the group of optional features. This disclosure should be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features can be embodied in seven different ways: having only one of the three possible features, having any two of the three possible features, or having three of the three possible features.

[0033] Many elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as an element that performs the defined function and has the defined interface to other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (e.g., hardware with biological elements), or combinations thereof, all of which may be behaviorally equivalent. For example, a module can be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript). It is possible to implement modules using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are typically programmed using hardware description languages ​​(HDLs), such as VHSIC Hardware Description Language (VHDL) or Verilog. These languages ​​configure the connections between internal hardware modules with limited functionality on the programmable device. The aforementioned techniques are often used in combination to achieve the desired result of functional modules.

[0034] Figure 1 An example wireless communication network in which embodiments of the present disclosure may be implemented is shown.

[0035] like Figure 1 As shown, an example wireless communication network may include an IEEE 802.11 (WLAN) infrastructure network 102. The WLAN infrastructure network 102 may include one or more Basic Service Sets (BSS) 110 and 120 and a Distribution System (DS) 130.

[0036] BSS 110-1 and 110-2 each include a set of access points (APs or AP STAs) and at least one station (STA or non-AP STA). For example, BSS 110-1 includes AP 104-1 and STA 106-1, and BSS 110-2 includes AP 104-2 and STAs 106-2 and 106-3. The APs and at least one STA in the BSS perform association procedures to communicate with each other.

[0037] The DS 130 can be configured to connect BSS 110-1 and BSS 110-2. Therefore, the DS 130 can enable Extended Service Set (ESS) 150. Within the ESS 150, APs 104-1 and 104-2 are connected via the DS 130 and can have the same Service Set Identifier (SSID).

[0038] The WLAN infrastructure network 102 can be coupled to one or more external networks. For example, such as Figure 1 As shown, WLAN infrastructure network 102 can be connected to another network 108 (e.g., 802.X) via portal 140. Portal 140 can act as a bridge connecting DS 130 of WLAN infrastructure network 102 to the other network 108.

[0039] Figure 1 The example wireless communication network shown may further include one or more self-organizing networks or independent BSSs (IBSSs). A self-organizing network or IBSS is a network of multiple STAs included within each other's communication range. The multiple STAs are configured such that they can communicate with each other using direct peer-to-peer communication (i.e., without through an AP).

[0040] For example, in Figure 1 In this configuration, STAs 106-4, 106-5, and 106-6 can be configured to form a first IBSS 112-1. Similarly, STAs 106-7 and 106-8 can be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Instead, STAs within an IBSS are managed in a distributed manner. STAs forming an IBSS can be fixed or mobile.

[0041] A STA, serving as a predefined functional medium, may include a Media Access Control (MAC) layer conforming to the IEEE 802.11 standard. The physical layer interface of the radio medium can be used in both AP and non-AP stations (STAs). STAs may also be referred to using various other terms, including mobile terminal, radio device, radio transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" may be used to refer to a STA participating in uplink multi-user multiple-input multiple-output (MU MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmissions.

[0042] Physical Layer (PHY) Protocol Data Units (PPDUs) can be composite structures, comprising a PHY preamble and a payload in the form of a PHY Service Data Unit (PSDU). For example, a PSDU may include a PHY preamble and a header and / or one or more MAC Protocol Data Units (MPDUs). The information provided in the PHY preamble can be used by the receiving device to decode subsequent data in the PSDU. When the PPDU is transmitted over a bonded channel (a channel formed by channel bonding), the preamble field can be copied and transmitted in each of the multiple component channels. The PHY preamble may include both a traditional portion (or "traditional preamble") and a non-traditional portion (or "non-traditional preamble"). The traditional preamble can be used for purposes such as packet detection, automatic gain control, and channel estimation. The traditional preamble is also typically used to maintain compatibility with legacy equipment. The format, encoding, and information provided in the non-traditional portion of the preamble are based on the specific IEEE 802.11 protocol to be used for transmitting the payload.

[0043] A frequency band can include one or more sub-bands or frequency channels. For example, PPDUs conforming to IEEE 802.11n, 802.11ac, 802.11ax, and / or 802.11be standard modifications can be transmitted on 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which can be divided into multiple 20 MHz channels. PPDUs can be transmitted through physical channels with a minimum bandwidth of 20 MHz. Alternatively, a larger channel can be formed by channel bonding a 20 MHz primary channel with one or more 20 MHz secondary channels. For example, PPDUs can be transmitted on physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 320 MHz by bonding a 20 MHz primary channel with one, three, seven, or fifteen secondary channels, respectively. The primary channel is a common channel used by all STAs, on which the AP sends management frames to ensure that all STAs (regardless of whether channel bonding is supported) can receive the data.

[0044] Figure 2 This is a block diagram illustrating example implementations of the STA 210 and AP 260. (See diagram for example.) Figure 2 As shown, STA 210 may include at least one processor 220, memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, memory 280, and at least one transceiver 290. Processors 220 / 270 may be operatively connected to memory 230 / 280 and / or transceiver 240 / 290.

[0045] Processors 220 / 270 can implement the functions of the PHY layer, MAC layer, and / or logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processors 220 / 270 may include one or more processors and / or one or more controllers. For example, one or more processors and / or one or more controllers may include, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), logic circuitry, or a chipset.

[0046] Memory 230 / 280 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage units. Memory 230 / 280 may include one or more non-transitory computer-readable media. Memory 230 / 280 may store computer program instructions or code that can be executed by processor 220 / 270 to perform one or more of the operations / implementations discussed in this application. Memory 230 / 280 may be implemented (or located) within processor 220 / 270 or external to processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 in various ways known in the art.

[0047] Transceiver 240 / 290 can be configured to transmit / receive radio signals. In some cases, transceiver 240 / 290 can implement the PHY layer of the corresponding device (STA 210 or AP 260). In some cases, STA 210 and / or AP 260 can be multi-link devices (MLDs), which are devices capable of operating on multiple links defined by the IEEE 802.11 standard. Therefore, STA 210 and / or AP 260 can each implement multiple PHY layers. One or more of transceivers 240 / 290 can be used to implement multiple PHY layers.

[0048] Figure 3An example format of a MAC frame is shown. In operation, the STA can construct a subset of MAC frames for transmission and can decode a subset of received MAC frames during verification. The specific subset of frames that the STA can construct and / or decode can be determined by the functions supported by the STA. The STA can verify received MAC frames using the Frame Check Sequence (FCS) contained within the frame and can interpret certain fields based on the MAC header of all frames.

[0049] like Figure 3 As shown, a MAC frame includes a MAC header, a variable-length frame body, and a frame check sequence (FCS).

[0050] The MAC header includes a frame control field, an optional duration / ID field, an address field, an optional sequence control field, an optional QoS control field, and an optional HT control field.

[0051] The frame control field includes the following subfields: protocol version, type, subtype, "to DS", "from DS", "more fragments", retry, power management, "more data", "protected frames" and "+HTC".

[0052] The size and placement of the protocol version subfield remain unchanged across all revisions of the IEEE 802.11 standard. For MAC frames, the value of the protocol version subfield is 0.

[0053] The Type and Subtype subfields together identify the function of a MAC frame. There are three frame types: control, data, and management. Each frame type has several defined subtypes. Bits within the subtype subfield are used to indicate specific modifications to the basic data frame (subtype 0). For example, in a data frame, the most significant bit (MSB) of the subtype subfield, bit 7 (B7) of the frame control field, is defined as the QoS subfield. When the QoS subfield is set to 1, it indicates a QoS data frame, i.e., a data frame that includes the QoS control field in its MAC header. When set to 1 in the data subtype, the second MSB of the subtype field, bit 6 (B6) of the frame control field, indicates a data frame that does not include a frame body field.

[0054] The “To DS” subfield indicates whether the data frame is directed to the Distribution System (DS). The “From DS” subfield indicates whether the data frame originated from the DS.

[0055] In all data or management frames that have another fragment following the MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) carried by the MAC frame, the "More Fragments" subfield is set to 1. In all other frames in which the "More Fragments" subfield exists, the "More Fragments" subfield is set to 0.

[0056] In any data or management frame that is a retransmission of an earlier frame, the retry subfield is set to 1. In all other frames in which the retry subfield exists, it is set to 0. The receiving STA uses this indication to assist in its process of eliminating duplicate frames. These rules do not apply to frames sent by the STA according to the block protocol.

[0057] The power management subfield is used to indicate the power management mode of the STA.

[0058] The “More Data” subfield, in Power Saving (PS) mode, indicates to the STA that a bufferable unit (BU) is buffered at the AP for the STA. The “More Data” subfield is valid in separately addressed data or management frames transmitted by the AP to the STA in PS mode. The “More Data” subfield is set to 1 to indicate that at least one additional buffered BU exists for the STA.

[0059] If the frame body field contains information that has been processed by an cryptographic encapsulation algorithm, the protected frame subfield is set to 1.

[0060] The +HTC subfield indicates that the MAC frame contains the HT control field.

[0061] The Duration / ID field in the MAC header indicates different content depending on the frame type and subtype, as well as the QoS capabilities of the sending STA. For example, in a control frame of the Power Saving Polling (PS-Poll) subtype, the Duration / ID field carries the Association Identifier (AID) of the STA that has transmitted a frame in 14 least significant bits (LSBs), and the two most significant bits (MSBs) are set to 1. In other frames transmitted by the STA, the Duration / ID field contains a duration value (in microseconds) for the receiver to use to update the Network Allocation Vector (NAV). The NAV is a counter indicating to the STA the amount of time during which the STA must postpone access to the shared medium.

[0062] A MAC frame format can contain up to four address fields. These address fields are used to indicate the Basic Service Set Identifier (BSSID), source address (SA), destination address (DA), transport address (TA), and receive address (RA). Some frames may not contain certain address fields. The use of certain address fields can be specified by the relative order of address fields (1-4) within the MAC header, regardless of the address type present in those fields. Specifically, address 1 always identifies the intended receiver of the frame, and address 2 (if present) always identifies the sender of the frame.

[0063] The sequence control field includes two subfields: a sequence number subfield and a fragment number subfield. In a data frame, the sequence number subfield indicates the sequence number of the MSDU (if not in an aggregated MSDU (A-MSDU)) or A-MSDU. In a management frame, the sequence number subfield indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment of the MSDU or MMPDU. In the first or only fragment of an MSDU or MMPDU, the fragment number is set to 0 and increments by one for each subsequent fragment of that MSDU or MMPDU. In a MAC Protocol Data Unit (MPDU) containing an A-MSDU or in an MPDU containing an unfragmented MSDU or MMPDU, the fragment number is set to 0. The fragment number remains constant throughout all retransmissions of the fragment.

[0064] The QoS control field identifies the service category (TC) or service flow (TS) to which the MAC frame belongs. The QoS control field can also indicate various other QoS-related, A-MSDU-related, and mesh-related information about the frame. This information can vary depending on the frame type, frame subtype, and the type of transport STA. The QoS control field exists in all data frames where the QoS subfield of the subtype subfield is equal to 1.

[0065] The HT control field exists in QoS data frames, QoS empty frames, and management frames, which are determined by the +HTC subfield of the frame control field.

[0066] The frame body field is a variable-length field that contains information specific to each frame type and subtype. The frame body may include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.

[0067] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated on all fields of the MAC header and frame body.

[0068] Figure 4 Example trigger frame 400 is shown. Trigger frame 400 may correspond to the basic trigger frame defined in the existing IEEE 802.11ax standard amendment. The AP can use trigger frame 400 to allocate resources to one or more STAs and request one or more TB PPDU transmissions from one or more STAs. Trigger frame 400 may also carry other information required by the STA to transmit TB PPDUs to the AP.

[0069] like Figure 4 As shown, trigger frame 400 includes a frame control field, a duration field, a receiver address (RA) field, a sender address (TA) field, a public information field, a user list information field, a padding field, and an FCS field.

[0070] The frame control field includes the following subfields: protocol version, type, subtype, to DS, from DS, more fragments, retry, power management, more data, protected frames, and +HTC.

[0071] The duration field indicates various contents depending on the frame type and subtype, as well as the QoS capabilities of the sending STA. For example, in a control frame of the Power Saving Polling (PS-Poll) subtype, the duration field carries the association identifier (AID) of the STA that has transmitted the frame in 14 least significant bits (LSBs), and both most significant bits (MSBs) are set to 1. In other frames transmitted by the STA, the duration field contains a duration value (in microseconds) for the receiver to use to update the Network Allocation Vector (NAV).

[0072] The RA field is the address of the STA intended to receive an incoming transmission from the transmitting station. If trigger frame 400 is addressed to a STA belonging to a single BSS, then the TA field is the address of the STA transmitting trigger frame 400. If trigger frame 400 is addressed to a STA from at least two different BSSs in a set of multiple BSSIDs, then the TA field is the BSSID that was transmitted.

[0073] The public information field can have the format shown in Public Information Field 600, which is further described below. The public information field specifies the trigger frame type of trigger frame 400, the transmission power of trigger frame 400 in dBm, and several key parameters of the TB PPDU transmitted by the STA in response to trigger frame 400. The trigger frame type used by the AP to receive QoS data using the UL MU is called the basic trigger frame.

[0074] The user list information field is included in the user information field for each STA addressed in trigger frame 400. Each STA's user information field includes an AID subfield, a RU allocation subfield, a spatial flow (SS) allocation subfield, an MCS subfield used by the STA in the TB PPDU transmitted in response to trigger frame 400, and trigger-related user information subfields. The AP can use the trigger-related user information subfields to specify the preferred access class (AC) for each STA. The preferred AC setting can be determined by the minimum priority AC traffic sent by the participating STAs. The AP determines the list of participating STAs, and the BW, MCS, RU allocation, SS allocation, Tx power, preferred AC, and maximum duration for each participating STA's TB PPDU.

[0075] A padding field may optionally be present in trigger frame 400 to extend the frame length, thus giving the receiver STA sufficient time to prepare a transmission response within one SIFS (Short Interframe Space) after receiving the frame. The padding field (if present) is at least two octets in length and is set to all 1s.

[0076] The STA uses the FCS field to verify received frames and interprets certain fields based on the frame's MAC header.

[0077] Figure 5 Example Multi-User Request Transmission (MU-RTS) trigger frame 500 is shown. The MU-RTS trigger frame 500 can be used by an AP to request simultaneous CTS frames from multiple STAs to transmit downlink (DL) MU PPDUs to multiple STAs. Figure 5 As shown, the MU-RTS trigger frame 500 may include a frame control field, a duration field, an RA field, a TA field, a common information field, one or more user information fields, a padding field, and an FCS field. The frame control field, TA field, RA field, padding field, and FCS field may be similar to their corresponding fields in the trigger frame 400 described above. The common information field may have the format shown in the common information field 600, which is further described below. The duration field may be set to the time (in microseconds) required to transmit the DL MU PPDU, plus the time required to transmit one CTS frame, one ACK frame (if needed), and three SIFS cycles.

[0078] One or more user information fields correspond to one or more STAs requested by MU-RTS trigger frame 500. For example... Figure 5 As shown, the user information field may include an AID12 subfield, an RU allocation subfield, reserved bits, and a PS 160 subfield. The AID12 subfield includes the associated identifier of the STA to which the user information field is addressed. The RU allocation subfield indicates the channel on which the requested STA will transmit CTS frames. In the example, this channel may include a primary 20 MHz channel, a primary 40 MHz channel, a primary 80 MHz channel, a primary 160 MHz channel, an 80+80 MHz channel, or a 320 MHz channel.

[0079] Figure 6 Example common information field 600 is shown. For example, common information field 600 could be an example implementation of the common information field of trigger frame 400 or MU-RTS trigger frame 500. Figure 6As shown, the public information field 600 may include the following subfields: trigger type, UL length, more TF, CS requirement, UL BW, GI and HE / EHT-LTF type / trigger TXS mode, first reserved subfield, HE / EHT-LTF symbol number, second reserved subfield, LDPC extra symbol segment, AP Tx power, pre-FEC fill factor, PE disambiguation, UL space reuse, third reserved subfield, HE / EHT P160, special user information field flag, EHT reserved subfield, fourth reserved subfield, and trigger-related public information subfield. The Trigger Type subfield, UL Length subfield, More TF subfield, CS Requirement subfield, UL BW subfield, GI and HE-LTF Type / Trigger TXS Mode subfield, First Reserved Subfield, HE / EHT-LTF Symbol Count subfield, Second Reserved Subfield, LDPC Additional Symbol Segment subfield, AP Tx Power subfield, Pre-FEC Fill Factor subfield, PE Disambiguation subfield, UL Space Reuse subfield, Third Reserved Subfield, HE / EHT P160 subfield, Special User Information Field Flag subfield, EHT Reserved Subfield, Fourth Reserved Subfield, and Trigger-Related Public Information subfield may have the same content and interpretation as the corresponding subfields of the EHT variant public information fields defined in the IEEE 802.11be draft revision (“IEEE P802.11be / D3.1, March 2023”).

[0080] Figure 7 Example 700 of a Request to Send (RTS) / Certify to Send (CTS) procedure is shown. Example 700 can be an example of an RTS / CTS procedure as defined in Section 10.3.2.9 of the IEEE 802.11 draft standard “IEEE P802.11-REVme™ / D3.0, April 2023”. Figure 7 As shown, example 700 can include STAs 702 and 704. Other STAs of the same BSS can also be within the communication range of STAs 702 and 704.

[0081] In the example, STA 702 can transmit RTS frame 706 to STA 704. STA 702 can transmit RTS frame 706 to protect the transmission of data frame 710, which STA 702 intends to transmit, from the influence of a hidden STA. RTS frame 706 may include a duration / ID field. The duration / ID field can be set to the time (in microseconds) required to transmit data frame 710, plus a CTS frame, plus an ACK frame (if needed), plus three SIFS (Short Interframe Spacing) periods.

[0082] In the example, STA 704 can respond to RTS frame 706 by transmitting CTS frame 708 to STA 702. CTS frame 708 can be transmitted in one SIFS cycle following RTS frame 706. STA 704 can respond to RTS frame 706 when it is addressed and after considering NAV, unless NAV is set by a frame originating from STA 702. STA 704 can respond to RTS frame 706 when it is addressed and if NAV indicates idle. For non-S1G STAs, NAV indicates idle when the NAV count is 0 or when the NAV count is not zero, but the non-bandwidth signaling TA obtained from the TA field of RTS frame 706 matches the stored TXOP holder address. For S1G STA, NAV indicates idle when both NAV and RID (Response Indication Delay) counters are 0, or when either NAV or RID counters are not zero, but the TA field of RTS frame 706 matches the stored TXOP holder address.

[0083] STA 704 can set the RA field of CTS frame 708 to the non-bandwidth signaling TA obtained from the TA field of RTS frame 706. STA 704 can set the duration field of CTS frame 708 based on the duration / ID field of RTS frame 706, i.e., set it to be equal to the value of the duration / ID field of RTS frame 706, wherein the duration field is adjusted by subtracting the time required to transmit CTS frame 708 and one SIFS period.

[0084] Upon receiving CTS frame 708, STA 702 may wait one SIFS cycle before transmitting data frame 710. STA 704 may transmit ACK frame 712 in response to data frame 710. STA 704 may transmit ACK frame 712 one SIFS after receiving data frame 710.

[0085] For example, a STA receiving RTS frame 706 can set its NAV based on the duration / ID field of RTS frame 706. Another STA receiving CTS frame 708 can set its NAV based on the duration field of CTS frame 708. Therefore, other STAs can access the channel without using EDCA until the transmission of ACK frame 712 ends.

[0086] Figure 8 Example 800 of a broadband RTS / CTS program is shown. Figure 8As shown, example 800 may include STAs 802 and 804. Other STAs may also be within the communication range of STAs 802 and 804. STAs 802 and 804 may each operate on a primary channel (PCH) and a secondary channel (SCH). By way of example and not limitation, the PCH may correspond to a 20 MHz primary channel, and the SCH may correspond to a 20 MHz secondary channel.

[0087] Example 800 can begin with STA 802 accessing both the PCH and SCH to simultaneously transmit RTS frames 806-1 and 806-2 to STA 804 on the PCH and SCH respectively. In this example, RTS frames 806-1 and 806-2 can be transmitted in a non-HT repeating PPDU with a bandwidth equal to the combined bandwidth of the PCH and SCH (e.g., 40 MHz). In this implementation, before transmitting RTS frames 806-1 and 806-2, STA 802 can check the NAV associated with the PCH. If the NAV associated with the PCH indicates that the PCH is idle, STA 802 can perform an idle channel assessment (CCA) on both the PCH and SCH. The CCA can include determining whether the received signal energy on the channel exceeds an energy detection (ED) threshold. When the received signal energy on the channel exceeds the ED threshold, the CCA returns a "channel busy" state, and when the received signal energy on the channel is below the ED threshold, the CCA returns a "channel idle" state. If the CCA indicates "channel idle" on both the PCH and SCH, the STA 802 can access both the PCH and SCH to transmit RTS frames 806-1 and 806-2.

[0088] RTS frames 806-1 and 806-2 can be repeated frames. RTS frames 806-1 and 806-2 can contain a duration field indicating the time (in microseconds) required to transmit data frame 810, plus a CTS frame, plus an ACK frame, plus three SIFS.

[0089] After receiving RTS frames 806-1 and 806-2, other STAs within the communication range of STA 802 can set the NAV associated with the PCH based on RTS frame 806-1. In some implementations, other STAs may not need to maintain the NAV for the SCH.

[0090] Upon receiving RTS frames 806-1 and 806-2, STA 804 responds to STA 802 by transmitting CTS frames 808-1 and 808-2 on the PCH and SCH, respectively. CTS frames 808-1 and 808-2 can be transmitted after SIFS has elapsed since STA 804 received RTS frames 806-1 and 806-2, respectively. In one implementation, STA 804 indicates that the PCH is idle based on the NAV associated with the PCH and transmits CTS frames 808-1 and 808-2 on the PCH and SCH, respectively. In another implementation, STA 804 may not maintain an NAV for the SCH, or may not check the NAV associated with the SCH before transmitting CTS frames 808-1 and 808-2.

[0091] After receiving CTS frames 808-1 and 808-2, other STAs within the communication range of STA 804 can set the NAV associated with the PCH based on CTS frame 808-1. In some implementations, other STAs may not need to maintain the NAV for the SCH.

[0092] After receiving CTS frames 808-1 and 808-2, STA 802 can continue transmitting data frame 810 on both PCH and SCH. Data frame 810 can be transmitted after SIFS has elapsed since STA 802 received CTS frames 808-1 and 808-2. In this implementation, STA 802 can only continue transmitting data frame 810 on both PCH and SCH if CTS frame 808-1 is received on PCH. That is, STA 802 may not need to receive CTS frame 808-2 on SCH to transmit data frame 810 on both SCH and PCH.

[0093] In this implementation, STA 804 can acknowledge data frame 810 by transmitting ACK frames 812-1 and 812-2 on PCH and SCH respectively. ACK frames 812-1 and 812-2 can be transmitted after SIFS has elapsed since STA 804 received data frame 810.

[0094] Figure 9 Example 900 of a wideband RTS / CTS procedure using bandwidth signaling RTS frames is shown. Figure 9 As shown, example 900 may include STAs 902 and 904. Other STAs may also be within the communication range of STAs 902 and 904. STAs 902 and 904 may each operate on a primary channel (PCH) and a secondary channel (SCH). By way of example and not limitation, the PCH may correspond to a 20 MHz primary channel, and the SCH may correspond to a 20 MHz secondary channel.

[0095] Example 900 can begin with STA 902 accessing both the PCH and SCH to simultaneously transmit RTS frames 906-1 and 906-2 to STA 904 on the PCH and SCH respectively. In this example, RTS frames 906-1 and 906-2 can be transmitted in a non-HT repeating PPDU with a bandwidth equal to the combined bandwidth of the PCH and SCH (e.g., 40 MHz). In this implementation, before transmitting RTS frames 906-1 and 906-2, STA 902 can check the NAV associated with the PCH. If the NAV associated with the PCH indicates that the PCH is idle, STA 902 can perform CCA on both the PCH and SCH. CCA can include determining whether the received signal energy on the channel exceeds an ED threshold. When the received signal energy on the channel exceeds the ED threshold, CCA returns to a "channel busy" state, and when the received signal energy on the channel is below the ED threshold, CCA returns to a "channel idle" state. If the CCA indicates "channel idle" on both the PCH and SCH, the STA 902 can access both the PCH and SCH to transmit RTS frames 906-1 and 906-2.

[0096] RTS frames 906-1 and 906-2 can be repeated frames. RTS frames 906-1 and 906-2 can contain a duration field indicating the time (in microseconds) required to transmit data frame 910, plus a CTS frame, plus an ACK frame, plus three SIFS.

[0097] In Example 900, RTS frames 906-1 and 906-2 can be bandwidth signaling RTS frames. That is, RTS frames 906-1 and 906-2 can each contain a field indicating the bandwidth (e.g., 40 MHz) of the PPDU carrying RTS frames 906-1 and 906-2.

[0098] After receiving RTS frames 906-1 and 906-2, other STAs within the communication range of STA 902 can set the NAV associated with the PCH based on RTS frame 906-1. In some implementations, other STAs may not need to maintain the NAV for the SCH.

[0099] Upon receiving RTS frames 906-1 and 906-2, STA 904 can decode the field indicating the bandwidth of the PPDU carrying RTS frames 906-1 and 906-2. The PPDU bandwidth can indicate to STA 904 that STA 902 expects STA 904 to respond with CTS frames on both the PCH and SCH. In one implementation, STA 904 can check the NAV associated with the PCH before responding to RTS frames 906-1 and 906-2. In another implementation, STA 904 may not maintain an NAV for the SCH, or may not check the NAV associated with the SCH before responding to RTS frames 906-1 and 906-2. In yet another implementation, if the NAV associated with the PCH indicates that the PCH is idle, STA 904 can perform CCA on both the PCH and SCH. In one implementation, if the CCA indicates "channel idle" on both the PCH and SCH, the STA 904 can respond on both the PCH and SCH. In another implementation, the STA 904 can only respond on the PCH if the CCA indicates "channel idle" on the PCH and "channel busy" on the SCH. In yet another implementation, if the NAV associated with the PCH is not zero, the STA 904 may not respond on either the PCH or SCH.

[0100] In Example 900, CCA returns "Channel Idle" on the PCH and "Channel Busy" on the SCH. Therefore, STA 904 can transmit CTS frame 908 only on the PCH. Thus, the bandwidth of CTS frame 908 can be narrower than the PPDU bandwidth indicated in RTS frames 906-1 and 906-2. CTS frame 908 can be transmitted after SIFS has elapsed since STA 904 received RTS frames 906-1 and 906-2, respectively.

[0101] After receiving CTS frame 908, other STAs within the communication range of STA 904 can set the NAV associated with PCH based on CTS frame 908.

[0102] After receiving CTS frame 908, STA 902 can continue transmitting data frame 910 on the PCH. Data frame 910 can be transmitted after SIFS has elapsed since STA 902 received CTS frame 908. In another implementation, STA 904 can acknowledge data frame 910 by transmitting ACK frame 912 on the PCH. ACK frame 912 can be transmitted after SIFS has elapsed since STA 904 received data frame 910.

[0103] Figure 10This is Example 1000 illustrating a Multi-User Request to Send (MU-RTS) / Certify to Send (CTS) procedure. Example 1000 may be an example of a MU-RTS / CTS procedure as defined in Section 26.2.6 of the IEEE 802.11 draft standard (“IEEE P802.11-REVme™ / D3.0, April 2023”). Figure 10 As shown, Example 1000 may include AP 1002 and STAs 1004 and 1006. STAs 1004 and 1006 may be associated with AP 1002. For illustrative purposes, Example 1000 also illustrates STAs (OBSS STAs) of the Overlapping Basic Service Set (OBSS) relative to the BSS of AP 1002. Figure 10 As shown, the OBSS STA can be hidden from AP 1002 (outside the communication range of AP 1002) or visible to AP 1002 (within the communication range of AP 1002).

[0104] In Example 1000, AP 1002 intends to transmit Downlink (DL) Multi-User (MU) PPDU 1014 to STAs 1004 and 1006. DL MU PPDU 1014 may include data from each of STAs 1004 and 1006. DL MU PPDU 1014 may occupy multiple channels (e.g., 20 MHz channels). Each of the multiple channels may carry data from the corresponding STA (e.g., STA 1004, STA 1006) served by DL MU PPDU 1014.

[0105] like Figure 10 As shown, to protect the transmission of DL MU PPDU 1014 to STAs 1004 and 1006 from interference by OBSS STAs hidden from AP 1002, AP 1002 can use the MU-RTS / CTS procedure to initiate a TXOP and protect the TXOP frame exchange sequence. AP 1002 can initiate a TXOP by transmitting an MU-RTS trigger frame 1008, which requests simultaneous CTS frame transmission from STAs 1004 and 1006.

[0106] MU-RTS trigger frame 1008 can have the following characteristics: Figure 5The format shown in the MU-RTS trigger frame 500 is as follows. Therefore, the MU-RTS trigger frame 1008 may include a frame control field, a duration field, an RA field, a TA field, a common information field, one or more user information fields, a padding field, and an FCS field. The duration field can be set to the time (in microseconds) required to transmit the DL MU PPDU 1014, plus the time required to transmit one CTS frame, one ACK frame (if needed), and three SIFS cycles.

[0107] One or more user information fields correspond to one or more STAs requested by the MU-RTS trigger frame. In Example 1000, the MU-RTS trigger frame 1008 may include user information fields for each of STAs 1004 and 1006, indicating that the CTS frame was requested from each of STAs 1004 and 1006. Figure 8 As shown, the user information field may include an AID12 subfield, an RU allocation subfield, reserved bits, and a PS 160 subfield. The AID12 subfield includes the associated identifier of the STA to which the user information field is addressed. The RU allocation subfield indicates the channel on which the requested STA will transmit CTS frames. In the example, this channel may include a primary 20 MHz channel, a primary 40 MHz channel, a primary 80 MHz channel, a primary 160 MHz channel, an 80+80 MHz channel, or a 320 MHz channel.

[0108] AP 1002 can transmit MU-RTS trigger frames 1008 in PPDUs that occupy one or more channels (e.g., 20 MHz channels). In the example, for each channel occupied by a PPDU carrying MU-RTS trigger frames 1008, AP 1002 can request at least one non-AP STA to transmit CTS frames occupying said channel. In the example, AP 1002 may not request non-AP STAs to transmit CTS frames occupying channels not occupied by PPDUs carrying MU-RTS trigger frames 1008.

[0109] After transmitting MU-RTS trigger frame 1008, AP 1002 may wait until it receives the PHYTXEND.confirm primitive of the transmitted MU-RTS trigger frame 1008 from its MAC layer to begin the CTSTimeout interval, i.e., aSIFSTime + aSlotTime + aRxPHYStartDelay. In an implementation, aSIFSTime may include the nominal time (in microseconds) required from the end of receiving the PPDU[+SigExt] on the radio medium until the MAC and PHY have processed any frames therein and responded with the start of the WM of the PPDU containing the earliest possible response frame. In an implementation, aSlotTime may include the duration of the backoff slot used by the STA when accessing the radio medium. In an implementation, aRxPHYStartDelay may include the duration from the start of the PPDU at the receiver's antenna to the earlier publication of the PHYRXEARLYSIG.indication (if transmitted) or PHY-RXSTART.indication primitive. If the MAC layer does not receive the PHY-RXEARLYSIG.indication or PHY-RXSTART.indication primitive during the CTSTimeout interval, AP 1002 can conclude that the transmission of MU-RTS trigger frame 1008 has failed, and if MU-RTS trigger frame 1008 has initiated a TXOP, AP 1002 can invoke its backoff procedure. If the MAC layer receives the PHY-RXEARLYSIG.indication or PHY-RXSTART.indication primitive during the CTSTimeout interval, the MAC layer can wait for the corresponding PHY-RXEND.indication primitive to determine whether the transmission of MU-RTS trigger frame 1008 was successful. Any CTS frame received from a non-APSTA addressed by MU-RTS trigger frame 1008 before the PHY-RXEND.indication primitive should be interpreted as a successful transmission of MU-RTS trigger frame 1008, thus allowing the frame exchange sequence to continue. Any other type of frame received should be interpreted as a transmission failure of MU-RTS trigger frame 1008. AP 1002 can process the received frame, and if MU-RTS trigger frame 1008 has initiated a TXOP, AP 1002 will invoke its backoff procedure upon discovering the PHY-RXEND.indication primitive.

[0110] In Example 1000, after receiving MU-RTS trigger frame 1008, STAs 1004 and 1006 respond by transmitting CTS frames 1010 and 1012 to AP 1002, respectively. In this example, STAs 1004 and 1006 begin transmitting CTS frames 1010 and 1012 at the SIFS time boundary after receiving the PPDU including MU-RTS trigger frame 1008, respectively. In the example, STA 1004 (or STA 1006) responds to MU-RTS trigger frame 1008 with a CTS frame when the following conditions are met: MU-RTS trigger frame 1008 includes a user information field addressed to the STA (the AID12 subfield of the user information field is equal to 12 LSBs of the STA's AID); MU-RTS trigger frame 1008 is sent by the AP associated with the STA; and the UL MU CS condition indicates that the medium is idle, as described in section 26.5.2.5 (UL MU CS Mechanism) of the IEEE 802.11 standard (“IEEE P802.11-REVme™ / D3.0, April 2023”). Otherwise, if any one of the conditions is not met, STA 1004 (or STA 1006) will not send a CTS frame to AP 1002.

[0111] In the example, STAs 1004 and 1006 can set the RA field of CTS frames 1010 and 1012 respectively to the TA obtained from the TA field of the MU-RTS trigger frame 1008. In the example, STAs 1004 and 1006 can set the duration field of CTS frames 1010 and 1012 respectively based on the duration field of the MU-RTS trigger frame 1008, i.e., set it to be equal to the value of the duration field of the MU-RTS trigger frame 1008, which is adjusted by subtracting the time required to transmit CTS frames 1010 and 1012 respectively and one SIFS period.

[0112] Because it is within the communication range of AP 1002, the OBSS STA visible to AP 1002 may receive MU-RTS trigger frame 1008. In the example, as... Figure 10 As shown, after receiving MU-RTS trigger frame 1008, OBSSSTAs visible to AP 1002 set their respective NAVs based on the duration field of MU-RTS trigger frame 1008. Therefore, during the duration of the TXOP initiated by AP 1002, OBSSSTAs visible to AP 1002 may not access the radio medium.

[0113] Because it is outside the communication range of AP 1002, the OBSS STA hidden from AP 1002 will not receive MU-RTS trigger frame 1008. However, in the example, as Figure 10 As shown, some OBSS STAs hidden from AP 1002 can receive CTS frames 1010 and / or 1012, and can set their respective NAVs based on the duration fields of CTS frames 1010 and / or 1012. Therefore, some OBSS STAs hidden from AP 1002 may not access the radio medium during the duration of a TXOP initiated by AP 1002.

[0114] Upon receiving CTS frame 1010 and / or CTS frame 1012, AP 1002 may wait one SIFS cycle before transmitting DL MU PPDU 1014. Upon receiving DL MU PPDU 1014, STAs 1004 and 1006 can respond by transmitting corresponding block acknowledgment (BA) frames 1016 and 1018 to AP 1002.

[0115] In future IEEE 802.11 standards, it is foreseeable that STAs (AP STAs or non-AP STAs) can operate using multiple primary channels (e.g., they can access non-primary channels to communicate with another STA). This operation can be called Non-Primary Channel Access (NCPA) operation, and such STAs can be called Multi-Primary Channel STAs (MPC STAs) or NPCA STAs. Specifically, in addition to the default primary channel (which is used by all STAs in the BSS, and the AP transmits management frames via this default primary channel), MPC / NPCA STAs can also have channels that are considered as NPCA primary channels. NCPA primary channels can be secondary channels of the BSS. Hereinafter, the default primary channel is referred to as the "primary channel," and the secondary channel that is considered a primary channel is referred to as the NPCA primary channel or anchor channel (or auxiliary primary channel). MPC / NPCA STAs can transmit or receive on channels that include NPCA primary channels but (e.g., when the primary channel is unavailable) do not necessarily include primary channels. MPC / NPCA STAs can maintain NAVs for NPCA primary channels or anchor channels independently of the NAVs associated with the primary channels. A STA (AP STA or non-AP STA) that supports NPCA operations can be called an NPCA STA. An AP (AP STA) that supports NPCA operations can be called an NPCA AP. A non-AP STA that supports NPCA operations can be called a non-AP NPCA STA.

[0116] Figure 11This is example 1100 illustrating MPC / NPCA operation. For illustrative purposes, MPC / NPCA operation is contrasted with single main channel (non-MPC / non-NPCA) operation. Figure 11 As shown, a non-MPC / non-NPCA STA can operate on multiple channels, including a primary channel (PCH), a first secondary channel (SCH1), a second secondary channel (SCH2), and a third secondary channel (SCH2). According to NPCA operation, the same channels can include the primary channel (PCH), the first secondary channel (SCH1), the NPCA primary channel (NPCA PCH), and the second secondary channel (SCH2). It should be noted that the position of the NPCA primary channel may or may not be as specified. Figure 11 As shown in the example. For example, the NPCA primary channel can correspond to SCH1. In the example, the channel corresponding to the second secondary channel (SCH2) of a non-MPC / non-NPCA STA can correspond to the anchor channel (ACH) or NPCAPCH of the MPC / NPCA STA, and the channel corresponding to the third secondary channel (SCH3) of a non-MPC / non-NPCA STA can correspond to the second secondary channel (SCH2) of the MPC / NPCASTA. The primary channel (PCH) and first secondary channel (SCH1) of both non-MPC / non-NPCA STAs and MPC / NPCA STAs correspond to the same channels.

[0117] like Figure 11 As shown, in non-NPCA operation, when the STA has a non-zero NAV for the PCH, the STA can communicate without using any channel of the BSS. The non-zero NAV for the PCH may be due to the STA receiving / detecting an inter-BSS PPDU on the PCH. Alternatively, the STA waits for the NAV for the PCH to reach zero and then contends for the PCH for transmission. In implementations such as... Figure 12 As shown, in non-MPC / non-NPCA STA operation, virtual carrier sense (CS) functions (e.g., NAV) can be associated only with the PCH. Secondary channels can only have their associated physical CS functions (e.g., energy detection), which can be performed only when there is contention for transmissions on the PCH. Therefore, as... Figure 11 As shown, non-MPC / non-NPCA STAs can transmit only on channels that include PCH (e.g., PCH, PCH+SCH1, PCH+SCH1+SCH2, PCH+SCH1+SCH2+SCH3), and only when the NAV associated with the PCH is zero (and the physical CS function indicates "channel idle" for all channels in use).

[0118] In NPCA operation, when a STA detects / receives an inter-BSS PPDU on the PCH, the STA can switch to the NPCA PCH. The STA can set a NAV for the PCH based on the inter-BSS PPDU (e.g., based on the frame duration field, the transmission opportunity (TXOP) duration field, or the length field of the inter-BSS PPDU), and can switch to the NPCA PCH for the duration of the NAV set for the PCH. After switching to the NPCA PCH, the STA can communicate via the NPCA PCH or a channel that includes the NPCA PCH. In implementations such as... Figure 12 As shown, in MPC / NPCA STA operation, virtual CS functions (e.g., NAV) can be associated with multiple channels (e.g., PCH and NPCA PCH). Therefore, as Figure 11 As shown, if the NAV associated with the NPCA PCH is zero (and the physical CS indicates "channel idle" for all channels in use), the MPC / NPCA STA can transmit on channels that do not include the PCH but do include the NPCA PCH (e.g., NPCAPCH, NPCA PCH+SCH1, NPCA PCH+SCH2). In another implementation, if the MPC / NPCASTA detects that the NPCA PCH is idle using the physical CS for at least a moderate synchronization duration, the MPC / NPCA STA can also transmit on channels that do not include the PCH but do include the NPCA PCH (e.g., NPCA PCH, NPCA PCH+SCH1, NPCA PCH+SCH2).

[0119] In its implementation, the MPC / NPCA STA can perform physical and / or virtual CS functions (referred to herein as CS or CCA) on multiple channels (e.g., PCH and NPCA PCH). If the PCH is busy (a non-zero NAV or CCA indicates "channel busy"), and if the NPCA PCH is idle (zero NAV and CCA indicate "channel idle"), the MPC / NPCA STA can use the NPCA PCH for transmission.

[0120] In one implementation, the MPC / NPCA STA can support parallel execution of CS on multiple channels, including the PCH and NPCA PCH. This NPCA STA can be referred to herein as a concurrent CCA MPC STA (this STA can also be referred to as a concurrent CCA non-primary channel access (NPCA) STA or a type 1 STA). Due to its concurrent CCA capability, the concurrent CCA MPC / NPCA STA can perform media synchronization simultaneously on multiple channels (e.g., PCH and NPCA PCH). Media synchronization on a channel (e.g., PCH or NPCA PCH) can be performed by detecting frames including NAV information or by listening to the channel for at least the media synchronization duration and searching for an idle channel throughout the media synchronization duration. In another implementation, the MPC / NPCA STA can support execution of CS on a single channel at a time. This STA can be referred to as a non-concurrent CCA MPC / NPCA STA. In this implementation, the MPC / NPCA STA can perform CS on the PCH by default. The STA can also perform CS on the NPCA PCH after switching from the PCH to the NPCA PCH. Compared to concurrent CCA MPC / NPCA STAs, non-concurrent CCA MPC / NPCA STAs can only synchronize to the NPCA PCH after the PCH is found to be busy. Therefore, a non-concurrent CCA MPC / NPCA STA may need to listen to the channel for at least a moderate synchronization duration (if it does not receive any frames including NAV information) before it can make a transmission.

[0121] Figure 13 This is an example comparing the operations of concurrent CCA MPC / NPCA STA with those of non-concurrent CCA MPC / NPCA STA. For example... Figure 13 As shown, both concurrent CCA MPC / NPCA STAs and non-concurrent MPC / NPCA STAs can operate on multiple channels, including the primary channel (PCH), the first secondary channel (SCH1), the anchor channel (ACH), and the second secondary channel (SCH2). Concurrent CCA MPC / NPCA STAs can perform concurrent CS on both the PCH and ACH. Non-concurrent CCA MPC / NPCA STAs can perform CS only on the PCH.

[0122] Figure 13The example can begin with either a concurrent CCA MPC / NPCA STA or a non-concurrent CCA MPC / NPCA STA operating on the PCH. In the example, the first OBSS transfer can begin on the PCH. Since both the concurrent and non-concurrent CCA MPC / NPCA STAs perform CS on the PCH, they can both detect the first OBSS transfer. In the implementation, upon detecting the first OBSS transfer on the PCH, both the concurrent and non-concurrent CCA MPC / NPCA STAs can be configured to set the NAV associated with the PCH (based on the duration of the first OBSS transfer) and switch to the ACH for the duration of the NAV.

[0123] In the example, a second OBSS transmission can begin on the ACH before or during the first OBSS transmission on the PCH. With concurrent CS capability, the concurrent CCA MPC / NPCA STA can detect the second OBSS transmission before switching to the ACH. In the implementation, the concurrent CCA MPC / NPCA STA can set the NAV associated with the ACH based on the second OBSS transmission. The concurrent CCA MPC / NPCA STA can wait until the end of the second OBSS transmission (and any associated ACK frames) before attempting to access the ACH to transmit data frames. The concurrent CCA MPC / NPCA STA can perform random backoff before transmitting data frames on the ACH. When the NAV associated with the PCH reaches zero, the concurrent CCA MPC / NPCA STA can switch back to the PCH.

[0124] In contrast, a non-concurrent CCA MPC / NPCA STA may not detect a second OBSS transmission before switching to ACH. Therefore, when switching to ACH, the non-concurrent CCA MPC / NPCA STA may be unaware that a second OBSS transmission is being transmitted on ACH. Simultaneously, the non-concurrent CCA MPC / NPCA STA may be unaware of its future access to ACH. In an implementation, the non-concurrent MPC / NPCA STA can be configured to wait at least the media synchronization duration for ACH before attempting to access ACH after switching, unless the STA detects a transmission during the media synchronization duration. In another implementation, after switching to ACH, the non-concurrent MPC / NPCA STA can start a "MediumSyncDelay" timer for the media synchronization duration. In this implementation, the value of the "MediumSyncDelay" timer can be set to the "dot11MSDTimerDuration" value. The STA can initialize the "dot11MSDTimerDuration" to the value of "aPPDUMaxTime" as defined in Table 36-70 (EHT PHY characteristics) of the IEEE 802.11be draft amendment ("Draft P802.11be_D4.1"). The STA can update the "dot11MSDTimerDuration" using the value in the medium synchronization delay information field (if present) of the basic multilink element in the most recent frame received from the STA's associated AP. In the implementation, a non-concurrent MPC / NPCA STA can reset the "MediumSyncDelay" timer to zero when the STA receives an MPDU or when the STA receives a PPDU in which the RXVECTOR parameter "TXOP_DURATION" is not set to "UNSPECIFIED".

[0125] exist Figure 13 In the example, after switching to ACH, the non-concurrent CCA MPC / NPCA STA can detect and receive the ACK frame associated with the second OBSS transmission. Receiving the ACK frame allows the non-concurrent CCA MPC / NPCA STA to reset the "MediumSyncDelay" timer to zero and acquire media synchronization on ACH. The non-concurrent CCA MPC / NPCA STA can wait for the ACK frame to end before performing random backoff to transmit data frames on ACH. When the NAV associated with PCH reaches zero, the non-concurrent CCA MPC / NPCA STA can switch back to PCH.

[0126] Figure 14This is another example comparing the operations of concurrent CCA MPC / NPCA STA with those of non-concurrent CCA MPC / NPCA STA. For example, in Figure 13 As in the example, both concurrent CCA MPC / NPCA STAs and non-concurrent MPC / NPCA STAs can operate on multiple channels, including the primary channel (PCH), the first secondary channel (SCH1), the anchor channel (ACH), and the second secondary channel (SCH2). Concurrent CCA MPC / NPCA STAs can perform concurrent CS on both the PCH and ACH. Non-concurrent CCA MPC / NPCA STAs can perform CS only on the PCH.

[0127] Figure 14 The example can begin with either a concurrent CCA MPC / NPCA STA or a non-concurrent CCA MPC / NPCA STA operating on the PCH. In the example, the first OBSS transfer can begin on the PCH. Since both the concurrent and non-concurrent CCA MPC / NPCA STAs perform CS on the PCH, they can both detect the first OBSS transfer. In the implementation, upon detecting the first OBSS transfer on the PCH, both the concurrent and non-concurrent CCA MPC / NPCA STAs can be configured to set the NAV associated with the PCH (based on the duration of the first OBSS transfer) and switch to the ACH for the duration of the NAV.

[0128] In the example, when a concurrent CCA MPC / NPCA STA or a non-concurrent CCA MPC / NPCA STA switches to ACH, the ACH may be idle. With concurrent CS capability, the concurrent CCA MPC / NPCA STA can know that the ACH is idle when it switches. Therefore, the concurrent CCA MPC / NPCA STA can attempt to access the ACH immediately after switching. Figure 14 As shown, concurrent CCA can perform random backoff before transmitting data frames on the ACH. When the NAV associated with the PCH reaches zero, the concurrent CCA MPC / NPCA STA can switch back to the PCH.

[0129] In contrast, when switching to ACH, a non-concurrent CCA MPC / NPCA STA may not be aware whether ACH is idle or busy. In an implementation, a non-concurrent MPC / NPCA STA can be configured to wait for at least the media synchronization duration required for ACH before attempting to access ACH after switching, unless the STA detects a transmission during the media synchronization duration. In another implementation, after switching to ACH, the non-concurrent MPC / NPCA STA can start a "MediumSyncDelay" timer for the media synchronization duration. In this implementation, the value of the "MediumSyncDelay" timer can be set to the "dot11MSDTimerDuration" value. The STA can initialize the "dot11MSDTimerDuration" to the "aPPDUMaxTime" value defined in Table 36-70 (EHT PHY characteristics) of the IEEE 802.11be draft amendment ("Draft P802.11be_D4.1"). The STA can update the "dot11MSDTimerDuration" using the value (if present) in the medium synchronization delay information field of the basic multilink element contained in the most recent frame received from the STA's associated AP. In the implementation, a non-concurrent MPC / NPCA STA can reset the "MediumSyncDelay" timer to zero when the STA receives an MPDU or when the STA receives a PPDU in which the RXVECTOR parameter "TXOP_DURATION" is not set to "UNSPECIFIED".

[0130] exist Figure 14 In the example, the non-concurrent CCA MPC / NPCA STA may not detect or receive any frames during the medium synchronization duration. Therefore, the non-concurrent CCA MPC / NPCA STA may not reset the "MediumSyncDelay" timer to zero. The non-concurrent CCA MPC / NPCA STA may only acquire medium synchronization on the ACH after the entire medium synchronization duration has elapsed. Therefore, the non-concurrent CCA MPC / NPCA STA may have to wait for the entire medium synchronization duration before attempting to access the ACH, even though the ACH is actually idle and available during the medium synchronization duration. Therefore, buffered data at the non-concurrent CCA MPC / NPCA STA may be unnecessarily delayed, and the ACH may therefore be underutilized.

[0131] As described herein, the AP can transmit a first frame that includes a media synchronization duration for a first channel. The first channel can be an anchor channel or a secondary master channel. When the media synchronization duration for the first channel begins, the AP can transmit a second frame via the first channel. The media synchronization duration for the first channel can begin when the AP receives a third frame indicating transmission on the second channel. The transmission can be an OBSS transmission. This transmission allows the AP to switch from the second channel to the first channel. The second channel can be the AP's master channel. The second frame can be transmitted during the media synchronization duration for the first channel. The second frame allows non-concurrent CCA MPC / NPCA STAs to acquire media synchronization on the first channel without waiting for the entire media synchronization duration for the first channel.

[0132] Figure 15 Example programs that can be executed by the AP in some cases are shown. For illustration, Figure 15 The behavior of the STA in response to an example AP procedure is also shown, which can be associated with the AP. The AP can operate on multiple channels, including the primary channel (PCH) and the anchor channel (ACH). In the example, the AP can further operate on a first secondary channel (SCH1) and a second secondary channel (SCH2). The AP can perform concurrent CS on both the PCH and ACH. The AP can support an anchor / secondary primary channel medium synchronization auxiliary mode, which allows the AP to perform... Figure 15 The program.

[0133] like Figure 15 As shown, the example procedure can begin with the AP operating on the PCH. In the example, the AP can transmit frame 1502 on the PCH. Frame 1502 can be a management frame, such as a beacon frame. In some cases, frame 1502 can indicate both the PCH and ACH. In some cases, frame 1502 can include or indicate the duration of media synchronization for the ACH. In some cases, frame 1502 can include an indication that the AP supports the anchor / secondary primary channel media synchronization auxiliary mode. In some cases, frame 1502 can also include an indication that the AP activates / deactivates the anchor / secondary primary channel media synchronization auxiliary mode. The STA associated with the AP can operate on the same channel as the AP. Therefore, the STA can receive frame 1502 via the PCH.

[0134] In the example, when the AP operates on the PCH, the transmission of frame 1504 from the OBSS can begin on the PCH. The AP can detect frame 1504 on the PCH. In an implementation, the AP can be configured to set the NAV associated with the PCH based on the receipt of frame 1504 on the PCH. Frame 1504 can indicate a transmission on the PCH. The duration of the transmission on the PCH can be provided by the duration field of frame 1504, the transmission opportunity (TXOP) duration field of the PPDU including frame 1504, or the length field of the PPDU. In an implementation, the AP can be configured to switch to the ACH within the NAV duration. In the example case, after switching to the ACH, the AP can start a "MediumSyncDelay" timer for the medium synchronization duration of the ACH. The "MediumSyncDelay" timer can be set based on the medium synchronization duration indicated in frame 1504 for the ACH.

[0135] In some cases, after switching to ACH, the AP can be configured to transmit frame 1506 on the ACH for the duration of the media synchronization used for ACH. In this implementation, the AP can be capable of concurrent CS on both PCH and ACH. Therefore, as... Figure 15 As shown, the AP can (after performing random backoff) transmit frame 1506 on the ACH without waiting for the medium synchronization duration for the ACH to expire. Frame 1506 can be any frame, including CTS frames, contention-free (CF) end frames, trigger frames, QoS data / empty frames, or empty data packet (NDP) frames.

[0136] In one implementation, the AP can determine the CCA state of the ACH before transmitting frame 1506. In another implementation, the AP can transmit frame 1506 while the ACH CCA state is idle. In yet another implementation, before the AP receives frame 1504 on the PCH, the AP can transmit frame 1506 while the ACH CCA state is idle for a first duration. In this implementation, an idle ACH CCA state includes a received power measured by the AP on the ACH during the first duration being less than a threshold. For example, the first duration can be one of 5.484 milliseconds, 25 microseconds, or 16 microseconds. For example, the threshold can be one of -62 dBm, -72 dBm, or -82 dBm. In some cases, an idle ACH CCA state includes a NAV associated with the ACH being zero.

[0137] In some cases, the AP can transmit frame 1506 on the ACH with the backoff count associated with the ACH being zero. The AP can initialize the backoff count to a random number. The AP can initialize the backoff count after: the end of the PPDU carrying frame 1504 on the PCH; an indication of a successful preamble detection; or an indication of a successful MPDU detection on the PCH.

[0138] The STA associated with the AP can also detect and receive frame 1504 on the PCH. Similar to the AP, the STA can be configured to set the NAV associated with the PCH based on the receipt of frame 1504 on the PCH. In some implementations, the STA can also be configured to switch to ACH together with the AP for the duration of the NAV. In other implementations, the STA can be configured to switch to ACH when the STA is an MPC / NPCASTA. In some cases, after switching to ACH, the STA can start a "MediumSyncDelay" timer for the media synchronization duration of ACH. The "MediumSyncDelay" timer can be set based on the media synchronization duration for ACH indicated in frame 1502.

[0139] In the example, such as Figure 15 As shown, the STA can be a non-concurrent CCA MPC / NPCA STA. When switching to ACH, the STA may not be aware that a transmission is already taking place on the ACH. The STA can be configured to wait for the "MediumSyncDelay" timer to expire before attempting to access the ACH. However, the AP's transmission of frame 1506 allows the non-concurrent CCA MPC / NPCA STA to acquire media synchronization on the ACH. Specifically, upon receiving frame 1506, the STA can reset the "MediumSyncDelay" timer to zero. After performing random backoff, the STA can then proceed to access the ACH to transmit frame 1508 on the ACH. For example, frame 1508 could be a QoS data / empty frame. In the example, frame 1508 could respond to frame 1506. For example, frame 1506 could be a trigger frame that triggers the STA to transmit frame 1508.

[0140] In some cases, the STA can transmit frame 1508 on the ACH with the backoff count associated with the ACH being zero. The STA can initialize the backoff count to a random number. The STA can initialize the backoff count after: the end of the PPDU carrying frame 1504 on the PCH; an indication of a successful preamble detection; or an indication of a successful MPDU detection on the PCH.

[0141] In another example, the STA can be a concurrent CCA MPC / NPCA STA. The STA can perform concurrent CS on both the PCH and ACH. In this implementation, the STA can determine the CCA state of the ACH. The CCA state can include both physical CS state and virtual CS state. The CCA state can be considered idle when both the physical and virtual CS states indicate that the channel is idle. In some cases, the STA can transmit frame 1506 while the ACH's CCA state is idle (e.g., with or in place of the AP). In this implementation, the STA can transmit frame 1506 while the AP is activating the anchor / auxiliary operation channel medium synchronization auxiliary mode. In this implementation, the STA can transmit frame 1506 while the ACH's CCA state is idle for a first duration before receiving frame 1504 on the PCH. In this implementation, the ACH's CCA state being idle includes the received power measured by the STA on the ACH during the first duration being less than a threshold. For example, the first duration can be one of 5.484 milliseconds, 25 microseconds, or 16 microseconds. For example, the threshold can be one of -62 dBm, -72 dBm, or -82 dBm. In some cases, the CCA state of the ACH is idle, including a NAV associated with the ACH that is equal to zero.

[0142] In some cases, the STA can transmit frame 1506 on the ACH with the backoff count associated with the ACH being zero. The STA can initialize the backoff count to a random number. The STA can initialize the backoff count after: the end of the PPDU carrying frame 1504 on the PCH; an indication of a successful preamble detection; or an indication of a successful MPDU detection on the PCH.

[0143] In some cases, the STA and AP transmit frame 1506 simultaneously. In this example, frame 1506 can be a specific frame type known to both the AP and the STA. In some cases, the backoff count associated with the ACH can be initialized to a value known to both the AP and the STA (e.g., 0).

[0144] Figure 16Example program 1600 is shown, illustrating problems that may arise in some situations due to the operation of MPC / NPCA STAs and non-MPC / non-NPCA STAs. Program 1600 depicts the operation of STAs (e.g., MPC / NPCA STA 1610 and non-MPC / non-NPCA STA 1620) in a wireless network and the interactions between these STAs. As shown, MPC / NPCA STA 1610 can operate on multiple channels, including a primary channel (PCH) and a secondary channel (SCH), while the non-MPC / non-NPCA STA 1620, which does not have multiple primary channel capabilities, operates only on the PCH and is thus shown. As described herein, the SCH can also be referred to as the secondary channel. By way of example and not limitation, the PCH may correspond to a 20 MHz primary channel, and the SCH may correspond to a 20 MHz secondary channel.

[0145] Regarding MPC / NPCA STA 1610, as mentioned above... Figures 10 to 11 As discussed herein, it is foreseeable that in some cases, future IEEE 802.11 standards will enable STAs to operate using multiple primary channels (e.g., operational channels). Given the description herein, it will be apparent to those skilled in the art that providing STAs with the ability to switch between multiple primary channels can provide benefits in some situations, including but not limited to improving STA performance by providing the ability to switch to a second channel to avoid traffic detected on the first channel.

[0146] In some methods used to implement MPC / NPCA STA, when a certain type of communication (e.g., a frame) is detected on the current operating channel, MPC / NPCA STA can immediately switch to a secondary channel. For example, as... Figure 16 As described, when CS is performed on PCH, MPC / NPCA STA 1610 can detect OBSSPPDU 1615 relative to the BSS of MPC / NPCA STA 1610. Therefore, MPC / NPCA STA 1610 is described at handover 1670 as immediately switching the operating channel from PCH to SCH.

[0147] For the purposes of this example, OBSS PPDU 1615 corresponds to frames of the Request to Send (RTS) or Multi-User RTS (MU-RTS) type, but this example is non-limiting and other types of frames may have similar processing performed by the implementation scheme.

[0148] In addition to the operation of MPC / NPCA STA 1610, for illustrative purposes, the operation of non-MPC / non-NPCA STA 1620 is also described as detecting OBSS PPDU 1615 via carrier sensing. In this example, since the non-MPC / non-NPCA STA 1620 is not an MPC / NPCA STA, it still uses PCH as its operating channel when OBSS PPDU 1615 is detected. The non-MPC / non-NPCA STA 1610 can set its NAV based on the detection of OBSS PPDU 1615. Furthermore, the non-MPC / non-NPCA STA 1610 can start a timer corresponding to the NAVTimeout period 1655. NAVTimeout 1655 can be equal to the NAV timeout defined in the IEEE 802.11 standard.

[0149] As noted above, in this example, OBSS PPDU 1615 corresponds to an RTS or MU-RTS frame, and as another element of this example, it is assumed that after detecting OBSS PPDU 1615, the non-MPC / non-NPCA STA 1620 does not detect a transmit-allowed (CTS) frame within NAVTimeout 1655. As mentioned above, according to the IEEE 802.11 standard, because OBSS PPDU 1615 is an RTS or MU-RTS frame and no CTS frame is detected within NAVTimeout 1665, the non-MPC / non-NPCA STA 1620 can reset its NAV set based on OBSS PPDU 1615.

[0150] Continuing this example operation of the non-MPC / non-NPCA STA 1620 relative to the MPC / NPCA STA 1610 and the PCH and SCH channels, a NAV reset 1660 can be performed based on the expiration of NAVTimeout 1665, and in this example, after the backoff time 1699, the non-MPC / non-NPCA STA 1620 can transmit data frame 1635 to the MPC / NPCA STA 1610. In some implementations, this data frame 1635 may correspond to an RTS frame used to transmit additional data.

[0151] In an example illustrating a potential problem that may arise under the circumstances described above, as depicted in the timeline of MPC / NPCA STA 1610 and non-MPC / non-NPCA STA 1620, because the transmission of data frame 1635 occurs while MPC / NPCA STA 1610 is operating on the SCH, MPC / NPCA STA 1610 may be unable to receive data frame 1635, resulting in a reception failure 1637 for the transmission of data frame 1635. In some cases, this failure may lead to a degradation in network performance for non-MPC / non-NPCA STAs associated with the MPC / NPCA STA.

[0152] As described below, the embodiments of this disclosure address one or more of the problems described above. References are provided below. Figure 17 In one example, the method corresponding to the implementation may include receiving a first frame from a second STA and via a first channel by a first STA, the first frame including an indication of the frame type of the first frame. In this example, the first STA may correspond to an MPC / NPCA STA 1710, which may receive (e.g., detect) a first frame corresponding to an RTS type frame (e.g., a type of OBSS PPDU 1704).

[0153] In the implementation scheme, the method may further include switching the operating channel of the first STA from the first channel to the second channel based on the frame type after receiving the first frame. For example, as described below... Figure 17 As described, the detection of RTS frame type frames by the MPC / NPCA STA 1710 can, in some cases, introduce a handover delay for the MPC / NPCA STA 1710. In an implementation, this handover delay allows the MPC / NPCA STA 1710 to avoid switching to SCH (e.g., handover 1670), and this allows the MPC / NPCA STA 1710 to detect data 1715 and avoid problems associated with reception failures (e.g., reception failure 1637). The following section discusses… Figures 17 to 21 Additional details are discussed regarding different methods for implementing handover delay, second frame, and additional operations for non-MPC / non-NPCA STA.

[0154] Figure 17 Example program 1700 is shown, which can be executed by an implementation scheme, for example, to mitigate one or more of the problems described above that may arise in some cases due to the operation of MPC / NPCA STAs and non-MPC / non-NPCA STAs. For example, as Figure 17As described, by performing CS on the PCH, the OBSS PPDU 1704 of the BSS relative to the MPC / NPCA STA1710 and non-MPC / non-NPCA STA 1720 can be detected.

[0155] exist Figure 16 In the example, because MPC / NPCA STA 1610 did not switch back to PCH, network performance may be negatively affected based on receive failure 1637, which occurs in some cases. As further described below, embodiments of this disclosure address one or more of the problems described above. In general, one or more embodiments can improve the likelihood that an MPC / NPCA STA (e.g., after receiving an OBSS PPDU frame on the PCH) can receive data from a non-MPC / non-NPCASTA with NAV reset. In the method that can be used by the embodiments, the MPC / NPCAAP (and generally the MPC / NPCA STA) can wait for a selected timeout period before switching from PCH to SCH.

[0156] During MPC / NPCA STA 1710 handover, methods for regulating the MPC / NPCA STA handover include determining the duration of timeout 1755. Timeout 1755 may correspond to the minimum duration for which MPC / NPCA STA 1710 can continue operating on the PCH after receiving OBSS PPDU 1704. As discussed herein, the value of timeout 1755 can be determined in different ways, but this determination generally includes determining whether the NAV on the PCH can be reset after receiving OBSS PPDU 1704. For example, based on the detected frame having OBSS PPDU 1704 type (e.g., RTS or MU-RTS), the PCH NAV can be determined to be reset at the end of NAVTimeout 1765.

[0157] In the illustrated example, given that a non-MPC / non-NPCA STA 1720 detects OBSS PPDU 1704, NAVTimeout 1765 can be selected to adjust the non-MPC / non-NPCA STA 1720's use of the PCH for communication. NAVTimeout 1765 can be determined in different ways, but this determination generally involves estimating when the PCH will no longer contain signals associated with the communication detected on the PCH (e.g., OBSS PPDU 1704) and will therefore be usable by the non-MPC / non-NPCA STA 1620 (e.g., by resetting the NAV set by OBSS PPDU 1704).

[0158] In the implementation, the MPC / NPCA STA 1710 can be configured to continue operating on the PCH for at least a timeout of 1755 after receiving OBSS PPDU 1704, before switching to the SCH, instead of immediately switching to the SCH upon detecting OBSS PPDU 1704 on the PCH. In this implementation, the duration of timeout 1755 can be set to be equal to or greater than the duration of the NAV timeout defined in the IEEE 802.11 standard. This ensures that the MPC / NPCA STA 1710 continues operating on the PCH after receiving OBSS PPDU 1704. In the example, timeout 1755 can be set to correspond to a PCH NAV set based on OBSS PPDU 1704 (e.g., NAV Timeout 1765), and the PCH NAV can be reset according to the IEEE 802.11 standard. For example, according to the IEEE 802.11 standard, if no PHY-RXEARLYSIG.indication or PHYRXSTART.indication primitive is received from the PHY during the NAV timeout period, the STA that uses information from the RTS frame or MU-RTS trigger frame as the most recent basis for updating the STA's NAV setting is permitted to reset its NAV. This NAV timeout period begins when the MAC receives the PHY-RXEND.indication primitive corresponding to the detected RTS frame or MU-RTS trigger frame. That is, if the STA does not receive any frames during the NAV timeout interval from the time the STA set its NAV, the STA can reset its NAV based on the RTS or MU-RTS trigger frame setting. Therefore, the NAV timeout can be used as a value for timeout 1755, for example, to set a time limit for evaluating whether to switch the operating channel of the MPC / NPCA STA 1710 to the SCH. In different implementations, the timeout value of 1755 can correspond to the following time associated with the PCH event: (2×aSIFSTime)+(CTS_Time)+aPHY-RX-START-Delay+(2×aSlotTime), where CTS_Time includes the duration of the PPDU carrying the CTS frame.

[0159] In an implementation, the method used may include receiving a first frame from a second STA via a first channel by a first STA, the first frame including an indication of the frame type of the first frame. In an implementation, the first STA may switch its operating channel based on the frame type. For example, as depicted in example procedure 1700, after MPC / NPCA STA 1710 receives OBSSPPDU 1704, and based on the frame type of OBSS PPDU 1704 being a specific type (e.g., RTS frame type or MU-RTS frame type), MPC / NPCA STA 1710 may switch its operating channel from PCH (or delay switch) to SCH. One method that may be used by an implementation to determine when (or whether) MPC / NPCA STA 1710 switches to SCH utilizes a timeout period determined by the implementation, such as timeout 1755 described below.

[0160] For example, because in this implementation, the MPC / NPCA STA 1710 can maintain the PCH as the operating channel for at least the specified timeout after receiving the OBSS PPDU 1704, the MPC / NPCA STA 1710 can detect that a frame that was originally expected to be received after the OBSS PPDU 1704 has not been received. For example, if the OBSS PPDU 1704 is an RTS frame or a MU-RTS frame, the MPC / NPCA STA 1710 can detect that a frame that was originally expected to be received after the RTS frame or MU-RTS frame has not been received.

[0161] In the implementation, since the MPC / NPCA STA 1710 maintains the PCH as its operating channel, it can receive information from the PCH and use this information to determine whether the MPC / NPCA STA 1710 switches to the SCH after receiving the OBSS PPDU 1704.

[0162] In the implementation, the MPC / NPCA STA 1710 can select a timeout of 1755 based on the originally expected time for detecting a CTS on the PCH, and when the timeout of 1755 expires and the MPC / NPCA STA 1710 has not received any subsequent transmissions on the PCH, the MPC / NPCA operation can be suspended at 1790. In the depicted example, because the MPC / NPCA STA 1710 did not detect any subsequent frames during the determined timeout of 1755, the MPC / NPCA operation can be suspended at 1790, and the MPC / NPCA STA 1710 does not continue monitoring the PCH in order to switch to an auxiliary channel, such as the SCH. As depicted on the timeline, for example, as described above regarding... Figure 16Compared to the return 1675 to PCH described for MPC / NPCA STA 1610, this handover absence in MPC / NPCA STA 1710 could beneficially facilitate the reception of data 1715 from non-MPC / non-NPCA STA 1720.

[0163] Figure 18 Example program 1800, which can be executed by the MPC / NPCA component according to the implementation scheme, is shown. (See above regarding...) Figure 17 As the examples illustrate, in some cases, one or more implementations can advantageously delay the MPC / NPCA STA handover to the secondary channel. (See the examples above regarding...) Figure 17 In the described example program 1700, because the MPC / NPCA STA 1710 does not detect a specific frame type (e.g., an OBSS CTS frame following OBSS PPDU 1704), the MPC / NPCA STA 1710 does not switch to SCH after detecting OBSS PPDU 1704.

[0164] In example program 1800, OBSS CTS 1805 is detected during the timeout period 1855, during which the MPC / NPCA STA 1810A can determine whether a frame following OBSS PPDU 1804 has been received. According to one or more embodiments, detecting OBSS CTS 1805 during the timeout period 1855 can cause the MPC / NPCA STA 1810A to switch to SCH 1860. Figure 18 As described, this switch can be based on the end of the OBSS CTS 1805 frame (e.g., the end of the PPDU carrying the OBSS CTS 1805 frame). Figure 18 In an alternative implementation not shown, for example, after receiving PHY-RXSTART.indication, the switching point 1860 from MPC / NPCA STA 1810A to SCH can be the end of the preamble of a PPDU carrying an OBSS CTS 1805 frame.

[0165] As depicted, in this example, based on the switch to the SCH, the MPC / NPCA STA 1810A can transmit frame 1807 via the SCH. Figure 18 In additional or alternative implementations not depicted herein, the MPC / NPCA STA 1810A may perform a media synchronization procedure on the SCH or receive an indication that a media synchronization procedure has been performed on the SCH before using the SCH to transmit frame 1807.

[0166] Continuing the discussion of example procedure 1800, during timeout 1865, the MPC / NPCA STA 1810B can determine whether the next frame has been received. As depicted, in this example, OBSS CTS 1805 was not detected. In additional or alternative implementations, it is not the OBSS CTS 1805 frame that causes the MPC / NPCA STA 1810B to switch, but rather the detection of the OBSS data 1806 frame, that causes the MPC / NPCA STA 1810B to switch to SCH. In a variant of this method using the detection of OBSS data frame 1806, the implementation can be configured to switch from PCH to SCH based on events, including but not limited to the end of the PPDU carrying OBSS data frame 1806, the end of the preamble of the PPDU carrying OBSS data frame 1806 (e.g., PHY-RXSTART.indication), the end of the orthogonal frequency division multiplexing (OFDM) symbol of the first MPDU carrying OBSS data frame 1806, and / or other events related to the handover determination described herein.

[0167] Figure 19 An example program 1900 is shown, illustrating the interaction between MPC / NPCA components in a coordinateable wireless network according to an implementation scheme. As described above, in the implementation of the MPC / NPCA components, the MPC / NPCA components can switch from the PCH to the SCH based on the detection of certain OBSS communications on the PCH.

[0168] For example, such as Figure 19 As described above, upon detecting OBSS PPDU 1906, MPC / NPCA STA 1910 can switch from 1960 to PCH. (This is in accordance with the above discussion.) Figure 19 As described in the implementation, upon detection of OBSS PPDU 1906, the MPC / NPCA AP STA 1910 can delay switching to the PCH until the conditions described above, such as CTS communication following the detection of OBSS PPDU 1906. The following examples of communication include... Figure 18 The OBSS data 1806 and OBSS CTS 1805 described above are as follows: Figure 18 The discussion.

[0169] In the implementation scheme, based on the detection of OBSS PPDU 1906, MPC / NPCA STA 1920 can switch to SCH at 1972, and MPC / NPCA AP STA 1910 can begin a timeout at 1955. Referring to media channel synchronization, MPC / NPCA STA 1920 can wait until 1980 for MPC / NPCA AP STA 1910 to transmit a frame on SCH, enabling MPC / NPCA STA 1920 to achieve media synchronization on SCH. In the implementation scheme, to facilitate access to SCH for MPC / NPCA STA 1920 and other devices, once MPC / NPCA AP 1921 has detected OBSS data 1908 and switched to SCH at 1960, a trigger frame (TF) 1970 can be transmitted on SCH to provide SCH media synchronization to MPC / NPCA STA 1920 and other devices, for example, as detected by MPC / NPCA STA 1920. In an alternative implementation, in order to provide synchronization assistance to the associated STA used for SCH, the MPC / NPCA AP STA 1910 may transmit DL frames (not shown) on SCH, for example, to be detected by the MPC / NPCA STA 1920, instead of using the transmission of TF 1970 to indicate synchronization.

[0170] Based on the indication of media synchronization, before returning to the PCH from 1975, for example after the NAV in the PCH expires, the MPC / NPCA STA 1920 can respond to the TF 1970 using a trigger-based Physical Protocol Data Unit 1912 (TB PPDU), as described above. Figures 13 to 15 The determination of NAV for non-AP stations is described in the discussion. Additionally, as depicted, after the timeout period expires, MPC / NPCA AP STA 1910 can return to PCH 1976.

[0171] Figure 20 An additional example program 2000 is shown, illustrating the interaction between MPC / NPCA components in a coordinateable wireless network according to an implementation scheme. In the implementation of the MPC / NPCA components, the MPC / NPCA components can switch from the PCH to the SCH based on the detection of certain OBSS communication on the PCH.

[0172] For example, such as Figure 20 As described above, upon detecting OBSS PPDU 2006, the MPC / NPCA STA 2010 can switch 2072 to PCH. (This is in accordance with the above discussion.) Figure 20As described in the implementation, upon detection of OBSS PPDU 2006, the MPC / NPCA STA 2010 may delay switching to the PCH until the conditions described above, such as communication after the detection of OBSS PPDU 2006.

[0173] In the implementation scheme, after MPC / NPCA STA 2010 detects OBSS data 2008 before timeout 2055 expires, MPC / NPCA STA 2010 can switch to SCH. In this example, data 2075 can be transmitted by MPC / NPCA STA 2010 on SCH to indicate synchronization, instead of transmitting TF 1970 to indicate channel synchronization to MPC / NPCA STA 2020.

[0174] Figure 21 An additional example program 2100 is shown illustrating the interaction between MPC / NPCA components in a coordinateable wireless network according to an implementation scheme. In the implementation of the MPC / NPCA components, the MPC / NPCA components can switch from the PCH to the SCH based on the detection of certain OBSS communication on the PCH.

[0175] like Figure 21 As depicted, because timeout 2165 expires before receiving the next frame, the NAV of MPC / NPCA AP 2110 can be reset, and the MPC / NPCA operation of MPC / NPCA AP 2110 can be suspended. In this example implementation, MPC / NPCA STA 2120 switches to PCH 2170 upon detecting OBSS PPDU 2106, but because MPC / NPCA AP 2110 does not switch to SCH, no synchronization TF 1970 is transmitted on SCH. Without an indication of synchronization, MPC / NPCA STA 2120 can perform an earlier return to PCH 2190 after AP wait timeout 2185 expires. Generally, in implementations, as depicted, the earlier return time 2190 can be selected after MPC / NPCA 2110 timeout 2165 and before return to PCH 2180. For example, in an implementation, the AP wait timeout 2185 may include an MPC / NPCA AP 2110 timeout 2165 plus the time that MPC / NPCA AP 2110 may spend switching from PCH to SCH and transmitting frames, plus the duration of any other timing parameter (e.g., aRxPHYStartDelay).

[0176] Figure 22An example process 2200 according to an implementation scheme is shown. Example process 2200 can be executed by a first STA, such as an MPC / NPCA STA, as described in the above reference. Figures 16 to 21 The MPC / NPCA STA is described. The MPC / NPCASTA can operate on multiple channels, including a first channel and a second channel, for example, a primary channel and a secondary (auxiliary) channel, as referenced above. Figures 16 to 21 As described.

[0177] like Figure 22 As shown, process 2200 may include steps 2202 and 2204. At step 2202, the depicted process may include a first station (STA) receiving a first frame from a second STA and via a first channel, the first frame including an indication of its frame type. In an embodiment, the first STA or the second STA may include an ultra-reliable STA. In an embodiment, the frame type of the first frame may include a request-to-transmit (RTS) frame or a multi-user request-to-transmit (MU-RTS) frame. At step 2204, the depicted process may further include switching the operating channel of the first STA from the first channel to the second channel based on the frame type after receiving the first frame.

[0178] In one embodiment, process 2200 may further include transmitting a second frame by a first STA and via a second channel at a transmission start time based on the indicated indication. In another embodiment, the indication may include a first duration, wherein the transmission start time is based on transmitting the second frame before the end of the first duration. In yet another embodiment, the first duration may include a transmission opportunity (TXOP) duration.

[0179] In this implementation, the transmission start time may be based on a timeout period that begins after the first frame is received. In this implementation, the timeout period may include a NAVTimeout period. In this implementation, the handover may occur after the timeout period, or alternatively, the handover may occur during the timeout period.

[0180] In one implementation, process 2200 may further include detecting a third frame via a first channel, wherein after receiving the third frame, the transport channel is switched to a second channel. In another implementation, the switching to the second channel may be based on receiving the third frame. Alternatively, the switching may be based on receiving the third frame during a timeout period. In yet another implementation, the third frame includes a Physical Layer Protocol Data Unit (PPDU), and the switching of the transport channel may occur after the end of the PPDU's preamble portion, the end of PPDU transmission, or the end of the PPDU's Orthogonal Frequency Division Multiplexing (OFDM) symbol.

[0181] In additional or alternative implementations, the frame type of the third frame can be one of the following: a data frame, a management frame, a transmit-allow (CTS) frame, a block acknowledgment request (BAR) frame, and a null data packet (NDP) announcement frame. In implementations, the first channel can correspond to a physical channel of the physical layer (PHY) associated with the first channel, and receiving the third frame can include receiving a PHY-RXEARLYSIG indication primitive or a PHYRXSTART indication primitive via the physical channel during a timeout period.

[0182] In additional or alternative embodiments, the first STA may include a multichannel access point (MPC / NPCA AP) STA, the first channel may include a primary channel, and the second channel may include a secondary channel. In embodiments, process 2200 may further include detecting communication via the primary channel from a non-MPC / non-NPCA non-AP station after receiving the first frame and before switching to the secondary channel. In embodiments, the second STA may include an MPC / NPCA non-AP STA that switches to the secondary channel when the first frame is received concurrently with the MPC / NPCA AP STA, and the second frame may include an indication frame indicating to the MPC / NPCA non-AP STA that the secondary channel is available for communication with the MPC / NPCA AP STA. In embodiments, the indication frame includes a downlink (DL) frame. In embodiments, the indication frame may indicate to the MPC / NPCA non-AP STA that the MPC / NPCA AP STA has performed media channel synchronization on the secondary channel. In embodiments, the indication frame may include a trigger frame.

[0183] In additional or alternative embodiments, the first STA may include an MPC / NPCA non-AP STA, and the second STA may include an MPC / NPCA AP station, the first channel includes a primary channel, and the second channel may include a secondary channel. In embodiments, process 2200 may further include switching to the secondary channel based on this indication and upon concurrent reception of the first frame with the MPC / NPCA AP station. In embodiments, process 2200 may further include receiving an indication frame via the secondary channel, wherein the transmission of the second frame is based on a trigger frame. In embodiments, the indication frame may have been transmitted by the MPC / NPCA AP station and indicates to the MPC / NPCA non-AP station that the secondary channel is available for communication. In embodiments, the indication frame indicates that the MPC / NPCA AP STA has performed media channel synchronization on the secondary channel. In embodiments, the indication frame may include at least one of the following: a management frame, a transmit-allow (CTS) frame, a block acknowledgment request (BAR) frame, and a null data packet (NDP) advertisement frame.

[0184] Figure 23An example process 2300 according to an implementation scheme is shown. Example process 2300 can be executed by a first STA, such as an MPC / NPCA STA, as described in the above reference. Figures 16 to 21 The MPC / NPCA STA is described. The MPC / NPCASTA can operate on multiple channels, including a first channel and a second channel, for example, a primary channel and a secondary (auxiliary) channel, as referenced above. Figures 16 to 21 As described.

[0185] like Figure 23 As shown, process 2300 may include steps 2302, 2304, and 2306. At step 2302, the depicted process may include a first station (STA) receiving a first frame from a second STA via a primary channel, the first frame including an indication of the frame type of the first frame and an indication of the duration of transmission following the first frame. At step 2304, the depicted process step 2300 may further include, after receiving the first frame, switching the operating channel of the first STA from the primary channel to a secondary channel based on the frame type, and transmitting a second frame by the first STA via the secondary channel at a transmission start time based on the indication. At step 2306, the depicted process 2300 may further include switching from the secondary channel to the primary channel after the duration.

[0186] In one implementation, the indication may include a first duration, wherein the transmission start time is based on transmitting a second frame before the end of the first duration. In another implementation, the first duration may include a transmission opportunity (TXOP) duration.

[0187] In this implementation, the transmission start time may be based on a timeout period that begins after the first frame is received. In this implementation, the timeout period may include a NAVTimeout period. In this implementation, the handover may occur after the timeout period, or alternatively, the handover may occur during the timeout period.

[0188] In one implementation, process 2300 may further include detecting a third frame via a first channel, wherein after receiving the third frame, the transport channel is switched to a second channel. In another implementation, the switching to the second channel may be based on receiving the third frame. Alternatively, the switching may be based on receiving the third frame during a timeout period. In yet another implementation, the third frame includes a Physical Layer Protocol Data Unit (PPDU), and the switching of the transport channel may occur after the end of the PPDU's preamble portion, the end of PPDU transmission, or the end of the PPDU's Orthogonal Frequency Division Multiplexing (OFDM) symbol.

[0189] In additional or alternative implementations, the frame type of the third frame can be one of the following: a data frame, a management frame, a transmit-allow (CTS) frame, a block acknowledgment request (BAR) frame, and a null data packet (NDP) announcement frame. In implementations, the first channel can correspond to a physical channel of the physical layer (PHY) associated with the first channel, and receiving the third frame can include receiving a PHY-RXEARLYSIG indication primitive or a PHYRXSTART indication primitive via the physical channel during a timeout period.

[0190] In additional or alternative embodiments, the first STA may include a multichannel access point (MPC / NPCA AP) STA, and the second channel may include a secondary channel. In embodiments, process 2300 may further include detecting communication via the primary channel from a non-MPC / non-NPCA non-AP station after receiving the first frame and before switching to the secondary channel. In embodiments, the second STA may include an MPC / NPCA non-AP STA that switches to the secondary channel when the first frame is received concurrently with the MPC / NPCA AP STA, and the second frame may include an indication frame indicating to the MPC / NPCA non-AP STA that the secondary channel is available for communication with the MPC / NPCA AP STA. In embodiments, the indication frame includes a downlink (DL) frame. In embodiments, the indication frame may indicate to the MPC / NPCA non-AP STA that the MPC / NPCA AP STA has performed media channel synchronization on the secondary channel. In embodiments, the indication frame may include a trigger frame.

[0191] In additional or alternative embodiments, the first STA may include an MPC / NPCA non-AP STA, and the second STA may include an MPC / NPCA AP station, and the second channel may include a secondary channel. In embodiments, process 2300 may further include switching to the secondary channel based on the indication and upon concurrent reception of the first frame with the MPC / NPCA AP station. In embodiments, process 2300 may further include receiving the indication frame via the secondary channel, wherein the transmission of the second frame is based on the trigger frame. In embodiments, the indication frame may have already been transmitted by the MPC / NPCA AP station and to the MPC / NPCA non-AP station.

Claims

1. A method comprising: The first frame is received by the first STA from the second STA via the main channel. The first frame includes: Indication of the frame type for the first frame, and An indication of the duration of transmission following the first frame; and After receiving the first frame: Based on the frame type, the operation channel of the first STA is switched from the primary channel to the secondary channel; The second frame is transmitted by the first STA and via the secondary channel at the start time of transmission based on the duration of the transmission; and After the specified duration, switch from the secondary channel to the primary channel.

2. A method comprising: The first frame is received by the first STA from the second STA and via the first channel, the first frame including an indication of the frame type of the first frame; as well as After receiving the first frame and based on the indication of the frame type, the operating channel of the first STA is switched from the first channel to the second channel.

3. The method of claim 2, wherein the first STA or the second STA includes an ultra-high reliability STA.

4. The method of any one of claims 2 to 3, wherein the frame type of the first frame includes a request to send an RTS frame or a multi-user request to send a MU-RTS frame.

5. The method of any one of claims 2 to 3, further comprising transmitting a second frame by the first STA and via the second channel at the transmission start time based on the indicated indication.

6. The method of claim 5, wherein the indication includes a first duration, and wherein the transmission start time is based on transmitting the second frame before the end of the first duration.

7. The method of claim 6, wherein the first duration includes the transmission opportunity (TXOP) duration.

8. The method of any one of claims 6 to 7, wherein the transmission start time is based on a timeout period that begins after the first frame is received.

9. The method of claim 8, wherein the timeout period includes the NAVTimeout period.

10. The method of any one of claims 8 to 9, wherein the switching is performed after the timeout period.

11. The method of any one of claims 8 to 9, wherein the switching is performed during the timeout period.

12. The method of any one of claims 8 to 11, wherein the method further comprises detecting a third frame via the first channel, and wherein switching the transport channel to the second channel is performed after the third frame is received.

13. The method of claim 12, wherein switching to the second channel is based on receiving the third frame.

14. The method of claim 13, wherein the switching is performed based on receiving the third frame during the timeout period.

15. The method of any one of claims 12 to 14, wherein the third frame comprises a Physical Layer Protocol Data Unit (PPDU), and wherein the switching of the transport channel is performed after one of the following: The end of the preamble portion of the PPDU, The end of the PPDU transmission; and The end of the orthogonal frequency division multiplexing (OFDM) symbol of the PPDU.

16. The method of any one of claims 12 to 15, wherein the frame type of the third frame is one of the following: a data frame, a management frame, a transmit-permit (CTS) frame, a block acknowledgment request (BAR) frame, and a null data packet announcement (NDP) frame.

17. The method of any one of claims 12 to 16, wherein the first channel corresponds to a physical channel of the physical layer PHY associated with the first channel, and wherein receiving the third frame includes receiving a PHY-RXEARLYSIG indication primitive or a PHYRXSTART indication primitive via the physical channel during the first duration.

18. The method of any one of claims 2 to 17, wherein the first STA includes a non-primary channel access NPCA AP STA, the first channel includes a primary channel, and wherein the second channel includes a secondary channel.

19. The method of claim 18, further comprising detecting, after receiving the first frame and before switching to the auxiliary channel, communication from a non-NPCA non-AP station via the main channel.

20. The method of any one of claims 18 to 19, wherein the second STA includes an NPCA non-AP STA that switches to the auxiliary channel when the first frame is received concurrently with the NPCA APSTA, wherein the second frame includes an indication frame, and wherein the indication frame indicates to the NPCA non-AP STA that the auxiliary channel is available for communication with the NPCA AP STA.

21. The method of claim 20, wherein the indication frame comprises a downlink DL frame.

22. The method of any one of claims 20 to 21, wherein the indication frame indicates to the NPCA non-AP STA that the NPCA AP STA has performed medium channel synchronization on the auxiliary channel.

23. The method of any one of claims 20 to 22, wherein the indication frame includes a trigger frame.

24. The method of any one of claims 2 to 17, wherein the first STA comprises an NPCA non-AP station, and the second STA comprises an NPCA AP station, wherein the first channel comprises a primary channel, and wherein the second channel comprises a secondary channel.

25. The method of claim 24, further comprising: Based on the instruction, when the first frame is received concurrently with the NPCA AP station, the system switches to the auxiliary channel; as well as The indication frame is received via the auxiliary channel, wherein the transmission of the second frame is based on the indication frame.

26. The method of claim 25, wherein the indication frame is transmitted by the NPCA AP station and indicates to the NPCA non-AP station that the auxiliary channel is available for communication.

27. The method of any one of claims 25 to 26, wherein the indication frame indicates that the NPCA AP STA has performed media channel synchronization on the auxiliary channel.

28. The method of any one of claims 25 to 27, wherein the indication frame comprises at least one of: a management frame, a CTS (Cross Transmission Allowed) frame, a Block Acknowledgment Request (BAR) frame, and a Null Data Packet (NDP) Announcement frame.

29. An apparatus comprising: One or more processors; and A memory for storing instructions that, when executed by the one or more processors, cause the device to perform the method as described in any one of claims 1 to 28.

30. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method as described in any one of claims 1 to 28.

Images