Procedure for soft pre-emption based secondary channel access in wi-fi systems

Abstract

A method and apparatus for performing Secondary Channel Access (SCA) in a wireless network are disclosed. In one method, a station (STA), such as an access point (AP) STA, determines that the primary channel is busy and sends a Secondary Channel Access (SCA) Request Channel Switching (RCS) frame to one or more target STAs to switch to a designated secondary channel. The STA receives a Channel Acknowledgment Switching (CCS) message from at least one of the one or more target STAs and transmits or receives one or more Physical Layer Protocol Data Units (PPDUs) on the designated secondary channel. After a period of time (e.g., an SCA Transmission Opportunity (TXOP)), the STA switches back to the primary channel. Additional embodiments are disclosed.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 554,690, filed February 16, 2024, the contents of which are incorporated herein by reference. Background Technology

[0002] When the primary sub-channel is observed or measured to be busy or occupied by OBSS (Overlapping Basic Service Set) transmissions, the Secondary Channel Access (SCA) mechanism allows the access point (AP) or non-AP station ((one or more) STA) of the Basic Service Set (BSS) to transmit or receive frames on one or more secondary sub-channels, such as when it is observed or measured at the transmitter side, receiver side, or both sides.

[0003] Switching the target STA (the potential transmitter and receiver of a frame) to a secondary channel may be more efficient and effective when the primary channel is busy. However, notifying one or more target STAs to switch to a secondary channel is challenging because the primary channel is already busy—that is, busy with one or more transmissions in one or more OBSSs. The mechanism for requesting a target STA to switch to a secondary channel remains unresolved. Summary of the Invention

[0004] The aspects of this disclosure can solve the problem of switching to a secondary channel (also known as an anchor channel) when the primary channel is occupied by OBSS transmissions, which can be triggered by a secondary channel access (SCA) initiator, causing one or more SCA responders to switch to the anchor channel during a transmission opportunity (TXOP) (also known as an SCA TXOP) in which the primary channel is busy.

[0005] In one aspect, the SCA initiator may negotiate (advance) certain service periods with (one or more) SCA responders, during which they can expect the SCA initiator to initiate the SCA handover process. In another aspect, the SCA initiator may negotiate (advance) certain availability windows with (one or more) SCA responders, during which they can expect the SCA initiator to initiate the process. These aspects may be referred to as soft-preemptive SCA.

[0006] According to one aspect, a general procedure for soft-preemptive SCA is disclosed, comprising five phases of SCA and definitions of the behavior of the SCA initiator, SCA responder, and OBSS AP enabling the procedure. Additional aspects relate to different handover operations for space reuse, soft-preemptive, and transmission gap-based SCA.

[0007] Additional aspects may relate to defining Ultra-Reliable (UHR) Physical Layer Protocol Data Units (PPDUs) carrying Request for Channel Switching (RCS) frames and / or the process of switching to multiple auxiliary channels (referred to as the cascading process).

[0008] In one example, a method for a station (STA) may include determining that the primary channel is busy and sending a Secondary Channel Access (SCA) Request Channel Switching (RCS) message to one or more target STAs to switch to a specified secondary channel. The STA may send a Request to Send (RTS) message and receive a Clear to Send (CTS) message on the specified secondary channel to acknowledge that one of the target STAs has switched to the specified secondary channel. The STA may then send and / or receive one or more Physical Layer Protocol Data Units (PPDUs) with the acknowledged target STAs on the specified secondary channel and switch back to the primary channel after a period of time. In one example, the STA receives a Channel Acknowledgment Switching (CCS) message from one of the one or more target STAs on the specified secondary channel.

[0009] In the examples, a time period includes one of the following: an SCA Transmission Opportunity (TXOP), the time for sending or receiving an acknowledgment (ACK) to one or more PPDUs after the SCA TXOP, or a period shorter than the SCA TXOP for monitoring the primary channel until the primary channel is no longer busy. In one example, the SCA request message includes a trigger frame that includes user information fields specifying the target SCA responder and the resources on the specified secondary channel for the target SCA responder to send a CCS message. In one example, prior to sending the SCA request, the method further includes the STA negotiating one or more service periods or availability windows with one or more target STAs, during which the one or more target STAs can expect to receive the SCA request. Additional embodiments are disclosed. Attached Figure Description

[0010] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the drawings indicate the same elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1AThe diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The system diagram shown in the figure illustrates a further example RAN and a further example CN used within the communication system. Figure 2 This is a timing diagram illustrating an example of individual target wake-up time (TWT) operation; Figure 3 This is a flowchart illustrating the general process of soft preemption-based assisted channel handover; Figure 4 This is a message sequence diagram illustrating Example Scenario 1 for Soft Preemption-Based Assisted Channel Access (SCA); Figure 5 This is a message sequence diagram illustrating Example Scenario 2 for SCA based on soft preemption; Figure 6 This is a message sequence diagram illustrating Example Scenario 3 for soft-preemption-based auxiliary channel access with early handover, according to an embodiment; Figure 7 This is a message sequence diagram illustrating example scenario 4 of an auxiliary channel access based on soft preemption, according to an embodiment, which switches back exactly after a transmission opportunity (TXOP) in SCA. Figure 8 This is a message sequence diagram illustrating example scenario 5 of SCA based on soft preemption for extended transmission using late switchback, according to an embodiment; Figure 9 This is a message sequence diagram illustrating Example Scenario 6 of soft-preemptive SCA, which uses Basic Service Set Physical Packet Data Unit (BSS PPDU) on the anchor channel and Acknowledgment (ACK) on the main channel, according to an embodiment. Figure 10 This is a message sequence diagram illustrating example scenario 7 of a soft-preemptive SCA for identifying a successful handover responder for use in a downlink (DL) PPDU, according to an embodiment; Figure 11 This is a message sequence diagram illustrating example scenario 8 of a soft-preemptive SCA for identifying a successful handover responder for uplink (UL) trigger-based (TB) PPDU, according to an embodiment. Figure 12 This is a message sequence diagram illustrating example scenario 9 of a soft-preemptive SCA with bidirectional handshake, according to an embodiment; Figure 13This is a flowchart illustrating a method according to an embodiment for a non-access point (AP) STA to use a three-way handshake as an SCA initiator to perform UL single-user (SU) PPDU anchor transmission using a three-way handshake; Figure 14 This is a flowchart illustrating a method for a non-AP STA to perform anchor channel UL SU PPDU transmission based on a two-way handshake, according to an embodiment; Figure 15 This is a flowchart illustrating a method for transmitting a SU / multi-user (MU) PPDU in the anchor channel DL using a three-way handshake, according to an embodiment, where a non-AP STA acts as an SCA responder and an AP STA acts as an SCA initiator. Figure 16 This is a flowchart illustrating a method for a non-AP STA to transmit SU / MU PPDU in the anchor channel DL based on a two-way handshake, according to an embodiment; Figure 17 This is a diagram illustrating an example of transmit power adjustment based on Overlapping Basic Service Set (OBSS) Packet Detection (PD) spatial reuse (SR) operation in an embodiment; Figure 18 This is a network diagram illustrating an exemplary scenario of advantageous conditions for performing a soft preemption process according to one embodiment; Figure 19 This is a message sequence diagram illustrating an exemplary illustration of a transmission gap in an OBSS PPDU that can be used for SCA alteration according to an embodiment; Figure 20 This is a message sequence diagram illustrating an exemplary scenario of soft-preemptive SCA in a multi-auxiliary-channel scenario according to an embodiment, where the SCA initiator detects that the first auxiliary channel is busy; and Figure 21 This is a message sequence diagram illustrating an exemplary scenario of soft-preemptive SCA in a multi-auxiliary-channel scenario when one or more SCA responders detect that the first auxiliary channel is busy, according to another embodiment. Detailed Implementation

[0011] Figure 1AThis diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0012] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any one of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0013] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b can be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs), new radio (NR) NodeBs), site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0015] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0016] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0017] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0018] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technology (such as NR radio access) that can use NR to establish air interface 116.

[0019] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0020] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0021] Figure 1A Base station 114b can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0022] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but will be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0024] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0025] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may also include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0026] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0027] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0028] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0029] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0030] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, processor 118 may access memory information that is never physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0031] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0032] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0033] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, and the like.

[0034] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0035] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0036] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0037] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0038] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0039] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and the like. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0041] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0042] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or can communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0043] Despite WTRU in Figure 1A-1D While described as a wireless terminal, in some representative embodiments such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0044] In a representative embodiment, the other network 112 may be a WLAN.

[0045] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or interfaces to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or leaves the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0046] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0047] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0048] The Very High Throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0049] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., for maintaining very long battery life).

[0050] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most of the available frequency bands remain idle.

[0051] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0052] Figure 1D The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0053] RAN 104 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0054] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / be connected to gNBs 180a, 180b, and 180c, and also communicate with / be connected to another RAN (such as eNode-B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0056] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0057] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0058] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., processing different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and so on. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0059] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services conducted through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0060] UPF 184a and 184b can be connected via an N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 104. This N3 interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and so on.

[0061] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via UPFs 184a and 184b through the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0062] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions, and one or more of the functions described herein with reference to one or more of the following items, may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing and / or to perform tests using over-the-air wireless communication.

[0064] One or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0065] Overview of WLAN Systems. A WLAN in Infrastructure Basic Services Set (BSS) mode has an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP typically has access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and out of the BSS. Traffic originating outside the BSS and destined for a STA arrives at and is delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS is sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can also be sent via the AP, where the source STA sends traffic to the AP, and the AP delivers the traffic to the destination STA. Such traffic between STAs within the BSS is effectively point-to-point traffic. Such point-to-point traffic can also be sent directly between the source and destination STAs using Direct Link Establishment (DLS) with 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using Standalone BSS (IBSS) mode do not have APs, and / or STAs communicate directly with each other. This communication mode is called a “self-organizing” communication mode.

[0066] By using the 802.11ac infrastructure operating mode, the AP can transmit beacons on a fixed channel (typically the primary channel). This channel can be 20 MHz wide and is the operating channel of the BSS. This channel is also used by the STA to establish a connection with the AP. The basic channel access mechanism in an 802.11 system is Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA). In this operating mode, each STA (including the AP) will listen for occupancy or idleness of the primary channel. If the channel is detected to be busy, the STA backs off. Therefore, in a given BSS, only one STA can transmit at any given time.

[0067] In 802.11n, High Throughput (HT) STAs can also communicate using a 40 MHz wide channel. This is achieved by combining a primary 20 MHz channel with an adjacent 20 MHz channel to form a continuous 40 MHz wide channel.

[0068] In 802.11ac, Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and 160 MHz. 40 MHz and 80 MHz channels are formed by combining consecutive 20 MHz channels, similar to 802.11n described above. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (this can also be referred to as an 80+80 configuration). For the 80+80 configuration, at the transmitter, after channel coding, the data passes through a segment resolver, which splits it into two streams. Each stream undergoes IFFT and time-domain processing separately. The streams are then mapped onto the two channels, and the data is transmitted. At the receiver, this mechanism is reversed, and the combined data is sent to the MAC.

[0069] 802.11af and 802.11ah support sub-1 GHz operating modes. For these specifications, compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carrier are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. A possible use case for 802.11ah is supporting instrument type control (MTC) devices in macro coverage areas. MTC devices can have limited capabilities, including supporting only limited bandwidth, but also requirements for very long battery life.

[0070] WLAN systems supporting multiple channels and channel widths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel designated as the primary channel. The primary channel can (but does not necessarily) have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. Therefore, the bandwidth of the primary channel is limited by the number of STAs operating in the BSS that support the minimum bandwidth operating mode. In the example of 802.11ah, if there are STAs that only support the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS may support 2MHz, 4 MHz, 8 MHz, 16 MHz, or other channel bandwidth operating modes. All carrier sense and NAV settings depend on the state of the primary channel; that is, if the primary channel is busy, for example because STAs supporting only the 1 MHz operating mode are transmitting to the AP, the entire available band is considered busy even if most of it remains idle and available.

[0071] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, it is from 917.5 MHz to 923.5 MHz; and in Japan, it is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0072] Existing solutions for secondary channel access include Subchannel Selective Transmission (SST). Starting with 802.11ax, the SST mechanism was defined to allow STAs to transmit and receive on secondary channels. High-Efficiency (HE) SST for non-AP STAs and HE SST APs can establish SST operation by negotiating the enabled target wake-up time (TWT) using an individual TWT protocol. (Reference) Figure 2 This shows an example of an individual TWT operation 200.

[0073] The TWT elements are shown in Table 1. Element ID length control TWT parameter information

[0074] Table 1: TWT Elements The control fields of the TWT element defined in 802.11be are shown in Table 2.

[0075] Table 2: Control Fields in the TWT Element of 802.11be The Broadcast subfield in the Negotiation Type subfield indicates whether the TWT element is used for broadcast TWTs or individual TWTs. If the Broadcast field of the Negotiation Type subfield is 0 (the TWT element is used for individual TWTs), then the TWT element contains only one set of individual TWT parameters.

[0076] The individual TWT parameter information fields defined in 802.11be are shown in Table 3. The TWT channel subfield in the individual TWT parameter set field indicates the subchannel that the STA may need to monitor.

[0077] Table 3: Individual TWT Parameter Set Fields Defined in 802.11be SST operation allows non-AP STAs to operate on either the secondary 20MHz or secondary 80MHz sub-channels within the negotiated TWT service period (SP). Non-AP STAs should be available at the start of the TWT and should not use Distributed Coordination Function (DCF) or Enhanced Distributed Channel Access Function (EDCAF) to access the medium in the sub-channel. Instead, channel access for non-AP STAs during SST operation is triggered on a trigger (TB) basis, meaning the AP grants uplink resources to the non-AP STA to perform uplink transmissions. Non-AP STAs may include a channel handover timing element in their (re)association request frames transmitted to the AP to indicate the time required for the STA to hand over between different sub-channels.

[0078] The IEEE 802.11 Ultra-High Reliability (UHR) Study Group was established in September 2022. UHR is considered the next major revision of the IEEE 802.11 standard, following 802.11be, which is currently in the working group letter voting phase. UHR was established to explore possibilities for improving reliability, supporting low-latency services, and further increasing peak throughput and efficiency of IEEE 802.11 networks. Secondary channel access has been discussed in 802.11bn and the UHR SG.

[0079] As previously mentioned, secondary channel access (SCA) is an issue requiring improved solutions. When the primary subchannel is busy or occupied (observations or measurements are transmitted by the Overlapping Basic Service Set (OBSS) at the transmitter side, receiver side, or both sides), the secondary channel access mechanism allows one or more APs or non-AP STAs to transmit or receive frames on one or more secondary subchannels.

[0080] Switching the target STA (the potential transmitter and receiver of a frame) to a secondary channel may be more efficient and effective when the primary channel is busy. However, notifying one or more target STAs to switch to a secondary channel is challenging because the primary channel is already busy—that is, busy with one or more transmissions in one or more OBSSs. The mechanism for requesting a target STA to switch to a secondary channel remains unresolved.

[0081] Embodiments for preemption-based secondary channel access terminology are disclosed. The following description is presented as example terminology.

[0082] Soft preemption refers to a transmission using the same or a portion of the resources used by an ongoing transmission (preempted transmission). Preempted transmissions can interfere with ongoing transmissions.

[0083] SCA Initiator - refers to a STA that initiates a switch to the anchor channel by sending a Request Channel Switching (RCS) frame on the busy primary channel.

[0084] SCA Responder - refers to the STA that receives the RCS frame that initiates the switch to the anchor channel and responds to the RCS frame by switching to the anchor channel.

[0085] Anchor channel - refers to a designated non-primary channel advertised by the associated AP to the STA in the BSS, used to access an available secondary channel when the primary channel is occupied (e.g., occupied by OBSS transmissions).

[0086] SCA Transmission Opportunity (TXOP) - refers to the duration of a TXOP in which the primary channel is occupied by an OBSS transmission and provides a potential opportunity for a STA in the BSS to switch to one or more secondary channels.

[0087] Basic Service Set (BSS) Physical Layer Protocol Data Unit (PPDU) - refers to a PPDU transmitted from the SCA initiator to the SCA responder or vice versa.

[0088] An embodiment of a soft preemption procedure for secondary channel access using a single anchor channel is disclosed. When the primary channel is occupied by OBSS transmissions, the switch to the secondary channel (also known as the anchor channel) can be triggered by the SCA initiator, causing one or more SCA responders to switch to the anchor channel during a TXOP (also known as an SCA TXOP) when the primary channel is busy, such as... Figure 4 As shown in the diagram.

[0089] In one embodiment, such as Figure 3 As illustrated in the figure, the process 300 for STA to switch to the auxiliary channel may include the following five main stages (1)-(5).

[0090] (1) Primary Channel Assessment (305) - In this phase, the SCA initiator performs a Free Channel Assessment (CCA) and determines that the primary channel is busy.

[0091] (2) Switch to the secondary channel (310) - In this phase, the SCA initiator requests one or more target STAs (SCA responders) to switch to the designated secondary channel (also known as the anchor channel).

[0092] (3) Handover confirmation (315) - In this phase, the SCA initiator may perform a frame exchange with (one or more) SCA responders to confirm that the handover has been successfully performed.

[0093] (4) Transmitting PPDU (320) - In this phase, the SCA initiator and / or (one or more) SCA responders may use the anchor channel (e.g., as a temporary master channel) to transmit and / or receive one or more PPDUs. These PPDUs may carry data, management, control, or action frames.

[0094] (5) Switch back to the main channel (325) - In this phase, the SCA initiator and / or (one or more) SCA responders switch back from the anchor channel to the main channel.

[0095] During the Free Channel Assessment (CCA) in Phase 1 (i.e., Main Channel Assessment 305), the SCA initiator may perform one or both of Energy Detection (ED) and Preamble Detection (PD) on the main channel to determine if the main channel is busy. As an example, the main channel may be busy due to transmissions from non-Wi-Fi or Wi-Fi technologies. The assumption considered in this disclosure is that the SCA initiator can determine that the main channel is occupied by a transmission from the OBSS. The SCA initiator can determine that the current transmission originates from the OBSS, for example, by decoding the BSS color and TXOP field in the preamble of the PPDU occupying the main channel (e.g., in the case of .11ax / .11be OBSS).

[0096] In one method, Figure 3 The general process 300 illustrated can also be applied to situations where the primary channel is determined to be busy due to non-Wi-Fi interference. In one example, once the SCA initiator and / or (one or more) SCA responders successfully switch to the anchor channel, they can start a countdown timer, and once the timer expires / resets to zero, they can begin switching back to the primary channel phase. In another example, the countdown timer can begin with any of the following: transmission of an RCS frame, reception of an RCS frame, transmission of a CCS frame, or reception of a CCS frame.

[0097] In one embodiment, implementation Figure 3In process 300, one or more SCA responders can negotiate conditions under which they can remain awake when they determine that the primary channel is busy. In one approach, the SCA initiator can negotiate (in advance) certain service periods (SPs) with one or more SCA responders during which they can expect the SCA initiator to initiate the process. In another approach, the SCA initiator can negotiate (in advance) certain availability windows with one or more SCA responders during which they can expect the SCA initiator to initiate the process.

[0098] refer to Figure 4 Example method 400 is shown for one embodiment, wherein the SCA initiator can be a transmitter of PPDU 430 to one or more SCA responders, who are the intended receivers of the PPDU. In one example, the SCA initiator can be an AP, while the one or more SCA responders can be one or more non-AP STAs (e.g., using downlink single-user (SU) PPDUs and / or downlink multi-user (MU) PPDUs). In another example, the SCA initiator can be a non-AP STA, while the SCA responder can be an AP (e.g., in the case of an uplink SU PPDU).

[0099] refer to Figure 5 Example method 500 is shown for such an embodiment, where the SCA initiator can be a receiver of a PPDU from an SCA responder, who is the intended transmitter of that PPDU. In one example, the SCA initiator can be an AP, while one or more SCA responders can be one or more non-AP STAs (e.g., uplink SU PPDUs or uplink trigger-based (TB) PPDUs). Various combinations of SCA initiator / responder roles are listed in Table 4 below.

[0100] In some embodiments, the SCA initiator (e.g., an AP) can trigger one or more non-AP STAs (SCA responders) to switch to the anchor channel, and then the SCA initiator can transmit a PPDU to (one or more) SCA responders in the downlink or trigger (one or more) SCA responders to transmit a PPDU in the uplink. In other embodiments, the SCA initiator (e.g., a non-AP STA) can trigger an AP (SCA responder) to switch to the anchor channel, and then the SCA initiator (non-AP STA) can transmit a PPDU in the uplink.

[0101] In various embodiments, the target transmitter / receiver of the PPDU (i.e., Figure 4 PPDU 430 / Figure 5PPDU 530 is triggered to switch to the anchor channel during a TXOP in which the primary channel may be occupied by OBSS transmissions. This TXOP may be referred to as SCA TXOP.

[0102] Table 4: Potential PPDU Types for Different Combinations of SCA Sponsor / Responder Roles Example behavior of STAs (i.e., AP STAs and non-AP STAs) according to example embodiments will now be described. Return to the reference example. Figure 4 In method 400, the SCA initiator can initiate a handover process from the primary channel 401 to the secondary channel (also known as the anchor channel 403) by sending a Request Channel Switching (RCS) frame 405 addressed to one or more SCA responders (i.e., the target STAs for transmitting or receiving potential PPDUs). At step 410, the SCA initiator can then switch to the anchor channel, and if the RCS frame from the initiator is successfully received, the SCA responder can switch to the anchor channel. The SCA initiator can then perform a Full Clear Channel Assessment (CCA) on the anchor channel. In an example embodiment, a Full CCA can include a physical CCA 415 via a listening channel and a virtual CCA by sending a Request to Send (RTS) / Multi-User Request to Send (MU-RTS) 420 on the anchor channel and waiting for a Clear Send (CTS) response 425 from one or more SCA responders. The SCA initiator can then send one or more PPDUs 430 to one or more SCA responders. One or more SCA responders can then send an Acknowledgment (ACK) 435 to the SCA initiator on the anchor channel. Alternatively or concurrently, the SCA responder may send an ACK on the primary channel after switching back to the primary channel from 440. Figure 4 (not shown in the image) (see example) Figure 9 Method 900).

[0103] In various embodiments, the handover indication (ITS) and request for channel handover (RCS) can be used interchangeably, both referring to the same frame. Furthermore, anchor channels (one or more) and secondary channels (one or more) can be used interchangeably, referring to channels other than the primary channel.

[0104] In some embodiments (e.g., Figure 4 , Figure 5 and Figure 7The SCA initiator and / or (one or more) SCA responders may remain in the anchor channel for the duration of the SCA TXOP and then switch back to the main channel. Additionally or alternatively, the SCA initiator and / or (one or more) SCA responders may remain in the anchor channel for a longer period than the SCA TXOP to complete the ongoing transmission and send an ACK response (see, for example...). Figure 8 Additionally or alternatively, the SCA initiator and / or (one or more) SCA responders may remain in the anchor channel for a shorter time than the SCA TXOP, and then switch back and continue monitoring the primary channel until the primary channel is released (see, for example...). Figure 6 ).

[0105] In one embodiment, after a successful switch to the anchor channel, the SCA initiator can send a trigger frame addressed to an SCA responder on the anchor channel to request confirmation from each SCA responder which SCA responder has successfully switched to the anchor channel. The trigger frame may include a user information list, where each target SCA responder has a user information field specifying a resource on the anchor channel, on which the SCA responder can send a response to indicate that it has successfully switched to the anchor channel, such as by... Figure 10 The example embodiments are illustrated. Responses from each SCA responder may also include a list of secondary channels that are accessible or available to the responder via an indication format (e.g., bitmap format).

[0106] In one embodiment, the trigger frame (sent by the SCA initiator) may be a polling trigger frame, and the response (requested from the SCA responder) may be a CTS-To-Self frame. In another example, the trigger frame may be an Empty Data Packet (NDP) Feedback Report Polling (NFRP) trigger frame, and the response may be an NDP Feedback Report (NFR).

[0107] In one embodiment, the SCA initiator may send a BSS PPDU to all SCA responders indicated in the RCS frame, which may be an RTS frame that includes SCA information, regardless of whether they respond to the RCS / RTS frame with an Acknowledgment Channel Switching (CCS) frame (which in some examples may be a CTS frame).

[0108] In one embodiment, the SCA initiator can trigger all SCA responders indicated in the RCS frame to send a BSS TBPPDU, regardless of whether they respond to the RTS frame with a CTS / CCS frame.

[0109] In one embodiment, the SCA initiator may send a BSS PPDU to all SCA responders indicated in the RCS frame only if the SCA initiator receives a CTS frame from one or more of the SCA responders. If the SCA initiator does not receive a response from any of the SCA responders, it may avoid transmitting any PPDU on the anchor channel.

[0110] In one embodiment, the SCA initiator may trigger all SCA responders indicated in the RCS frame to transmit a BSS-based trigger (TB) PPDU only if the SCA initiator receives a CTS frame from one or more of the SCA responders. If the SCA initiator does not receive a response from any of the SCA responders, it may avoid triggering any of the SCA responders.

[0111] In one example, the SCA initiator may send a BSS PPDU only to the SCA responder in response to a trigger frame, which requests a response indicating a successful handover to the anchor channel. In another example, the SCA initiator may send a BSS PPDU to an SCA responder that transmitted CTS-To-Self (CTS2S) in response to a polling trigger frame. In yet another example, the SCA initiator may send a BSS PPDU to an SCA responder that transmitted NFR in response to an NFRP trigger frame.

[0112] In one embodiment, the SCA initiator may trigger only the SCA responders in response to a trigger frame to transmit a TB PPDU on the anchor channel, the trigger frame requesting a response indicating a successful switch to the anchor channel. In one example, the SCA initiator may trigger the transmission of a BSS TB PPDU from an SCA responder that transmitted CTS-To-Self in response to a polling trigger frame. In another example, the SCA initiator may trigger the transmission of a BSSTB PPDU from an SCA responder that transmitted NFR in response to an NFRP trigger frame, such as... Figure 11 As shown in the example embodiments.

[0113] In one embodiment, the SCA initiator may switch to the anchor channel and wait for a Confirmation Channel Switching (CCS) frame sent by one or more SCA responders to confirm a successful switch to the anchor channel. The SCA initiator may then send a BSS PPDU to the SCA responder or trigger the SCA responder to transmit a BSS TB PPDU, for example, as... Figure 12 As shown in the example embodiments.

[0114] Return to reference Figure 4Method 400 illustrates an exemplary scenario 1, where the SCA initiator is the transmitter of a potential BSS PPDU 430, and the SCA responder(s) are receivers. The transmission of the BSS PPDU 430 is preferably managed such that the transmission occupies the majority of SCA TXOP 402, and allows for the reception of one or more ACKs on anchor channel 403 just before SCA TXOP 402 has passed. In this scenario, the handover 440 back to the main channel 401 begins just after SCA TXOP has passed.

[0115] refer to Figure 5 Method 500 illustrates an exemplary scenario 2, which is similar to Figure 4 In scenario 1, the SCA initiator is the receiver of the potential BSS PPDU 530, while the SCA responder is the transmitter. Figure 5 Method 500 and other subsequent figures can be similar. Figure 4 Method 400, and the descriptions of related elements and steps may be omitted due to repetition.

[0116] refer to Figure 6 An exemplary scenario 3 is illustrated for method 600, in which the transmission of BSS PPDU 630 and the reception of ACK 635 are completed before SCA TXOP 602, and the handover back to the main channel 640 begins before SCA TXOP has passed. This example embodiment may be referred to as SCA with early handover back.

[0117] In one embodiment, reference Figure 7 An exemplary scenario 4 is shown for method 700, in which the transmission of BSS PPDU 730 and the reception of ACK 735 are completed before SCA TXOP 702, but the switch back to the main channel 740 waits until SCA TXOP 702 has passed.

[0118] In one embodiment, reference Figure 8 An exemplary scenario 5 is illustrated for method 800, in which the transmission of BSS PPDU 830 and the reception of ACK 835 are later than the completion of SCA TXOP 802, and then the switchback to the main channel 840 begins after ACK 835. This example embodiment may be referred to as SCA with late switchback.

[0119] In one embodiment, reference Figure 9Example scenario 6 is shown in method 900, where the transmission of BSS PPDU 930 is later than the completion of SCA TXOP 902, then the switch back to the main channel begins at 940, and then ACK 935 is sent / received on the main channel. In this example, the SCA responder performs CCA 937 on the main channel before sending ACK 935.

[0120] In one embodiment, reference Figure 10 Example scenario 7 is shown in method 1000, where the SCA initiator transmits a trigger frame 1027 on the anchor channel to request acknowledgment (e.g., polling / CTS-to-Self (CTS-TS) or NFRP / NFR) from one or more SCA responders who have successfully switched to the anchor channel. The SCA initiator then transmits one or more BSSPPDUs 1030 to the SCA responders, or as... Figure 11 As shown in method 1100, trigger frame 1127 requests the SCA responder to transmit one or more BSSTB PPDUs 1130.

[0121] In one embodiment, reference Figure 12 Example scenario 9 is shown in method 1200, which represents a two-way handshake alternative. In scenario 9, the SCA initiator transmits a request for channel switching (RCS) 1205 on the primary channel to switch to the anchor channel, and monitors the anchor channel to receive an acknowledgment of channel switching (CCS) 1225 before starting to transmit BSS PPDU 1230.

[0122] refer to Figure 13 An example method 1300 is illustrated for a non-AP STA acting as the SCA initiator and an AP STA acting as the responder to use a three-way handshake to transmit a UL single-user (SU) PPDU on an anchor channel. In this example embodiment, note that the SCA initiator sends an ITS / RTS to change the channel, then requests an indication of the channel change from the SCA responder regarding the new channel, and receives confirmation of the channel change from the SCA responder—that is, a three-way handshake. It is worth noting that the handover indication (ITS) and the request for channel handover (RCS) can be used interchangeably, both referring to the same frame.

[0123] As with any method disclosed herein, the steps and / or elements of method 1300 may be omitted, modified, performed in a different order, and / or combined with other example embodiments disclosed herein.

[0124] The SCA initiator (e.g., a non-AP STA) performs a full CCA (physical CCA + virtual CCA) on the primary channel at 1305 and finds the primary BSS channel occupied by an OBSS transmission. If the SCA initiator (non-AP STA) has queued packets to send to the SCA responder (AP) at 1310, it can initiate a switch to the anchor channel at 1320 by sending an Indication to Switch to the Second Channel (ITS) (e.g., an RCS frame) on the primary channel, and then switch to the second channel (also known as the anchor channel) at 1365. If the SCA initiator (non-AP STA) has no queued packets at 1310, it can set NAV 1315 and enter sleep mode. In one example, the SCA initiator adjusts the transmit power of the PPDU carrying the ITS / RCS frame so that the SCA responder can successfully receive the PPDU at 1325.

[0125] If the 1325 RCS frame is successfully received by the SCA responder (AP), the SCA responder switches 1335 to the anchor channel, performs CCA, and monitors the anchor channel for an RTS frame from the SCA initiator.

[0126] If the SCA responder at step 1325 does not receive a PPDU carrying the RCS, it can continue monitoring the primary channel, or it can set the Network Allocation Vector (NAV) at step 1330 and enter sleep mode. At step 1365, the SCA initiator sends an RTS frame or other indication requesting the SCA responder to acknowledge the channel change, such as a polling frame, trigger frame, etc., and monitors the channel waiting for the SCA responder to respond with an indication to acknowledge the channel change (e.g., a CTS frame).

[0127] If the SCA responder at 1340 successfully receives the RTS frame, it responds with a CTS frame at 1350. If the SCA responder at 1340 does not successfully receive the RTS frame, it can switch back to the main channel at 1345, wait for another RTS, or wait until the SCA TXOP has passed and then switch back to the main channel. If the SCA initiator at 1370 successfully receives the CTS frame, it transmits one or more BSS PPDUs to the SCA responder at 1380, monitors the channel for ACK, and then switches back to the main channel at 1385, for example, after a period of time. If the SCA initiator at 1370 does not successfully receive the CTS frame, at step 1375, it can switch back to the main channel, transmit another RTS on the anchor channel, or wait until the SCA TXOP has passed and then switch back to the main channel.

[0128] After successfully receiving one or more BSS PPDUs at step 1355, the SCA responder can respond with ACK on the anchor channel 1360 and switch back to the main channel, switch back to the main channel and then respond with ACK on the main channel, and / or wait until the SCA TXOP has passed and switch back to the main channel.

[0129] refer to Figure 14 An example method 1400 is shown for a non-AP STA acting as an SCA initiator and an AP STA acting as a responder to use a two-way handshake to transmit a PPDU on an anchor channel for a UL single-user (SU). As with any method disclosed herein, the steps and / or elements of method 1400 may be omitted, modified, performed in a different order, and / or combined with other example embodiments disclosed herein.

[0130] In this example, the SCA initiator (e.g., a non-AP STA) performs a full CCA (i.e., physical CCA + virtual CCA) at 1405 on the first BSS channel (e.g., the primary channel) and finds the primary channel occupied by OBSS transmissions. If the SCA initiator (non-AP STA) at 1410 has queued packets to send to the SCA responder (AP), the SCA initiator (non-AP STA) can initiate a switch to the second BSS channel (e.g., the anchor channel) at 1415 by sending a handover indication / (ITS) / request for channel switching (RCS) frame on the primary channel, and then switch to the second BSS channel (e.g., the indicated / designated anchor channel) at 1420. In this example, the SCA initiator adjusts the transmit power of the PPDU carrying the RCS frame so that the SCA responder can successfully receive the PPDU. If the SCA initiator (non-AP STA) at 1410 has no queued packets, it can set up a NAV at 1425 and enter sleep mode.

[0131] If the 1430 RCS frame is successfully received by the SCA responder (AP), the SCA responder switches to the anchor channel at 1435, performs a CCA on the anchor channel, and transmits an indication of channel change (e.g., clearing the transmit (CTS) / acknowledging channel switch (CCS) frame) to the SCA initiator. If the 1430 SCA responder does not receive a PPDU carrying the ITS / RCS, it can either continue monitoring the primary channel or set up the 1440 NAV and enter sleep mode.

[0132] At step 1445, if the SCA initiator successfully receives the CCS frame, it transmits one or more BSS PPDUs to the SCA responder at 1450, monitors channel 1455 for ACK reception, and then switches back to the main channel. If the SCA initiator does not successfully receive the CCS frame at 1445, it can switch back to the main channel at 1460, wait for another CCS, or wait until SCATXOP passes and then switch back to the main channel.

[0133] If the SCA responder receives a PPDU with its address at 1465, the AP STA receives the PPDU at 1470. In one example, the PPDU is received at the x-inter-frame interval (xIFS) following the CTS transmission, where x corresponds to the type of IFS. After successfully receiving one or more BSS PPDUs, the SCA responder can respond with an ACK at 1475 on the anchor channel and switch back to the main channel, switch back to the main channel and then respond with an ACK on the main channel, and / or wait until the SCATXOP passes and switch back to the main channel. Otherwise, if the SCA responder does not receive a PPDU addressed to it at 1465, the responder can immediately switch back to the main channel at 1480, transmit another CCS, or wait for the SCA TXOP to pass and switch back to the main channel.

[0134] refer to Figure 15 This document illustrates an example method 1500 for using a three-way handshake in a single-user (SU) / multi-user (MU) transmission PPDU on an anchor channel DL where a non-AP STA acts as an SCA responder and an AP STA acts as an SCA initiator. As with any method disclosed herein, the steps and / or elements of method 1500 may be omitted, modified, performed in a different order, and / or combined with other example embodiments disclosed herein.

[0135] At step 1505, the SCA initiator (e.g., an AP STA) can perform a full CCA (physical CCA + virtual CCA) on the first channel (i.e., the primary BSS channel) and find that the primary channel is occupied by OBSS transmissions. If the SCA initiator (AP STA) has queued packets to send to the SCA responder (e.g., a non-AP STA) at step 1510, the SCA initiator (AP STA) can initiate a switch to the anchor channel at step 1515 by sending an ITS / RCS frame on the primary channel, and then switch to the anchor channel at step 1520. If the SCA initiator (AP STA) has no queued packets at step 1510, it can set the NAV at step 1525 and enter a sleep mode. In one example, the SCA initiator adjusts the transmit power of the PPDU carrying the RCS frame so that the SCA responder can successfully receive the PPDU, for example, using the spatial reuse (SR) parameter.

[0136] At step 1530, if the ITS / RCS frame is successfully received by the SCA responder (non-AP STA), the SCA responder switches to the anchor channel at 1535, can perform CCA, and monitor the anchor channel to obtain an indication (e.g., an RTS frame) requesting channel change acknowledgment from the SCA initiator (sent at step 1520, where the SCA initiator sends an RTS frame on the anchor channel and monitors the channel waiting for the SCA responder to respond with a channel change acknowledgment indication (e.g., a CTS frame)). If the SCA responder does not receive a PPDU carrying the RCS at 1530, it can continue monitoring the main channel, or it can set up the NAV at 1540 and enter sleep mode.

[0137] If the 1537 SCA responder successfully receives the RTS frame, it responds with a CTS frame at 1545. If the 1537 SCA responder does not successfully receive the RTS frame, it can switch back to the main channel at 1539 and wait for another RTS, or wait until the SCA TXOP has passed and then switch back to the main channel.

[0138] At step 1550, if the SCA initiator successfully receives the CTS frame, it transmits one or more BSS PPDUs at 1555 to the SCA responder, monitors channel 1560 for ACK reception, and then switches back to the main channel. Alternatively, the SCA initiator can switch back to the main channel, as the ACK may be sent by the SCA responder on the main channel. If the SCA initiator does not successfully receive the CTS frame at 1550, at step 1565, it can switch back to the main channel at 1565, send another RTS, or wait until the SCA TXOP has passed and then switch back to the main channel.

[0139] After successfully receiving one or more BSS PPDUs at step 1570, the SCA responder can respond with ACK on the anchor channel at 1575 and switch back to the main channel, switch back to the main channel and then respond with ACK on the main channel, and / or wait until the SCA TXOP has passed and switch back to the main channel.

[0140] refer to Figure 16 An example method 1600 is shown for transmitting PPDUs in a single-user (SU) / multi-user (MU) anchor channel DL using a two-way handshake, where a non-AP STA acts as an SCA responder and an AP STA acts as an SCA initiator. As with any method disclosed herein, the steps and / or elements of method 1600 may be omitted, modified, performed in a different order, and / or combined with other example embodiments disclosed herein.

[0141] At step 1605, the SCA initiator (AP STA) performs a full CCA (e.g., physical CCA + virtual CCA) on the first channel of the BSS (e.g., the primary channel) and finds the primary channel occupied / busy by OBSS transmissions. If the SCA initiator (AP STA) has queued packets to send to the SCA responder (non-AP STA) at step 1610, the SCA initiator (AP STA) can initiate a switch to the anchor channel at step 1615 by sending an ITS / RCS frame on the primary channel, and then switch to the second BSS channel (e.g., the anchor channel) at step 1620. If the SCA initiator (AP STA) has no queued packets at step 1610, it can set the NAV at step 1625 and enter a sleep mode. As in other embodiments, the SCA initiator can, for example, use spatial reuse parameters to adjust the transmit power of the PPDU carrying the ITS / RCS frame so that the SCA responder can successfully receive the PPDU, even though the primary channel is detected as busy due to one or more OBSS transmissions.

[0142] At step 1630, if the ITS / RCS frame is successfully received by the SCA responder (non-AP), the SCA responder switches to the anchor channel at 1635, performs CCA, and transmits an indication to the SCA initiator to confirm the channel change to the anchor channel (e.g., confirm channel switch (CCS) frame, CTS, CTS to self (CTSTS), etc.). If the SCA responder does not receive a PPDU carrying the ITS / RCS at 1630, it can continue monitoring the primary channel, or it can set up a NAV at 1640 and enter sleep mode.

[0143] At step 1645, if the SCA initiator successfully receives the CCS frame, it transmits one or more BSS PPDUs at 1650 to the SCA responder, then monitors the anchor channel at 1655 to receive an ACK, and then switches back to the main channel. Alternatively, the SCA initiator may switch back to the main channel and receive an ACK and / or other options as described herein. At step 1645, if the SCA initiator does not successfully receive the CCS frame, it may switch back to the main channel at 1660, wait for another CCS, send an RTS requesting an indication from the SCA responder, or wait until the SCA TXOP has passed and then switch back to the main channel. For this example embodiment, note that there may be no transmission of an indication from the SCA initiator requesting a channel change from the SCA responder. That is, only the ITS / RCS is transmitted, and the SCA responder indicates that it has switched to the anchor channel, i.e., a two-way handshake.

[0144] At step 1665, if the SCA responder does not receive a PPDU from the SCA initiator, for example after sending an xIFS of a CCS, the SCA responder may switch back to the main channel at 1670, send another CCS, or wait until the SCA TXOP has passed and then switch back to the main channel. Otherwise, after successfully receiving one or more BSS PPDUs (as shown in steps 1665 and 1670), the SCA responder may respond with an ACK on the anchor channel at 1680 and switch back to the main channel, switch back to the main channel and then respond with an ACK on the main channel, and / or wait until the SCA TXOP has passed and switch back to the main channel.

[0145] refer to Figure 17 An example method for channel handover operation with SCA based on spatial reuse (SR) is disclosed. In one embodiment, the SCA initiator can transmit RCS frames by following the same procedure as the OBSS packet detection (PD) based spatial reuse operation illustrated in Figure 1700. The SCA initiator can measure the received signal strength (OBSS_PD) of the OBSS PPDU occupying the primary channel. level 1705. If (OBSS_PD) level )1705 in the range [OBSS_PD min ,OBSS_PD max Within this scope, the SCA initiator will proceed according to the following: Figure 17 The permissible OBSS_PD is illustrated in Figure 1700. level The transmit power adjustment rules for TX_PWR 1715 are used to adjust the transmit power of PPDUs carrying RCS frames (TX_PWR) 1710.

[0146] In one embodiment, the SCA initiator can satisfy all the conditions for OBSS PD spatial reuse (SR) operation before transmitting an RCS frame on the main channel. Transmission of the RCS frame on the main channel is similar to spatial reuse transmission, except that it does not include the transmission of data PPDUs by the SCA initiator on the main channel. In procedure 1700, the primary purpose of following the OBSS packet detection (PD) spatial reuse operation is for the SCA initiator to send an RCS frame to the SCA responder via the main channel (i.e., during a detected OBSS transmission) to initiate a handover to the anchor channel. Note that... Figure 17 The illustration shows an example transmit power adjustment in a normal OBSSPD-based space reuse operation as defined in 802.11ax, although other similar operations can be utilized.

[0147] Alternatively or additionally, in one embodiment, the SCA initiator may send RCS frames following the same procedure as a space reuse operation based on parameterized spatial reuse (PSR). The SCA initiator may satisfy all the conditions of the PSR space reuse operation before transmitting the RCS frame on the main channel. The transmission of the RCS frame on the main channel is similar to space reuse transmission, except that it does not include the transmission of data PPDUs by the SCA initiator on the main channel. In this process, the primary purpose of following the PSR space reuse operation is for the SCA initiator to send the RCS frame to the SCA responder to initiate a handover to the anchor channel.

[0148] In one embodiment, the parameters for OBSS group detection (PD)-based spatial reuse can be modified to relax the conditions required for OBSS PD spatial reuse operations. In one example, OBSS_PD max It can be increased to allow the SCA initiator to send RCS frames even in the event of a higher level of interference on the main channel.

[0149] In one embodiment, the parameters for PSR-based spatial reuse can be modified to relax the conditions required for PSR spatial reuse operations. In one example, the maximum Acceptable Receiver Intereffect Level... AP It can be increased to allow the SCA initiator to send RCS frames even in the event of a higher level of interference on the main channel.

[0150] In various embodiments, soft-preemptive SCA is used in conjunction with SR-type parameters. In one embodiment, an RCS frame may be transmitted on the primary 20MHz channel during an OBSS transmission. This transmission may interfere with ongoing transmissions on the primary channel within the OBSS. This transmission may follow spatial reuse operations, where certain conditions must be followed to protect ongoing OBSS transmissions on the primary channel. In another approach, the transmission may follow soft-preemptive operations as discussed in this section, where coordination with one or more transmitting STAs (AP or non-AP STAs) in the OBSS occupying the primary channel is not required.

[0151] In one embodiment, soft preemption in the above embodiments refers to transmitting a PPDU during an ongoing transmission without requiring a partial or complete halt to the ongoing transmission (this can be referred to as hard preemption). Soft preemption represents a short-term disruption to the OBSS and can be used to trigger one or more STAs to switch to the anchor channel.

[0152] In one embodiment, the transmit power of the PPDU containing the RCS frame in the previous embodiment can be calculated to minimize interference with ongoing transmissions in the OBSS, while maintaining a sufficient SINR (signal-to-interference-plus-noise ratio) level for the transmitted PPDU so that the receiving STA can successfully decode the PPDU.

[0153] In one approach, the SCA initiator adjusts the transmit power of the PPDU carrying the RCS frame according to Equation 1 below, so that the SCA responder can successfully receive the PPDU: (Equation 1) TX_PWR ref The Threshold value can be selected to trade off increasing the probability of successfully receiving a PPDU carrying an RCS frame and the amount of interference affecting OBSS transmission.

[0154] Note that the other parameters of the above equations can be defined in the normal space reuse operation of 11ax and / or 11be (see Figure 17 ).

[0155] In one embodiment, such as Figure 18 As illustrated in Figure 1800, a PPDU carrying an RCS / ITS frame (shown by line 1812, which is transmitted between SCA initiator 1815 and SCA responder 1830 in BSS 1810) may interfere with ongoing transmission 1862 in OBSS 1850 and may cause an interruption to the OBSS PPDU. Furthermore, OBSS PPDU 1862 may interfere with PPDU 1812 carrying an RCS / ITS frame, causing unsuccessful reception of that frame by SCA responder 1830. To guarantee successful reception of the RCS frame with limited impact on ongoing transmissions, a set of conditions is desired. Examples of these conditions may include one or any combination of the following conditions (1)-(5).

[0156] (1) The OBSS AP 1860 can indicate that soft preemption of its PPDU is allowed by setting a field (e.g., a new field called the Soft Preemption Allow Field) in the beacon frame 1870 or any other management, control, or action frame. Additionally or alternatively, the Soft Preemption Allow Field can be included in the UHR-SIG or UHR-USIG field of the OBSS PPDU 1862. The Soft Preemption Allow Field can be set to a value (such as 1) to indicate that soft preemption of the OBSS PPDU is allowed. The Soft Preemption Allow Field can be set to a value (such as 0) to indicate that soft preemption of the OBSS PPDU is not allowed.

[0157] (2) Additionally or alternatively, the OBSS AP may advertise a soft preemption period in which its PPDU is permitted to preempt soft preemption. The soft preemption period may be indicated in the beacon frame or may be negotiated using a coordination process.

[0158] (3) Additionally or alternatively, if soft preemption permission is set to 1, OBSS may indicate the maximum acceptable interference it can handle.

[0159] (4) The SCA initiator can measure the signal strength of the OBSS PPDU and identify whether the PPDU is an uplink or downlink PPDU. The SCA initiator can also measure the signal strength of the OBSS beacon frame to estimate the relative path loss of the OBSS AP. The SCA initiator can use these measurements to identify whether an ongoing transmission is being transmitted or received by the OBSS AP. The SCA initiator can use these measurements to determine the transmit power of the PPDU carrying the RCS frame and whether the interference caused by the transmission of the PPDU carrying the RCS frame is within acceptable limits.

[0160] (5) The SCA initiator may use the minimum MCS to transmit the RCS frame to increase the probability that the frame will be successfully received by the SCA responder 1830.

[0161] refer to Figure 19 An example method 1900 for SCA utilizing OBSS transmission gaps is illustrated. In method 1900, the BSS (OBSS AP 1910 in this scenario) may announce transmission gaps 1912 during certain periods of transmission of one or more PPDUs. These transmission gaps 1912 may be left blank, filled with one or more padding symbols, or used to transmit training fields, allowing the SCA initiator 1950 to transmit RCS 1955 during these gaps 1912 to initiate an SCA handover process as discussed in previous embodiments. These gaps 1912 may be announced in beacon frames, probe request / response frames, (re)association request / response frames, and / or any other management, control, or action frames that may be used to negotiate the availability of OBSS gaps 1912, which the BSS may use to send RCS 1955 and initiate SCA handover.

[0162] In one approach, OBSS 1910 may indicate that it allows the transmission of short PPDUs from other BSSs during these gaps by indicating this in the USIG or SIG fields.

[0163] RCS frames 1955 can be transmitted in different ways. In one example, it can be a dedicated null data packet (NDP), a MAC frame carried in a UHR PPDU or a non-UHR PPDU, an existing short MAC frame (e.g., a QoS null frame) carried in a UHR PPDU or a non-UHR PPDU, or a short new MAC frame carried in a UHR PPDU or a non-UHR PPDU. The different options for RCS frames will be discussed below.

[0164] In one approach, a handover to the anchor channel can be initiated by transmitting a special form of null data packet (NDP) (referred to as RCS-NDP). The NDP can be carried in an ultra-high reliability (UHR) PPDU or a non-UHR PPDU (e.g., EHT PPDU, HE PPDU, VHT PPDU, HT PPDU, or non-HT PPDU, or non-HT DUP PPDU). In one embodiment, the RCS-NDP can be transmitted on the main channel by the SCA initiator, and all STAs that can successfully receive it can switch to the anchor channel. In this approach, the SCA responder is not addressed in the RCS-NDP; the SCA responder is the STA that can successfully receive the RCS-NDP and switch to the anchor channel.

[0165] In one approach, the RCS frame can be a trigger frame addressed to a target SCA responder, carried in a UHR PPDU or a non-UHR PPDU, listing information about the SCA responder. In another example, the RCS frame can be a short frame addressed to a group of STAs identified by a group ID (e.g., Quality of Service (QoS) empty, RTS, empty, PS-Poll, etc.). In yet another example, the RCS frame can be a newly created short Media Access Control (MAC) frame addressed to a group of STAs identified by a group ID.

[0166] In one embodiment, the SCA initiator may use a Distributed Tone Resource Unit (DRU) to transmit a PPDU carrying an RCS frame, thereby minimizing interference with the OBSS PPDU. The SCA initiator may indicate the type of PPDU carrying the RCS frame in the UHR-SIG or UHR-USIG field.

[0167] UHR PPDU. In one embodiment, an SCA initiator can initiate a handover to the anchor channel by transmitting an RCS frame to one or more SCA responders in a UHR PPDU. The U-SIG field of the UHR PPDU may contain a field named "Switch to Anchor," as illustrated in Table 5. The "Switch to Anchor" field can be set to a value (such as 1) to indicate that one or more STAs addressed in the RCS frame should switch to the anchor channel.

[0168] Table 5: Exemplary illustration of the UHR U-SIG field In another approach, switching to the anchor field can be included in the common fields of the UHR-SIG field, as shown in Table 5.

[0169] In one embodiment, the SCA responder may fail to correctly decode the RCS frame addressed to itself, but the preamble carrying the RCS frame's PPDU can be successfully decoded, and the SCA responder can be aware of the switch to the anchor field indication. In this scenario, the SCA responder can switch to the anchor channel and wait on the anchor channel for an RTS, MU-RTS, or trigger frame addressed to itself. If the SCA responder does not receive an RTS, MU-RTS, or trigger frame addressed to itself on the anchor channel, it can switch back to the main channel.

[0170] In one embodiment, the UHR U-SIG field, UHR-SIG, or any other signaling field may contain a field (which may be named the anchor channel index). The anchor channel index may indicate a specific index of the anchor channel to be used in the switchover to the secondary phase. A list of available secondary channels to be used in this phase may be announced in beacon frames, probe request / response frames, (re)association request / response frames, and / or any other management, control, or action frames that may be used to negotiate the availability of secondary channels for performing the switchover to the secondary phase.

[0171] In one embodiment, an indication of which anchor channel can be used to perform the handover process can be transmitted from the MAC to the PHY via a PHY service interface (e.g., TXVECTOR).

[0172] In one embodiment, the CCS frame can be a short frame sent by the SCA responder on the anchor channel in a UHR PPDU or non-UHR PPDU to acknowledge successful handover. In another approach, the CCS can be sent on a dedicated resource unit allocated to each SCA responder and indicated in the user information field corresponding to each SCA responder in the RCS frame. The CCS can be a known frame, such as CTS, CTS-To-Self, etc., or a newly defined frame specific to this purpose.

[0173] An example of operation on the anchor channel is described. In one embodiment, the SCA initiator and SCA responder can negotiate the requirements for successful operation on the anchor channel. The SCA initiator can exchange parameters indicating the relative handover time required to switch to the anchor channel, ensuring that the SCA responders can switch relatively simultaneously in order to achieve successful synchronization on the anchor channel.

[0174] In one embodiment, the SCA initiator may transmit a synchronization frame on the anchor channel to synchronize with the SCA responder. The synchronization frame may be a basic trigger frame, a Buffer Status Report Polling (BSRP) trigger frame, a Bandwidth Query Report Polling (BQRP) trigger frame, a polling trigger frame, a Null Data Packet Feedback Report Polling (NFRP) trigger frame, an RTS, a Multi-User (MU)-RTS, or any other frame.

[0175] refer to Figure 20 An example method 2000 for soft preemption for secondary channel access (i.e., using multiple anchor channels) is illustrated. In dense environments where multiple OBSSs or even other technologies operate simultaneously across unlicensed spectrum, the first secondary channel (or anchor channel) may still be found busy after switching according to the various methods described previously. In some scenarios, to meet low-latency requirements, the SCA initiator may need to subsequently switch to a second secondary channel, and if the second secondary channel is still busy, this process can be repeated until a more accessible secondary channel is found or the SCA TXOP on the primary channel has expired.

[0176] The SCA initiator / responder's BSS can maintain a list of multiple potential secondary channels to switch to. This list can be generated by factors such as the priority of the technical user on a given channel, the operating bandwidth capabilities of the AP and STA, and polling from the AP and STA based on their past observations of channel conditions on the secondary channels (including but not limited to interference intensity and frequency, maximum permissible transmit power, and Received Signal Strength Indicator (RSSI) measurements). The secondary channels in the list can be sorted and indexed according to the aforementioned factors. In one approach, the SCA initiator can randomly select a secondary channel from the list for switching; in another approach, the SCA initiator can switch secondary channels one at a time according to the sorting and indexing of the list until a more accessible secondary channel is found.

[0177] like Figure 20As illustrated, method 2000 begins on a first BSS channel, for example, in a primary channel occupied by OBSS1 transmissions. SCA initiator 2010 can initiate a handover to a secondary channel by sending a Handover Indication (ITS) / Request for Channel Switching (RCS) frame 2012 (e.g., in primary channel 2001, which may be a UHR PPDU carrying an RTS frame, MU-RTS frame, or any other frame addressed to one or more SCA responders 2020). SCA initiator 2010 and (one or more) SCA responders 2020 can switch 2014 to a second BSS channel, for example, a first secondary channel 2002. SCA initiator 2010 can perform a Full Clear Channel Assessment (CCA) in the first secondary channel 2002. As previously described, a full CCA can include a physical CCA 3026 via a listening channel and a virtual CCA by sending another RTS / MU-RTS on the first secondary channel and waiting for a CTS response from (one or more) SCA responders. If one or more SCA responders send back a CCS / CTS response, this situation and subsequent procedures have been previously described.

[0178] If the SCA initiator 2010 detects through physical CCA 2016 that the first auxiliary channel 2002 is also occupied, then... Figure 20 As shown, the SCA initiator 2010 can initiate a handover process to a third BSS channel (e.g., the second auxiliary channel 2003) by sending another RCS 2018 to one or more SCA responders 2020. The SCA initiator and one or more SCA responders can then switch to the second auxiliary channel 2003. Alternatively, if the SCA initiator detects that the first auxiliary channel is idle, such as... Figure 21 As illustrated in the diagram, the SCA initiator may have several options depending on whether all or some of the SCA responders send back a CTS response during the virtual CCA process. In one approach, if the SCA initiator cannot identify which SCA responders responded with CTS, but does know that some of them did respond, the SCA initiator 2010 can continue transmitting and receiving on the secondary channel as if all SCA responders had responded.

[0179] refer to Figure 21In another method 2100, the SCA initiator can identify which SCA responders responded with CCS / CTS, and then the SCA initiator can continue transmission and reception on the secondary channel with a subset of the SCA responders who responded with CCS / CTS. In yet another method, the SCA initiator can determine that not all SCA responders sent back CCS / CTS 2125 or no SCA responders sent back CCS / CTS, and then it immediately sends another RCS frame 2118 to indicate the next channel switch to the second secondary channel, such as... Figure 21 The diagram is shown in the image. Then, both the SCA initiator and (one or more) responders again perform the same full CCA procedure described above on the second secondary channel. If the CCA is not idle or in some partially idle scenarios as described above, the SCA initiator can initiate another handover to the fourth BSS channel (e.g., another secondary channel) by repeating the handover procedure described above. The handover procedure can stop when the SCA TXOP in the primary channel has expired, or it can continue until an available secondary channel is found, regardless of the duration of the SCA TXOP in the primary channel.

[0180] In one approach, the SCA initiator can initiate a handover to a secondary channel by transmitting an RCS frame in a UHR PPDU to one or more SCA responders. The U-SIG (or UHR-SIG) field of the UHR PPDU can contain a field called Secondary Channel Information, as illustrated in Table 6 below. The Secondary Channel Information field can be set to a multi-bit value to indicate whether one or more STAs addressed in the RCS frame should handover to a secondary channel, and if so, which secondary channel. Alternatively, the Secondary Channel Information field can contain only a single-bit hold or handover indicator; in the latter case, all APs and STAs automatically handover to the next secondary channel in the list of potential secondary channels.

[0181] Table 6: Exemplary illustration of UHR U-SIG field for multiple auxiliary channels Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and Digital Universal Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for a station (STA), the method comprising: Communicate with the target STA on the first channel of the Basic Service Set (BSS); It is determined that the first channel is busy due to the first overlapping BSS (OBSS) STA transmission; A change to the second channel of the BSS is initiated by sending a channel switching instruction to the target STA on the first channel; Send a message requesting confirmation of the channel change to the target STA on the second channel; In response to sending a message requesting confirmation of the channel change, an indication confirming the channel change is received from the target STA on the second channel; Sending or receiving one or more BSS physical layer protocol data units (PPDUs) to or from the target STA that confirms the channel change; and After a period of time, it switches back to the first channel.

2. The method of claim 1, wherein before sending or receiving one or more BSS PPDUs, the method further comprises: It was determined that the second channel was busy due to the second OBSS STA transmission; A change to the third channel of the BSS is initiated by sending a channel switching instruction to the target STA on the second channel; Send a message requesting confirmation of the channel change to the target STA on the third channel; as well as In response to sending a message requesting confirmation of the channel change, an indication of confirmation of the channel change is received from the target STA on the third channel.

3. The method according to claim 2, wherein the first channel is the primary BSS channel, the second channel is the first auxiliary BSS channel, and the third channel is the second auxiliary BSS channel.

4. The method according to any one of claims 1-3, wherein the indication for switching channels includes a request for channel switching (RCS) frame addressed to a plurality of target STAs carried in an ultra-high reliability (UHR) PPDU.

5. The method according to any one of claims 1-4, wherein the message requesting confirmation of a channel change includes one of the following: a request to transmit (RTS) frame or a trigger frame.

6. The method according to any one of claims 1-4, wherein the message requesting confirmation of a channel change includes a polling trigger frame or a null data packet feedback report polling (NFRP).

7. The method according to any one of claims 1-6, wherein the indication of acknowledging a channel change includes one of the following: Clear Transmission (CTS), CTS to Self (CTSTS), Null Data Packet Feedback Report (NFR), or Channel Acknowledgment Switching (CCS) message.

8. The method according to any one of claims 1-7, wherein the time period includes one of the following: Supplementary Channel Access Transmission Opportunity (SCA TXOP), the time for sending or receiving an acknowledgment (ACK) to one or more BSS PPDUs after the SCA TXOP, or a time shorter than the SCA TXOP for monitoring the first channel until the first channel is not busy.

9. The method according to any one of claims 1-8, wherein before transmitting the indication for switching channels, the method further comprises: Negotiate one or more service periods or availability windows with the target STA, during which the target STA can expect to receive an instruction to switch channels.

10. The method according to any one of claims 1-8, wherein the STA includes an access point (AP), and wherein the target STA includes a non-AP STA.

11. A station (STA), comprising: transceiver; as well as A processor, communicatively coupled to a transceiver, wherein the transceiver and the processor are configured to: Communicate with the target STA on the first channel of the Basic Service Set (BSS); It is determined that the first channel is busy due to the first overlapping BSS (OBSS) STA transmission; A change to the second channel of the BSS is initiated by sending a channel switching instruction to the target STA on the first channel; Send a message requesting confirmation of the channel change to the target STA on the second channel; In response to sending a message requesting confirmation of the channel change, an indication confirming the channel change is received from the target STA on the second channel; Sending or receiving one or more BSS physical layer protocol data units (PPDUs) to or from the target STA that confirms the channel change; and After a period of time, it switches back to the first channel.

12. The STA of claim 11, wherein the transceiver and processor are further configured to: prior to transmitting or receiving one or more BSS PPDUs. It was determined that the second channel was busy due to the second OBSS STA transmission; A change to the third channel of the BSS is initiated by sending a channel switching instruction to the target STA on the second channel; Send a message requesting confirmation of the channel change to the target STA on the third channel; and In response to sending a message requesting confirmation of the channel change, an indication of confirmation of the channel change is received from the target STA on the third channel.

13. The STA according to claim 12, wherein the first channel is a primary BSS channel, the second channel is a first auxiliary BSS channel, and the third channel is a second auxiliary BSS channel.

14. The STA according to any one of claims 11-13, wherein the indication for switching channels includes a request for channel switching (RCS) frame addressed to a plurality of target STAs carried in an ultra-high reliability (UHR) PPDU.

15. The STA according to any one of claims 11-14, wherein the message requesting confirmation of a channel change includes one of the following: a request to transmit (RTS) frame or a trigger frame.

16. The STA according to any one of claims 11-14, wherein the message requesting confirmation of a channel change includes a polling trigger frame or a null data packet feedback report polling (NFRP).

17. The STA according to any one of claims 11-16, wherein the indication of acknowledging a channel change includes one of the following: Clear Transmission (CTS), CTS to Self (CTSTS), Null Data Packet Feedback Report (NFR), or Channel Acknowledgment Switching (CCS) message.

18. The STA according to any one of claims 11-17, wherein the time period includes one of the following: a secondary channel access transmission opportunity (SCA TXOP), the time for sending or receiving an acknowledgment (ACK) to one or more BSSPPDUs after the SCA TXOP, or a time shorter than the SCA TXOP for monitoring the first channel until the first channel is not busy.

19. The STA according to any one of claims 11-18, wherein the transceiver and processor are further configured to: Negotiate one or more service periods or availability windows with the target STA, during which the target STA can expect to receive an instruction to switch channels.

20. The STA according to any one of claims 11-19, wherein the STA includes an access point (AP), and wherein the target STA includes a non-AP STA.

Images