Coordinated beamforming sounding exchange framework

Abstract

The invention relates to a coordinated beamforming sounding switching framework. A method for performing coordinated beamforming sounding in a wireless local area network is described. A first access point wireless device may transmit an initial control frame to a second access point wireless device, the initial control frame initiating a transmission opportunity for coordinating beamforming sounding. The initial control frame may include an indication of a first duration configured to determine a network allocation vector. An initial control response may be received from the second access point wireless device, the initial control response including an indication of a second duration configured to determine the network allocation vector. The second duration may be derived from the first duration, for example, such that the same network allocation vector may be derived from the indication of the first duration as derived from the indication of the second duration.

Description

Technical Field

[0001] This application relates to wireless communications, including techniques and devices for effectively coordinating beamforming and spatial multiplexing in wireless local area network architectures. Background Technology

[0002] Wireless communication systems are ubiquitous. Furthermore, wireless communication technology has evolved from solely voice communication to also include the transmission of data such as the internet and multimedia content.

[0003] Mobile electronic devices or stations (STAs) or user equipment (UEs) may take the form of smartphones or tablets typically carried by users. One aspect of wireless communication, typically performed by mobile devices, may include wireless networking, for example, via a wireless local area network (WLAN), which may include devices operating according to one or more communication standards in the IEEE 802.11 family of standards. As the deployment of such wireless networks becomes increasingly dense, the likelihood of interference from nearby networks affecting the efficiency of such communications also increases. Therefore, improvements in this area are expected. Summary of the Invention

[0004] This paper presents several implementation schemes, including systems, apparatuses, and methods for devices to efficiently perform coordinated beamforming (CBF) detection and data operations, as well as coordinated spatial multiplexing operations, in a wireless local area network architecture.

[0005] A wireless device may include: one or more antennas; one or more radio components operatively coupled to the one or more antennas; and a processor operatively coupled to the one or more radio components. The wireless device may be configured to establish a connection with an access point via a wireless local area network (WLAN) on one or more wireless links, or may be an access point configured to establish a connection with one or more other wireless devices via a WLAN on one or more wireless links. In some embodiments, the wireless device may operate in each of the plurality of wireless links using a corresponding radio component from the one or more radio components.

[0006] This document describes various techniques used during the CBF probe phase, based on several implementation schemes. These techniques may include those for providing Network Assignment Vector (NAV) protection and those for reporting probe failures and recovering from them. This document also describes techniques for providing STAs with an option to exit CBF, as well as techniques for setting preambles for probe null data packets (NDP) and beamforming reports (BFR) to accommodate situations involving multiple access points and associated sites with different basic service set identification information during CBF probes.

[0007] According to some implementation schemes, this document also describes techniques used during the CBF data phase. These techniques may include multiple possible CBF data frame exchange sequences, which may include the use of interleaved initial control frame and initial control response structures or multi-user initial control frame and initial control response structures. This document describes various technical details for such CBF data frame exchange sequences, including handling enhanced multi-link single radio state machine operation, NAV setup, fault recovery, acknowledgment procedures, and security. This document also describes possible CBF physical layer protocol data unit alignment techniques.

[0008] It should also be noted that at least some of the techniques described herein can also be applied, or alternatively, to other multi-AP schemes, such as coordinated spatial multiplexing, joint transmission, etc.

[0009] The technologies described herein can be implemented in and / or used with a variety of different types of devices, including but not limited to cellular phones, tablet computers, accessory and / or wearable computing devices, portable media players, base stations, access points and other network infrastructure equipment, servers, unmanned aerial vehicles, unmanned aerial controllers, automobiles and / or motor vehicles, and any computing device in various other computing devices.

[0010] The present invention is intended to provide a brief overview of some of the subjects described in this document. Therefore, it should be understood that the above features are merely illustrative and should not be construed as narrowing the scope or substance of the subjects described herein in any way. Other features, aspects, and advantages of the subjects described herein will become apparent from the following detailed description, drawings, and claims. Attached Figure Description

[0011] A better understanding of the subject matter can be obtained by considering the following specific description of the implementation scheme in conjunction with the accompanying drawings.

[0012] Figure 1 Example wireless communication systems including wireless devices are illustrated according to some implementation schemes;

[0013] Figure 2 This is a block diagram illustrating an example wireless device according to some implementation schemes;

[0014] Figure 3 This is a block diagram illustrating example network elements or access points according to some implementation schemes;

[0015] Figure 4 This is a block diagram illustrating an example modem or baseband processor according to some implementation schemes;

[0016] Figure 5This is a flowchart illustrating an example method for performing coordinated beamforming (CBF) detection in a wireless local area network according to some implementation schemes;

[0017] Figure 6 This is a flowchart illustrating an example method for performing CBF data frame switching in a wireless local area network according to some implementation schemes;

[0018] Figure 7 Example aspects of possible systems that can implement CBF according to some implementation schemes are illustrated;

[0019] Figure 8 Example timelines are illustrated according to some implementation schemes in which CBF detection and subsequent CBF data frame transmission may occur;

[0020] Figure 9 Two example timelines for processing CBF detection timing are illustrated according to some implementation schemes;

[0021] Figure 10 Examples of scenarios in which hidden node interference can affect CBF detection operations are illustrated according to some implementation schemes;

[0022] Figures 11 to 12 Example aspects of possible joint methods for CBF detection operations according to some implementation schemes are illustrated;

[0023] Figure 13 Example aspects of possible sequential methods for CBF probing operations according to some implementation schemes are illustrated;

[0024] Figure 14 Examples of various possible fault handling methods for CBF detection according to some implementation schemes are illustrated;

[0025] Figure 15 This is a timing diagram illustrating an example aspect of a possible frame switching sequence for CBF data frame switching according to some implementation schemes;

[0026] Figure 16 This is a timing diagram illustrating an example aspect of another possible frame switching sequence for CBF data frame switching according to some implementation schemes;

[0027] Figure 17 This is a timing diagram illustrating an example aspect of another possible frame switching sequence for CBF data frame switching according to some implementation schemes;

[0028] Figure 18 This is a timing diagram illustrating an example aspect of another possible frame switching sequence for CBF data frame switching according to some implementation schemes;

[0029] Figures 19 to 21 This is a timing diagram illustrating example aspects of possible frame switching sequences for coordinating spatial multiplexing (C-SR) data frame switching according to some implementation schemes;

[0030] Figures 22 to 23 Example aspects of possible network allocation vector processing methods for CBF data frame exchange sequences are illustrated according to some implementation schemes;

[0031] Figure 24 Example aspects of possible block acknowledgment scheduling methods for CBF data frame exchange sequences according to some implementation schemes are illustrated;

[0032] Figure 25 Example aspects of possible CBF data frame exchange sequences, including physical layer preambles for alignment of CBF data frames, are illustrated according to some implementation schemes.

[0033] Figure 26 Example aspects of possible scenarios according to some implementation schemes are illustrated, in which one or more special radio device identifiers can be defined and assigned for CBF data frame exchange;

[0034] Figure 27 Example aspects of possible scenarios according to some implementation schemes are illustrated, in which the allocation of resource units in physical layer signaling is extended to be based on the basic service set color code and site identifier for CBF data frame exchange;

[0035] Figure 28 Example aspects of possible scenarios according to some implementation schemes are illustrated, wherein in physical layer signaling for CBF data frame switching, a first content channel may carry a resource element allocation of a basic service set, and a second content channel may carry a resource element allocation of another basic service set.

[0036] Figure 29 Examples of implementation schemes available for use are shown. Figures 27 to 28 Further details of the possible physical layer signaling formats for one or more of the methods;

[0037] Figures 30 to 31 Example aspects of possible physical layer signaling formatting methods for the U-SIG1 and UHR-SIG common fields transmitted by non-orthogonal frequency division multiple access (CBF) according to some implementation schemes are illustrated;

[0038] Figure 32 Aspects of possible CBF physical layer signaling format methods according to some implementation schemes are illustrated, wherein basic service set color codes can be signaled to two access points;

[0039] Figure 33Examples of possible physical layer signaling formatting methods, according to some implementation schemes, that can be used to distinguish user fields from different access points, such as those for combining... Figure 27 Example methods used;

[0040] Figure 34 Examples of possible scenarios for transmitting partial bandwidth CBF data frames according to some implementation schemes are illustrated;

[0041] Figure 35 Examples of possible UHR-SIG user fields for orthogonal frequency division multiple access transmission for partial bandwidth CBF operation according to some implementation schemes;

[0042] Figure 36 Examples of possible U-SIG format implementations according to some schemes are illustrated, wherein the Physical Layer Protocol Data Unit (PLD Data Unit) type field can indicate a full-bandwidth CBF PLD Data Unit or a partial-bandwidth CBF PLD Data Unit; and

[0043] Figure 37 An aspect of the possible UHR SIG common field format according to some implementation schemes is illustrated, in which the Partial Bandwidth CBF field can be used to indicate the Partial Bandwidth CBF physical layer protocol data unit.

[0044] While the features described herein are susceptible to various modifications and alternatives, specific embodiments thereof are shown by way of example in the accompanying drawings and described in detail herein. However, it should be understood that the drawings and their detailed description are not intended to limit one to the specific forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the subject matter as defined by the appended claims. Detailed Implementation

[0045] the term

[0046] The following are definitions of the terms used in this disclosure:

[0047] Memory media—any of various types of non-transitory memory devices or storage devices. The term "memory media" is intended to include any computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDORAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, e.g., hard disk drives or optical storage devices; registers or other similar types of memory elements, etc. The term "memory media" may include two or more memory media that may reside in different locations (e.g., different computer systems connected via a network). Memory media may store program instructions (e.g., embodied in a computer program) that can be executed by one or more processors.

[0048] Carrier medium—such as memory media as described above, and physical transmission medium, such as buses, networks and / or other physical transmission media that transmit signals (such as electrical signals, electromagnetic signals or digital signals).

[0049] Computer system—any of all types of computing or processing systems, including personal computer systems (PCs), server-based computer systems, wearable computers, networked appliances, internet-connected appliances, smartphones, television systems, grid computing systems, or other devices or combinations of devices. In general, the term "computer system" can be broadly defined to encompass any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0050] User equipment (UE) (or “UE device”) — any of various types of computer systems or devices that are mobile or portable and perform wireless communication. Examples of UE devices include mobile phones or smartphones (e.g., iPhone-based). ™ Android ™ This includes mobile phones, tablet computers, portable gaming devices, laptops, wearable devices (e.g., smartwatches, smart glasses, smart goggles, head-mounted displays, etc.), portable internet devices, music players, data storage devices or other handheld devices, automobiles and / or motor vehicles, unmanned aerial vehicles (UAVs) (e.g., drones), UAV controllers (UACs), etc. Generally speaking, the term "UE" or "UE device" can be broadly defined to encompass any electronic device, computing device, and / or telecommunications device (or a combination of these devices) that is easily transportable by the user and capable of wireless communication.

[0051] A wireless device or station (STA) is any of various types of computer systems or devices that perform wireless communication. A wireless device can be portable (or mobile), or it can be stationary or fixed in a location. The terms "station" and "STA" are used similarly. A UE is an example of a wireless device.

[0052] A communication device is any of various types of computer systems or devices that perform communication, which may be wired or wireless. A communication device may be portable (or mobile), or it may be stationary or fixed in a location. A wireless device is one example of a communication device. A UE is another example of a communication device.

[0053] Base station or access point (AP) — The term “base station” has the full breadth of its common meaning and includes at least a wireless communication station installed in a fixed location for communication as part of a wireless communication system. The term “access point” (or “AP”) is often associated with and used similarly to Wi-Fi-based communication.

[0054] A processing element (or processor) is a variety of elements or combinations of elements capable of performing functions in a device (e.g., a communication device or a network infrastructure device). A processor may include, for example: a processor and associated memory, circuitry such as an ASIC (Application-Specific Integrated Circuit), portions or circuitry of individual processor cores, an entire processor core, a processor array, programmable hardware devices such as a field-programmable gate array (FPGA), and / or a large portion of a system comprising multiple processors, as well as any combination of the above elements.

[0055] IEEE 802.11 refers to technologies based on the IEEE 802.11 wireless standard (such as 802.11a, 802.11b, 802.11g, 802.11n, 802.11-2012, 802.11ac, 802.11ad, 802.11ax, 802.11ay, 802.11be, and / or other IEEE 802.11 standards). IEEE 802.11 technology can also be referred to as "Wi-Fi" or "Wireless Local Area Network (WLAN)" technology.

[0056] "Configured as"—Various components can be described as being "configured as" to perform one or more tasks. In this context, "configured as" is a broad expression generally meaning "having" a "structure" that performs one or more tasks during operation. Therefore, a component can be configured to perform a task even when it is not currently performing one (e.g., a set of electrical conductors can be configured to electrically connect one module to another, even when the two modules are not connected). In some contexts, "configured as" can be a broad expression generally meaning a structure that "has" a "circuit" that performs one or more tasks during operation. Therefore, a component can be configured to perform a task even when it is not currently powered on. Generally, the circuit forming the structure corresponding to "configured as" can include hardware circuitry.

[0057] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". Statements describing a component as configured to perform one or more tasks are explicitly intended not to invoke the interpretation of 35 USC § 112(f) for that component.

[0058] Figures 1 to 2 —Wireless communication system

[0059] Figure 1 An example of a wireless communication system is shown. Note that... Figure 1 This represents one of many possibilities, and the features of this disclosure can be implemented as needed through any of various systems. For example, the situation described herein can be implemented in any type of wireless device. The wireless communication system described below is an example.

[0060] As shown in the figure, an exemplary wireless communication system includes an access point (AP) 102 that communicates with one or more wireless devices 106A, 106B, etc., via a transmission medium. Wireless devices 106A and 106B can be user equipment, such as a station (STA), a non-AP STA, a UE, or other WLAN devices.

[0061] STA 106 may be a device with wireless network connectivity, such as a mobile phone, handheld device, wearable device (e.g., such as a smartwatch, smart glasses, and / or head-mounted display), computer or tablet, unmanned aerial vehicle (UAV), unmanned aerial controller (UAC), automobile, or virtually any other type of wireless device. STA 106 may include a processor (processing element) configured to execute program instructions stored in memory. STA 106 may perform any of the methods described herein by executing one or more of such stored instructions. Alternatively or in addition, STA 106 may include programmable hardware elements such as FPGAs (Field-Programmable Gate Arrays), integrated circuits (e.g., ASICs), programmable logic devices (PLDs), and / or any of various other possible hardware components configured to perform (e.g., individually or in combination) any of the methods described herein or any portion thereof.

[0062] AP 102 can be a standalone AP or an enterprise AP, a transceiver base station (BTS) or a cell site, and may include hardware enabling wireless communication with STA devices 106A and 106B. AP 102 may also be equipped to communicate with network 100 (e.g., the core network of a service provider (e.g., a cellular service provider, internet service provider, and / or operator), a WLAN, an enterprise network, and / or another communication network connected to the internet, and various other possibilities). Therefore, AP 102 facilitates communication between STA devices 106 and / or communication between STA devices 106 and network 100. AP 102 can be configured to provide communication via one or more wireless technologies, such as any, any combination of, and / or all of the following: 802.11 a, 802.11 b, 802.11 g, 802.11 n, 802.11 ac, 802.11 ad, 802.11 ax, 802.11 ay, 802.11 be, and / or other 802.11 versions, and / or cellular protocols such as 6G, 5G, or LTE, including in unlicensed frequency bands.

[0063] The communication area (or coverage area) of AP 102 may be referred to as the Basic Service Area (BSA) or cell. AP 102 and STA 106 can be configured to communicate via a transmission medium using any of a variety of radio access technologies (RAT) or wireless communication technologies such as Wi-Fi, LTE, Advanced LTE (LTE-A), 5G NR, 6G, Ultra Wideband (UWB), etc.

[0064] Therefore, AP 102 and other similar access points (not shown) operating according to one or more wireless communication technologies can be configured as a network that can provide continuous or nearly continuous overlapping services to STA devices 106A to 106B and similar devices within a geographical area, for example, via one or more communication technologies. STAs can roam directly from one AP to another, or can switch between APs and / or network cells (e.g., cellular network cells).

[0065] It should be noted that, at least in some cases, the STA device 106 can communicate using any of a variety of wireless communication technologies. For example, the STA device 106 can be configured to communicate using Wi-Fi, LTE, LTE-A, 5G NR, 6G, Bluetooth, UWB, one or more satellite systems, etc. Other combinations of wireless communication technologies (including more than two wireless communication technologies) are also possible. Similarly, in some cases, the STA device 106 can be configured to communicate using only a single wireless communication technology.

[0066] As shown in the figure, the exemplary wireless communication system may also include an access point (AP) 104 that communicates with the wireless device 106B via a transmission medium. AP 104 also provides a communication connection to network 100. Therefore, a wireless device can connect to either or both of AP 102 (or another cellular base station) and access point 104 (or another access point) to access network 100. For example, a STA may roam from AP 102 to AP 104 based on one or more factors such as mobility, coverage, interference, and / or capability. It should be noted that AP 104 may also allow access to networks different from those allowed by AP 102 (e.g., enterprise Wi-Fi networks, home Wi-Fi networks, etc.).

[0067] STA 106A and STA 106B may include handheld devices (such as smartphones or tablets), wearable devices (such as smartwatches, smart glasses, head-mounted displays), and / or may include any device of various types with wireless communication capabilities. For example, one or more of STA 106A and / or STA 106B may be wireless devices designed for fixed or nomadic deployments, such as home appliances, measuring devices / sensors, control devices, etc.

[0068] STA 106B can also be configured to communicate with STA 106A. For example, STA 106A and STA 106B may be able to perform direct device-to-device (D2D) communication. It should be noted that such direct communication between STAs may also be referred to as, or alternatively as, peer-to-peer (P2P) communication. Direct communication may be supported by AP 102 (e.g., AP 102 may facilitate discovery, and various possible forms of assistance), or may be performed in a manner not supported by AP 102. According to various examples, such P2P communication may be performed using any of the following direct communication technologies: 3GPP-based D2D communication technology, Wi-Fi-based P2P communication technology, UWB, BT, and / or various other direct communication technologies.

[0069] STA 106 may include one or more devices or integrated circuits for facilitating wireless communication, potentially including Wi-Fi modems, cellular modems, and / or one or more other wireless modems. The wireless modem may include one or more processors (processor elements) and various hardware components as described herein. STA 106 may perform any method (or any part thereof) of the methods described herein by executing instructions on one or more programmable processors. For example, STA 106 may be configured to perform techniques such as those for effectively coordinating beamforming detection and data manipulation in a wireless communication system according to the various methods described herein. Alternatively or otherwise, the one or more processors may be one or more programmable hardware elements, such as FPGAs (Field-Programmable Gate Arrays), Application-Specific Integrated Circuits (ASICs), or other circuitry configured to perform any method or any part thereof of the methods described herein. The wireless modem described herein may be used in STA devices as defined herein, wireless devices as defined herein, or communication devices as defined herein. The wireless modem described herein may also be used in APs, base stations, picocells, femtocells, and / or other similar network-side devices.

[0070] STA 106 may include one or more antennas for communicating using two or more wireless communication protocols or radio access technologies (RATs). In some cases, STA device 106 may be configured to communicate using a single shared radio component. The shared radio component may be coupled to a single antenna or to multiple antennas (e.g., for MIMO) for performing wireless communication. Alternatively, STA device 106 may include two or more radio components, each of which may be configured to communicate via a corresponding wireless link. Other configurations are also possible.

[0071] Figure 2 –Example block diagram of STA device

[0072] Figure 2An example block diagram of a STA device (such as STA 106) is illustrated. In some cases, STA 106 may additionally or alternatively be referred to as UE 106. STA 106 may also be referred to as a non-AP STA 106. As shown, STA 106 may include a System-on-Chip (SOC) 200, which may include one or more parts configured for various purposes. Some or all of the various illustrated components (and / or other device components not illustrated, e.g., in variant and alternative arrangements) may be “communically coupled” or “operationally coupled”, terms used herein to refer to components that can communicate directly or indirectly when the device is in operation.

[0073] In some cases, the STA 106 can be configured as a multi-link device (MLD). In such cases, the STA 106 (e.g., one or more radio components of the STA 106) can be configured to perform concurrent data transmission and reception across a single frequency band and / or multiple frequency bands (e.g., such as the 2.4 GHz band, the 5 GHz band, and / or the 6 GHz band) on multiple channels. Therefore, the STA 106 (e.g., one or more radio components of the STA 106) can be configured to perform multi-link operation (MLO). For example, the STA 106 (e.g., one or more radio components of the STA 106) can be configured to perform simultaneous transmit and receive (STR) operation (e.g., configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operation (e.g., configured such that a single radio component can simultaneously listen to two or more links).

[0074] As shown, the SOC 200 may include: a processor 202 that executes program instructions for the STA 106; and display circuitry 204 that performs graphics processing and provides display signals to the display 260. The SOC 200 may also include motion sensing circuitry 270, which may use, for example, any motion sensing component such as a gyroscope, accelerometer, and / or various other motion sensing components to detect motion of the STA 106 in one or more dimensions. The processor 202 may also be coupled to a memory management unit (MMU) 240, which may be configured to receive addresses from the processor 202 and translate these addresses into locations in memory (e.g., memory 206, read-only memory (ROM) 250, flash memory 210). The MMU 240 may be configured to perform memory protection and page table translation or setup. In some cases, the MMU 240 may be included as part of the processor 202.

[0075] As shown in the figure, SOC 200 can be coupled to various other circuits of STA 106. For example, STA 106 may include various types of memory (e.g., including NAND flash memory 210), connector interface 220 (e.g., for coupling to computer systems, docking stations, charging stations, etc.), display 260, and wireless communication circuitry 230 (e.g., for LTE, LTE-A, 5G NR, 6G, Bluetooth, Wi-Fi, NFC, GPS, UWB, peer-to-peer (P2P), device-to-device (D2D), etc.).

[0076] STA 106 may include at least one antenna, and in some cases may include multiple antennas, such as 235A and 235B, for performing wireless communication with access points, base stations, wireless stations, and / or other devices. For example, STA 106 may use antennas 235A and 235B to perform wireless communication. As noted above, STA 106 may be configured in some examples to perform wireless communication using a variety of wireless communication standards or radio access technologies (RATs).

[0077] The wireless communication circuitry 230 may include a Wi-Fi modem 232, a cellular modem 234, and a Bluetooth modem 236. It should be noted that one or more of the Wi-Fi modem 232, cellular modem 234, and / or Bluetooth modem 236 may be configured for MLO, for example, as described above. The Wi-Fi modem 232 enables STA 106 to perform Wi-Fi or other WLAN communications, for example, on an 802.11 network. The Bluetooth modem 236 enables STA 106 to perform Bluetooth communications. The cellular modem 234 may be able to perform cellular communications according to one or more cellular communication technologies, for example, according to one or more 3GPP specifications.

[0078] As described herein, STA 106 may include hardware and software components for implementing aspects of this disclosure. For example, one or more components of the wireless communication circuitry 230 of STA 106 (e.g., Wi-Fi modem 232, cellular modem 234, BT modem 236) may be configured, for example, to implement part or all of the methods described herein for efficiently coordinating beamforming detection and data manipulation in a wireless communication system by means of a processor executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), a processor configured as an FPGA (Field Programmable Gate Array), and / or using dedicated hardware components that may include ASICs (Application-Specific Integrated Circuits).

[0079] Figure 3 —Block diagram of the access point

[0080] Figure 3 An example block diagram of Access Point (AP) 104 is shown. In some cases (e.g., in an 802.11 communication context), AP 104 may also be referred to as a Station (STA), and may be more specifically referred to as an AP STA. Note that... Figure 3 The AP is merely one example of a possible access point. As shown, AP 104 may include a processor 304 capable of executing program instructions for AP 104. Processor 304 may also be coupled to a memory management unit (MMU) 340, which may be configured to receive addresses from processor 304 and translate these addresses into locations in memory (e.g., memory 360 and read-only memory (ROM) 350), or into other circuitry or devices.

[0081] In some cases, AP 104 can be configured as a multi-link device (MLD). In such cases, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform concurrent data transmission and reception across a single frequency band and / or multiple frequency bands (e.g., such as the 2.4 GHz band, the 5 GHz band, and / or the 6 GHz band) on multiple channels. Therefore, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform multi-link operation (MLO). For example, AP 104 (e.g., one or more radio components of AP 104) can be configured to perform simultaneous transmit and receive (STR) operation (e.g., configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operation (e.g., configured such that a single radio component can be used to simultaneously listen on two or more links).

[0082] AP 104 may include at least one network port 370. Network port 370 may be configured to be coupled to a network and provide network access to multiple devices such as STA device 106, as described above in this document. Figure 1 As described in the text.

[0083] Network port 370 (or an additional network port) may also be configured, or alternatively configured, to be coupled to a cellular network, such as the core network of a cellular service provider (e.g., an operator and / or cellular carrier). The core network may provide mobility-related services and / or other services to multiple devices, such as STA device 106. In some cases, network port 370 may be coupled to a telephone network via the core network, and / or the core network may provide a telephone network (e.g., in other STA devices served by a cellular service provider).

[0084] AP 104 may include one or more radio components 330A-330N and at least one antenna 334 (and may include multiple antennas), which may be coupled to one or more corresponding communication links. Antenna 334 may be configured to operate as a wireless transceiver in conjunction with one or more other components, and may also be configured to communicate with STA device 106 via radio components 330A-330N. Note that one or more of the radio components 330A-330N may be configured for MLO, for example, as described above. Antennas 334A-N communicate with one or more corresponding radio components 330A-N via communication links 332A-N. Communication link 332 may be a receive link, a transmit link, or both. Radio components 330A-N may be configured to communicate according to various wireless communication standards, including but not limited to LTE, LTE-A, 5G NR, 6G, UWB, Wi-Fi, BT, etc. AP 104 may be configured to operate on multiple wireless links using one or more radio components 330A-N. In some implementations, each radio component can be used to operate on the corresponding wireless link.

[0085] AP 104 can be configured to perform wireless communication using multiple wireless communication standards. In some cases, AP 104 may include multiple radio components that enable network entities to communicate according to various wireless communication technologies. For example, as one possibility, AP 104 may include 4G or 5G radio components for performing communication according to 3GPP wireless communication technologies, and Wi-Fi radio components for performing communication according to one or more Wi-Fi specifications. In this case, AP 104 may be able to operate as both a cellular base station and a Wi-Fi access point. As another possibility, AP 104 may include multimode radio components capable of performing communication according to any of the various wireless communication technologies (e.g., 5G NR and Wi-Fi, 5G NR and LTE, etc.). As yet another possibility, AP 104 may be configured to function exclusively as a Wi-Fi access point, for example, in the absence of cellular communication capabilities.

[0086] As further described herein, AP 104 may include hardware and software components for implementing or supporting the implementation of the features described herein, such as techniques for performing efficient coordinated beamforming detection and data operations, and various other possible features. The processor 304 of AP 104 may be configured, for example, to implement or support some or all of the methods described herein by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium) to operate multiple wireless links using multiple corresponding radio components. Alternatively, processor 304 may be configured as a programmable hardware element, such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), or a combination thereof. Alternatively (or otherwise), the processor 304 of AP 104, in conjunction with one or more of other components 330, 332, 334, 340, 350, 360, 370, may be configured to implement or support some or all of the features described herein.

[0087] Figure 4 —Block diagram of a modem or baseband processor

[0088] Figure 4 An example block diagram of a modem 400 is shown, which may also be referred to as a baseband processor 400. Modem 400 can provide signal processing functionality for one or more wireless communication technologies such as Wi-Fi, Bluetooth, and / or cellular (e.g., 3GPP) communication technologies. Therefore, as an option, modem 400 may represent a Wi-Fi modem; for example, Figure 4 The illustrated modem 400 can represent Figure 2 One possible example of the illustrated Wi-Fi modem 232. Alternatively, modem 400 could represent a cellular modem or a cellular baseband processor; for example... Figure 4 The illustrated modem 400 can represent Figure 2 One possible example of the illustrated cellular modem 234. As a further possibility, modem 400 could represent a Bluetooth modem; for example, Figure 4 The illustrated modem 400 can represent Figure 2 This is one possible example of the illustrated Wi-Fi modem 236. In some cases, modem 400 may implement functionality to support communication according to various wireless communication technologies. In at least some cases, modem 400 may run a real-time operating system, for example, to facilitate the performance of time-dependent wireless communication functionality.

[0089] In some cases, modem 400 can be configured to perform concurrent data transmission and reception across multiple channels in a single and / or multiple frequency bands (e.g., such as the 2.4 GHz band, 5 GHz band, and / or 6 GHz band). Therefore, modem 400 can be configured to perform multi-link operation (MLO). For example, modem 400 can be configured to perform simultaneous transmit and receive (STR) operation (e.g., configured for simultaneous uplink and downlink traffic on a pair of links) and / or enhanced multi-link single radio (EMLSR) operation (e.g., configured to allow a single radio component to simultaneously listen to two or more links).

[0090] Modem 400 may include processing circuitry 402, which may include one or more processor cores, ASICs, programmable hardware elements, digital signal processors, and / or other processing elements. The processing circuitry may be able to prepare baseband signals for up-conversion and transmission by the radio circuitry of a wireless device, and / or process baseband signals for reception and down-conversion by the radio circuitry of the wireless device. Such processing may include signal modulation, encoding, decoding, etc., among various possible functions. The processing circuitry may also be able to, or alternatively, perform functionality of one or more baseband and / or other layers / sublayers of the protocol stack for a wireless communication technology implemented by modem 400, such as physical layer (PHY) functionality, media access control (MAC) functionality, logical link control (LLC) functionality, radio resource control (RRC) functionality, radio link control (RLC) functionality, etc. In some cases, modem 400 itself may include at least some radio circuitry (e.g., for performing input baseband signal to radio frequency signal conversion and / or input radio frequency signal to baseband signal conversion). Alternatively or additionally, some or all of these functions may be performed by separate radio / transceiver components of the wireless device.

[0091] The modem 400 may also include a memory 404, which may include a non-transitory computer-readable storage medium. The memory 404 may include program instructions for performing signal processing and / or any of the various possible general-purpose processing functions. The processing circuitry 402 may be able to execute the program instructions stored in the memory 404. The memory 404 may also store data generated and / or used during processing performed by the processing circuitry 402.

[0092] As shown in the figure, the modem 400 may also include, for example, for communication with wireless devices (such as...) Figures 1 to 3Interface circuitry that communicates with other components of the illustrated STA 106 or AP 104 (such as the application processor, radio / transceiver circuitry, and / or any of the various other components). Such an interface can be implemented in any of a variety of ways; for example, as one possibility, the modem 400 may have a direct interface to the transceiver circuitry of the wireless device and may have additional indirect interfaces via the system bus to the application processor and / or other components of the wireless device. Other configurations are also possible.

[0093] In at least some cases, the hardware and software components of modem 400 may be configured to implement or support the features described herein, such as techniques for effectively coordinating beamforming detection and data operations, as well as various other possible features. For example, the processing circuitry 402 of modem 400 may be configured to implement or support some or all of the methods described herein, for example, by executing program instructions stored on memory (e.g., a non-transitory computer-readable storage medium) 404 and / or using dedicated hardware components.

[0094] Figures 5 to 6 —Flowchart of Coordinating Beamforming Detection and Data Phases

[0095] Access point (AP) wireless devices can provide one or more basic service sets (BSS). In some implementations, an AP wireless device can be an AP multilink device (MLD) capable of providing a BSS on each of multiple links such as 2.4 GHz, 5 GHz, and / or 6 GHz. An AP wireless device can operate independently or be attached to one or more other devices (e.g., as part of a larger network). For example, in some implementations, an AP wireless device can be a member of a multi-access point (MAP) system that may include multiple AP wireless devices.

[0096] An access point (AP) wireless device can establish a wireless association with one or more non-AP (or "STA") wireless devices. Depending on the implementation, such wireless associations can be established using Wi-Fi, at least partially Wi-Fi-based wireless communication technologies, and / or any of a variety of other wireless communication technologies. For example, as a possibility, an access point (AP) wireless device may provide (e.g., broadcast) a beacon transmission including information for association with the AP wireless device, and one or more other wireless devices (e.g., non-AP wireless devices) may use the information provided in the beacon transmission to request association with the AP wireless device. In some cases, it is also possible to use (e.g., unicast) probe requests and probe responses for non-AP wireless devices to obtain AP parameters and / or other system information about the AP wireless device. Variations and / or other technologies for establishing associations are also possible.

[0097] According to at least some implementations, the AP wireless device can provide wireless LAN functionality to associated wireless devices. As part of the wireless LAN functionality, depending on the general specifications of the wireless communication technology used by the wireless LAN (e.g., as a possibility, Wi-Fi) and / or the network-specific parameters configured by the AP wireless device, the wireless devices may compete for medium access and may perform wireless transmissions on one or more wireless communication channels (each of which may include multiple sub-channels).

[0098] For example, according to at least some implementations, performing downlink data transmission from an access point (AP) wireless device to a non-AP wireless device in such a wireless LAN may include contention for media access (e.g., to avoid collisions and potential interference), and once media access is obtained, a Physical Layer (PHY) Protocol Data Unit (PPDU) (which may also be referred to as a downlink frame) is transmitted to the destination wireless device. The downlink frame may include physical layer signaling (e.g., including preambles for frame detection, time and frequency synchronization, channel estimation, etc., and header information indicating packet configuration, format, data rate, channel occupancy time, and / or other control information) and data (which may in turn include one or more higher-layer packets, such as Media Access Control (MAC) Protocol Data Units (MPDUs)). It should be noted that other types of transmission (e.g., including triggered uplink frames, Enhanced Distributed Channel Access (EDCA) uplink frames, Transmission Opportunity (TXOP) sharing for peer-to-peer (P2P) communication, etc.) are also possible in such wireless LANs.

[0099] In some implementations, coordinated beamforming (CBF) operations are possible in a WLAN setup. Such operations may include multiple access point wireless devices preparing and performing coordinated beamforming and nulling transmissions to associated non-access point wireless devices to potentially improve efficiency and overall network capacity. To prepare for coordinated beamforming and nulling transmissions, a probing phase may be performed among the various devices involved, for example, to enable access point devices to effectively form beamforming and nulling signals for data transmission.

[0100] Figure 5 This is a flowchart illustrating methods for supporting such coordinated beamforming detection operations in a WLAN according to some embodiments. In various embodiments, some elements of the method shown may be performed simultaneously, in a different order than shown, replaced by one or more other method elements, or omitted. Additional method elements may also be performed as needed.

[0101] Figure 5 Various aspects of the method can be derived from wireless devices (such as...) Figures 1 to 4 This can be implemented using the AP 104 or STA 106 shown and described with respect to these figures, or more generally, it can be implemented as needed using any of the computer circuits, systems, devices, elements, or components shown in the figures. For example, the processor of such a device (such as in...) Figure 4 The baseband processor 400 illustrated and described relative to the figure and / or other hardware may be configured to cause the device to perform any combination of the method elements shown and / or other method elements.

[0102] It should be noted that, although described in a manner relating to the use of communication technologies and / or features associated with the IEEE 802.11 specification document... Figure 5 The method incorporates at least some elements, but this description is not intended to limit the scope of this disclosure. Figure 5 Various aspects of this method can be used in any suitable wireless communication system as needed. As shown in the figure, the method can be operated as follows.

[0103] The first access point radio device may send an initial control frame (ICF) to the second access point radio device to initiate a transmission opportunity (TXOP) (502) for coordinating beamforming (CBF) probes. The ICF may indicate a (“first”) duration value configured for, for example, determining a network allocation vector (NAV) by a receiving device, which may include the second access point radio device, non-access point radio devices associated with the first access point radio device, overlapping basic service set radio devices, etc. The first duration may be configured to protect the entire CBF probe sequence, or may protect multiple CBF probe sequences within the TXOP. Alternatively, the first duration may be configured to protect a more limited portion of the CBF probe sequence, such as until the transmission of beamforming report polling frames begins. This approach avoids blocking media use in scenarios where NAV protection for the entire sequence is not required, such as when BFR information can be provided from the first access point radio device to the second access point radio device via a backhaul link.

[0104] In some implementations, the access point wireless device that initiates a TXOP in this manner may be referred to herein as the TXOP-sharing initiating access point, while the access point wireless device that shares a TXOP with it in this manner may be referred to herein as the TXOP-shared access point. Therefore, in Figure 5 In the example, the first access point wireless device may act as the TXOP sharing initiating access point, while the second access point wireless device may act as the TXOP being shared access point. However, it should be noted that, at least according to some embodiments, such roles are not necessarily fixed, and an access point may be able to act as the TXOP sharing initiating access point at one time and as the TXOP being shared access point at another time. For example, in some embodiments, an access point may act as both the TXOP sharing initiating access point for CBF probing and the TXOP being shared access point for CBF data frame exchange sequences.

[0105] The second access point wireless device may, for example, send an Initial Control Response (ICR) frame (504) to the first access point wireless device in response to an ICF. The ICR may indicate a (“second”) duration configured to determine a NAV, which may also be configured to protect one or more CBF probe sequences in the TXOP. In some cases, at least according to some embodiments, the endpoints of the NAV derived from the indication of the second duration in the ICR and the endpoints of the NAV derived from the indication of the first duration in the ICF may be matched, for example, to provide protection for both those wireless devices within range of the first access point wireless device and those within range of the second access point wireless device in the CBF probe sequences. The ICF and ICR may also carry the payload of one or more of the following: a Null Data Packet Advertisement (NDPA) frame, a Null Data Packet (NDP) frame, and / or a Beamforming Report Polling (BFRP) frame, for configuring subsequent frames in the probe sequence.

[0106] The first and second access point wireless devices may perform one or more CBF probe frame exchanges with one or more non-access point wireless devices (506). For example, CBF probe frame exchanges may be performed with a non-access point wireless device associated with one of the first or second access point wireless devices. In some embodiments, additional CBF probe frame exchanges may be performed with additional wireless devices (e.g., one or more additional non-access point wireless devices associated with the first or second access point wireless device).

[0107] In some implementations, CBF probe frame exchange may include joint CBF probe frame exchange. In this approach, it is possible that a first access point radio device and a second access point radio device concurrently perform null data packet (NDP) transmission. For example, after an ICF / ICR exchange between the first and second access point radio devices, the first access point radio device may perform an ICF / ICR exchange with a non-access point radio device associated with either the first or second access point radio device, and provide an NDP Advertisement (NDPA) frame. Following the NDPA, the first and second access point radio devices may (concurrently in time) transmit an NDP frame, which can be received by the non-access point radio device. The first access point wireless device may then provide a beamforming report polling (BFRP) frame to a non-access point wireless device, which may then respond with a beamforming report (BFR) frame to provide beamforming report information about both the first and second access point wireless devices, based at least in part on NDP frames provided by the first and second access point wireless devices. According to some embodiments, similar joint CBF detection operations may be performed with other non-access point wireless devices associated with the first or second access point wireless device.

[0108] As another possibility, in some implementations, CBF probe frame exchange may include sequential CBF probe frame exchange. In this approach, it is possible that NDP transmissions are performed sequentially by the first access point wireless device and the second access point wireless device. For example, the first access point wireless device may perform an ICF / ICR exchange with a non-access point wireless device associated with either the first or second access point wireless device and provide an NDPA frame. After the NDPA, the first access point wireless device may transmit an NDP frame, which may be received by the non-access point wireless device. The first access point wireless device may then provide a BFRP frame to the non-access point wireless device, which may then respond with a BFR frame to provide beamforming report information about the first access point wireless device, at least in part based on the NDP frame provided by the first access point wireless device. To obtain probe information from the non-access point wireless device against the second access point wireless device, the first access point wireless device may perform another ICF / ICR exchange with the non-access point wireless device (if necessary) and provide another NDPA frame. Following the NDPA, the second access point wireless device may transmit an NDP frame, which can be received by the non-access point wireless device. The first access point wireless device may then provide a BFRP frame to the non-access point wireless device, which can then respond with a BFR frame to provide beamforming report information about the second access point wireless device, at least in part, based on the NDP frame provided by the second access point wireless device. According to some embodiments, similar sequential CBF probe operations may be performed with other non-access point wireless devices associated with the first or second access point wireless device.

[0109] For concurrent NDP transmissions from multiple access points for joint probes, it may be important for both access points to set the BSS color code indicator to the same value (e.g., to align the physical layer (PHY) preamble). Similarly, for sequential probes, for a non-access point wireless device associated with one access point wireless device to decode / filter NDPs from another access point wireless device, it may be necessary to explicitly define the BSS color code to use.

[0110] Therefore, as one possibility, it is possible that the BSS_COLOR indicator is set to 0 in the PHY preamble of the NDP used for CBF detection. This could be a special BSS_COLOR value specified for this purpose. It is also possible, or alternatively, that a different special BSS_COLOR value is specified for this purpose. As another possibility, the TXOP-shared AP can be configured to use the BSS_COLOR value associated with the TXOP-shared initiating AP in the PHY preamble of the NDP used for CBF detection; for example, according to some embodiments, the second access point radio device can transmit the NDP with the BSS_COLOR indicator set to the BSS_COLOR value associated with the first access point radio device in the PHY preamble of the NDP used for CBF detection. As a further possibility, according to some embodiments, the BSS_COLOR value of the TXOP-shared AP can be used in the PHY preamble of the NDP used for CBF detection from both access point radio devices.

[0111] According to some implementation schemes, a similar option can be used to indicate BSS_COLOR for BFRs generated and transmitted by non-access point radio devices participating in CBF detection operations. For example, a second access point radio device can receive a BFR frame from a non-access point radio device associated with a first access point radio device, the BFR frame including a BSS_COLOR indicator set to 0 in the PHY preamble of the BFR frame, and the second access point radio device can decode the BFR frame at least in part based on the BSS_COLOR indicator set to 0 in the PHY preamble of the BFR frame. As another possibility, the second access point wireless device can receive a BFR frame from a non-access point wireless device associated with the first access point wireless device. This BFR frame includes a BSS_COLOR indicator in the PHY preamble of the BFR frame, where the BSS_COLOR value is set to the value associated with the first access point wireless device. The second access point wireless device can decode the BFR frame at least partially based on the BSS_COLOR indicator in the PHY preamble being set to the BSS_COLOR value associated with the first access point wireless device. As a further possibility, according to some embodiments, the BSS_COLOR value associated with the second access point wireless device can be used in the PHY preamble of the BFR frame, and both access point wireless devices can be configured to decode the BFR frame at least partially based on the BSS_COLOR indicator being set to the BSS_COLOR value associated with the second access point wireless device.

[0112] It should be noted that in some implementations, it is possible to use a different type of BSS_COLOR indicator in the BFR frame than in the NDP frame; for example, in some implementations, the BSS_COLOR indicator may be set to 0 in the PHY preamble of the NDP for CBF probing of a non-access point radio device, and in the PHY preamble of the BFR frame for CBF probing of a non-access point radio device, the BSS_COLOR indicator may be set to the BSS_COLOR value of the associated access point radio device for the non-access point radio device. Other combinations are also possible.

[0113] Providing a framework for fault notification and recovery during CBF probe operations can be useful. For example, if a second access point wireless device detects any error or special condition that may affect CBF data exchange operations with a first access point wireless device, such a framework could allow the second access point wireless device to notify the first access point wireless device to stop CBF transmission and / or take remedial actions to continue CBF transmission.

[0114] One approach for such error reporting could be for the second access point wireless device to provide an unsolicited error report frame after a CBF probe frame exchange sequence. Another approach could be for the second access point wireless device to provide CBF probe failure report information in a CBF response frame, provided in response to a CBF announcement frame provided by the first access point wireless device, for example, when the first access point wireless device is initiating, scheduling, or otherwise communicating regarding CBF data frame exchange. A further possibility could include the second access point wireless device providing CBF probe failure report information in its own ICF (Independent Frame Message). For example, after the first access point wireless device initiates a CBF data frame exchange with the second access point wireless device using its own ICF, the second access point wireless device could provide CBF probe failure report information to the first access point wireless device in its ICF. According to at least some implementation schemes, if the second access point wireless device determines to cancel CBF data frame exchange due to CBF probe failure report information, the ICF can be addressed to the first access point wireless device, and based on this, the first access point wireless device can continue to use the remaining TXOPs in the absence of the second access point wireless device.

[0115] It should be noted that CBF probe failure report information can be related to any aspect of CBF probe. In some implementations, error conditions associated with NDP transmissions during CBF probe can be provided. Alternatively, error conditions associated with BFR transmissions during CBF probe can be provided. In some cases, address change reports of non-access point radio devices included in the CBF probe can be provided as CBF probe failure report information; in this case, remedial information, such as updated address information for the non-access point radio devices, can also be provided. Other types of CBF probe failure report information are also possible.

[0116] It should be noted that in some implementations, a non-access point wireless device or an access point wireless device may opt out of CBF operation, for example, including CBF probing and / or CBF data frame exchange operations. For example, the wireless device may determine that lower power consumption has a higher priority than high data throughput and accordingly decide to opt out of CBF operation. Other reasons for deciding to opt out of CBF operation are also possible. For such non-access point wireless devices, an indication may be provided to their associated access point wireless device to opt out of CBF operation. Such an indication may be provided in any of a variety of ways, such as in a management frame, a data frame, the A-Control field of a management frame, a control frame, etc.

[0117] Therefore, according to Figure 5 The method, according to at least some implementation schemes, can perform CBF detection by providing NAV protection for all involved BSSs, and providing error reporting and handling options, opt-out signaling, and BSS_COLOR signaling coordination, which can greatly increase the robustness of such operations.

[0118] Once CBF detection has been performed, for example, by providing a group of access point wireless devices with detection information to enable the formation of beams and empty signals directed at one or more associated non-access point wireless devices, one or more CBF data frame exchange sequences can be executed.

[0119] Depending on the implementation scheme, there are several possible methods to construct the CBF data frame exchange sequence. One possibility is to use an interleaved ICF / ICR method, where the sharing initiating access point performs ICF / ICR exchange with its associated non-access point radio device, followed by the shared access point performing ICF / ICR exchange with its associated non-access point radio device. The sharing initiating access point and the shared access point can then coordinate the transmission of CBF data frames and receive block acknowledgment frames from the receiving radio device.

[0120] In this approach, it is possible to provide an indication to the non-access point radio device associated with the shared originating access point (e.g., by the shared originating access point, in an ICF provided to the associated non-access point radio device, or in another ICF, or in a CBF advertisement frame, or in a CBF synchronization frame, and in various other possibilities) to continue monitoring CBF data frames on the radio link after a CBF ICF from the shared access point is detected. This indication may include an identifier for the radio device, such as an association identifier. This prevents enhanced multi-link single radio (eMLSR) devices from switching their radio operation in a manner that would prevent the effective reception of CBF data frames. In various other possibilities, such an indication may indicate a duration or a number of physical layer protocol data units to continue monitoring on the radio link. It should be noted that, in this case, at least according to some embodiments, the shared originating access point may also be configured not to attempt to transmit on different links to the non-access point associated with it (e.g., if the non-access point radio device is an eMLSR radio device) for a configured duration.

[0121] In some implementations, similar operation may be applied to the shared access point and the non-access point wireless device associated with the shared access point. For example, the shared access point may indicate a duration in an ICF sent by the shared access point for the non-access point wireless device associated with the shared access point to remain on the link. In this case, at least according to some implementations, the shared access point wireless device may also be configured not to attempt to transmit to the non-access point wireless device on a different link during the configured duration (e.g., if the non-access point wireless device is an eMLSR wireless device).

[0122] In some implementations, NAV protection for the ICF from each AP can be left to the AP-specific implementation choice. One possibility includes supporting an indication of duration in the ICF, configured to determine the NAV, which provides protection until the end of the BA frame of the CBF sequence; this may also be referred to herein as the "long NAV protection" case. In this scenario, it is possible that the carrier sensing requirement subfield of the ICF can be set to 0, for example, so that carrier sensing does not need to be performed before sending any ICR frames provided in response to the ICF.

[0123] In some implementations, it may also be the case that the shared initiating access point and / or the shared access point provides an indication to prohibit non-primary channel access (NPCA) during the CBF data frame exchange sequence. For example, in various scenarios, such explicit indications may be provided in ICF, ICR, announcement, response, and / or synchronization frames.

[0124] Additionally, it is possible that the radio devices involved in a CBF data frame exchange sequence constructed in this manner can be configured with one or more NAV rule exceptions, for example, to provide NAV protection for both basic service sets participating in the CBF data frame exchange sequence without completely preventing the execution of the CBF data frame exchange sequence. For example, one or more NAV exceptions can be configured for a shared initiating access point to allow the transmission of one or more of ICF, ICR, synchronization, CBF data, or BA frames during an NAV set by a radio device, wherein the radio device is associated with a basic service set not provided by the shared initiating access point and is participating in the CBF data frame exchange sequence together with the shared initiating access point radio device, such as the shared access point radio device, a non-access point associated with the shared access point radio device, etc. Similarly, one or more NAV exceptions can be configured for a shared access point to allow the transmission of one or more of ICF, ICR, synchronization, CBF data, or BA frames during a NAV set by a radio device, wherein the radio device is associated with a basic service set not provided by the shared access point and is participating in a CBF data frame exchange sequence with the shared access point radio device, such as a shared initiating access point radio device, a non-access point associated with the shared initiating access point radio device, etc. For a non-access point radio device, one or more NAV exceptions can be configured to allow the transmission of one or more of ICR or BA frames during a NAV set by a radio device, wherein the radio device is not associated with the basic service set of the non-access point radio device and is participating in a CBF data frame exchange sequence with the non-access point radio device. For example, for non-access point wireless devices associated with a shared initiating access point, these may include the shared access point wireless device, non-access point wireless devices associated with the shared access point wireless device, etc.; while for non-access point wireless devices associated with a shared access point, these may include the shared initiating access point wireless device, non-access point wireless devices associated with the shared initiating access point wireless device, etc. It should be noted that, depending on the various implementation schemes, other NAV exceptions may also be implemented by using interleaved ICF / ICR structured CBF data frame exchange sequences, or alternatively.

[0125] Using such an interleaved ICF / ICR structure can potentially introduce a variety of possibilities for fault handling and fault recovery. For example, a scenario might arise where any of the following could fail: an ICR from a non-access point wireless device associated with the shared access point, an ICF from the shared access point, or an ICR from a non-access point wireless device associated with the shared access point. Therefore, in some implementations, fault handling / recovery techniques can be provided for such scenarios.

[0126] As a technique of this kind, in the event of an ICR failure from a non-access point radio device associated with the shared originating access point, the shared access point can suspend its ICF transmission. To facilitate this operation, the shared access point can also monitor the ICR from the non-access point radio devices associated with the shared originating access point.

[0127] As another such technique, the shared originating access point can perform data transmission within the basic service set even when no CBF ICF is received from the shared access point. In other words, at least according to some implementations, the shared originating access point can suspend the CBF data frame exchange sequence, but continue non-CBF data transmission in this case.

[0128] As another such technology, in the event of an ICR failure from a non-access point wireless device associated with the shared access point, the shared originating access point may adjust its CBF data frames or transmit non-CBF data frames instead of CBF data frames. In some implementations, it may also be possible for the shared originating access point to continue using the original CBF data frames in such scenarios. It should be noted that, according to various implementations, the shared originating access point can directly detect such ICR failures, for example, by monitoring the ICR from the non-access point wireless device associated with the shared access point, or the shared access point can notify the shared originating access point of such failures (e.g., using PIFS recovery).

[0129] Another approach to constructing a CBF data frame exchange sequence may include using a multi-user initial control frame, wherein a shared initiating access point simultaneously performs multi-user ICF / ICR exchanges with multiple non-access point radio devices and possibly also with a shared access point. The shared initiating and shared access points can then coordinate the transmission of CBF data frames and receive block acknowledgment frames from the receiving radio devices. According to some implementations, this method can potentially avoid at least some of the additional complexities introduced by CBF data frame exchange sequence structures that include interleaved ICF / ICR methods.

[0130] Figure 6 This is a flowchart illustrating methods for performing such coordinated beamforming data operations in a WLAN according to some embodiments. In various embodiments, some elements of the method shown may be performed simultaneously, in a different order than shown, replaced by one or more other method elements, or omitted. Additional method elements may also be performed as needed.

[0131] Figure 6 Various aspects of the method can be derived from wireless devices (such as...) Figures 1 to 4This can be implemented using the AP 104 or STA 106 shown and described with respect to these figures, or more generally, it can be implemented as needed using any of the computer circuits, systems, devices, elements, or components shown in the figures. For example, the processor of such a device (such as in...) Figure 4 The baseband processor 400 illustrated and described relative to the figure and / or other hardware may be configured to cause the device to perform any combination of the method elements shown and / or other method elements.

[0132] It should be noted that, although described in a manner relating to the use of communication technologies and / or features associated with the IEEE 802.11 specification document... Figure 6 The method incorporates at least some elements, but this description is not intended to limit the scope of this disclosure. Figure 6 Various aspects of this method can be used in any suitable wireless communication system as needed. As shown in the figure, the method can be operated as follows.

[0133] The first access point wireless device can transmit an ICF (602) for CBF data frame exchange sequences addressing multiple users. Because this ICF can be addressed to multiple users, in some embodiments, this ICF may also be referred to herein as a multi-user ICF or MU ICF. This ICF can be addressed to one or more non-access point wireless devices, such as a first non-access point wireless device associated with the first access point wireless device and a second non-access point wireless device associated with the second access point wireless device. Figure 6 In the example scenario, the first access point radio device can act as the TXOP sharing initiating access point, while the second access point radio device can act as the TXOP being shared access point. The ICF can indicate the duration configured to determine the NAV, which can be configured to protect the remainder of the CBF data frame exchange sequence. Alternatively, the duration indicated in the ICF may be configured to determine an NAV that protects only a portion of the CBF data frame exchange sequence. Such shorter NAV protection can be useful, for example, to prevent the second access point radio device from using the medium if CBF data frame transmission is ultimately performed without the participation of the second access point radio device.

[0134] The first access point wireless device may receive one or more ICRs in response to the ICF of the CBF data frame exchange sequence. At least in some embodiments, ICRs may be received simultaneously, for example, effectively as multi-user uplink frames. For example, in some embodiments, the first access point wireless device may receive ICRs from each of a first non-access point wireless device and a second non-access point wireless device.

[0135] In some implementations, the ICF can also be addressed to a second access point wireless device. For example, if a first access point wireless device determines that it needs to request an ICR from a second access point wireless device to obtain better NAV protection, the second access point wireless device can be addressed. In this case, the first access point wireless device can receive the ICR from the second access point wireless device.

[0136] The ICF may provide information to non-access point radio devices participating in the CBF data frame exchange sequence to facilitate efficient reception of CBF data frames. In some embodiments, this may include providing associated access point identifier information (such as BSS_COLOR, or another access point identifier, such as the full MAC address of the access point, or a short identifier (e.g., only 11 or 12 bits to identify the AP to improve call time efficiency)) and associated identifier (AID) information for those non-access point radio devices. Providing both associated access point identifier information and AID information helps avoid uncertainty when participating non-access point radio devices associated with different BSSs have the same AID. Therefore, in some embodiments, the ICF may include access point identifier information and AID information for a first non-access point radio device and a second non-access point radio device. In some embodiments, the access point identifier information and AID information may be explicitly indicated as tuples. In some embodiments, the access point associated with the non-access point radio device for which information is provided in the ICF may be implicitly indicated, for example, based on the location of the non-access point's AID information within the ICF. For example, as one possibility, the AID of the device associated with the shared originating access point may be placed in the ICF earlier, and the AID of the device associated with the shared access point may be placed in the ICF later, wherein a split point is indicated in the ICF. As another example, the access point identifier information of the shared access point or the AID of the device associated with the shared access point may be placed in the ICF earlier, and the AID of the device associated with the shared originating access point may be placed in the ICF later, wherein a split point is indicated in the ICF. One example of indicating a split point may be inserting a user information field containing the short identifier of the shared access point's AID12 immediately after all user information fields for the device associated with the shared originating access point. Another example of indicating a split point may be inserting a user information field containing the short identifier of the shared access point's AID12 at the beginning of the user information list in the ICF, and the content of this user information field may indicate a split point, for example, in various possibilities, as a user information field counter or byte count.

[0137] In some implementations, the ICF may additionally or alternatively assign one or more CBF-specific values ​​to participating non-access point radio devices for use in the CBF data frame exchange sequence. For example, one or more of the CBF-specific associated access point identifier (e.g., a CBF-specific BSS_COLOR, which may differ from the BSS_COLOR of the BSS provided by the first or second access point radio device) or a CBF-specific AID may be assigned to one or more of the first or second non-access point radio devices. At least according to some implementations, such assignment may potentially assist the non-access point radio devices in decoding CBF data frames provided during the CBF data frame exchange sequence.

[0138] In some implementations, the ICF can provide CBF-specific transmitter address (TA) and / or CBF-specific receiver address (RA) information. For example, one or more TA and / or RA values ​​can be specified for CBF operation in wireless communication standard specifications. In this case, a non-access point wireless device receiving the ICF can be configured to recognize that the use of such TA and / or RA in the ICF indicates that the ICF is initiating a CBF data frame exchange sequence, and filter the frames accordingly.

[0139] It should be noted that, depending on the implementation scheme, any frame format from a wide range of possible frame formats can be used for ICF and ICR frames. As one possibility, a frame format based on Multiple User Request Transmission (MU-RTS) frames can be used as ICF. Similarly, a frame format based on Clear Transmission (CTS) frames can be used for ICR frames. Other options are also available, including frame formats based on Buffer Status Report Polling (BSRP) and Buffer Status Report (BSR) frame formats, newly defined trigger and / or response frames, and / or any of a variety of other possible frame formats.

[0140] In some implementations, the exchange of CBF announcement frames and CBF response frames may be performed by a first access point wireless device and a second access point wireless device (e.g., before transmitting an ICF), for example, to coordinate the scheduling of the CBF data frame exchange sequence (e.g., for the second access point wireless device to indicate its participation intention, for the first and second access point wireless devices to indicate / select participating non-access point wireless devices, to negotiate the parameters of the CBF data frames (e.g., preamble settings), how to schedule block acknowledgment frames, etc.). Therefore, it is possible that an ICF is transmitted at least in part based on the exchange of CBF announcement frames and CBF response frames. In some implementations, the exchange of CBF announcement frames and CBF response frames may be performed between two or more access point wireless devices, for example, in scenarios where CBF data exchanges can be scheduled and performed between three or more access point wireless devices. It is also possible, or alternatively possible, that the exchange of CBF announcement frames and CBF response frames can be performed in a manner that includes one or more non-AP wireless devices. For example, in some implementations, the CBF announcement frame may also request a response frame from the first non-access point wireless device. In this scenario, the first access point may also receive a CBF response frame from the first non-access point wireless device. Therefore, in some implementations, the CBF announcement frame may include a multi-user triggered frame, and the response may include a trigger-based frame. Clear Transmission (CTS) CBF response frames can be used as another possibility. In some cases, non-high-throughput repeating (non-HT dup) frames may be used for the CBF response frame.

[0141] According to at least some implementations, the first and second access point wireless devices can maintain NAV protection throughout the entire CBF data frame exchange sequence. For example, a CBF notification frame can indicate a (“first”) duration (configured to determine the NAV providing protection until the start of an ICF), a CBF response frame can indicate a (“second”) duration (configured to determine the NAV providing protection until the start of an ICF frame or a CBF data frame), and an ICF can indicate a (“third”) duration (configured to determine the NAV providing protection until the end of one or more block acknowledgment frames completing the CBF data frame exchange sequence). As previously mentioned herein, in some cases, an ICR (e.g., if requested) provided by the second access point wireless device can also provide NAV protection until the end of one or more block acknowledgment frames completing the CBF data frame exchange sequence.

[0142] According to various implementation schemes, multiple options may exist for handling the security of CBF data frame exchange sequences. Specifically, since devices associated with multiple BSSs may be involved in the CBF data frame sequence, it may be useful to provide techniques for non-access point radio devices to identify when to respond to communications from access point devices not associated with the non-access point. For example, considering that a second non-access point radio device is associated with a second access point radio device rather than a first access point radio device, it may be important to provide a way for the second non-access point radio device to identify whether an ICF from the first non-access point radio device is a valid frame and whether to respond with an ICR frame.

[0143] As one possibility, the CBF response frame provided by the second access point wireless device may include security fingerprint information of the second non-access point wireless device (e.g., generated based on a key between the second access point wireless device and the second non-access point wireless device). Based at least in part on this security fingerprint information, the second non-access point device can determine the subsequent ICF (e.g., if authentication is successful). Therefore, in this case, the second non-access point can directly decode the CBF response frame to obtain this fingerprint information.

[0144] As an alternative possibility, the CBF response frame could similarly carry this fingerprint information, and the first access point wireless device could rebroadcast the fingerprint in a subsequent ICF. In this case, the second non-access point might not need to decode the CBF response frame to obtain this fingerprint information, and could use the key between the second non-access point wireless device and the second access point wireless device to verify the fingerprint in the ICF to determine whether to respond to the ICF.

[0145] Another possibility could include defining a shared key across the two BSSs. In other words, a shared key could be defined across the first and second access point radio devices (e.g., as a possibility, together with CBF scheduling and parameter negotiation during CBF announcement / response exchanges), for example, for use in CBF data frame sequences. In this case, the first access point radio device could include the security fingerprint information of the second non-access point radio device in the ICF based on this shared key, and the second non-access point radio device could use the shared key to verify the ICF and determine whether to respond to the ICF.

[0146] The first access point wireless device can transmit CBF data frames (606). The second access point wireless device can also transmit CBF data frames concurrently with those transmitted by the first access point wireless device in time. At least in some embodiments, the CBF data frames transmitted by the first and second access point wireless devices can occupy the same bandwidth. If preamble puncturing is used in CBF data transmission, the same puncturing pattern can be used. At least in some embodiments, this method avoids introducing additional complexity for joint probe and nulling operations.

[0147] According to at least some embodiments, CBF data frame transmission by the first access point wireless device may include beamforming the CBF data frame to the first non-access point wireless device and nulling the CBF data frame to the second non-access point wireless device, for example, to reduce potential interference to the second non-access point wireless device caused by transmitting the CBF data frame to the first non-access point wireless device. Similarly, CBF data frame transmission by the second access point wireless device may include beamforming the CBF data frame to the second non-access point wireless device and nulling the CBF data frame to the first non-access point wireless device, for example, to reduce potential interference to the first non-access point wireless device caused by transmitting the CBF data frame to the second non-access point wireless device. Therefore, according to at least some embodiments, such coordinated beamforming between the initiating access point wireless device and the shared access point wireless device can improve the signal quality at each of the receiving wireless devices.

[0148] CBF data frames transmitted by the first and second access point wireless devices may be transmitted using at least partially the same PHY preamble. For example, in some embodiments, the PHY preamble may be aligned via the UHR-SIG field (e.g., for the initial non-beamforming portion). According to at least some embodiments, aligning the PHY preamble (e.g., at least its initial portion) helps wireless devices not belonging to the CBF data frame sequence to decode these preambles to obtain relevant information. In some embodiments, following the aligned non-beamforming PHY preamble portion of the CBF data frame, a beamforming portion with space nulls may be provided, which may also include one or more PHY preamble fields, such as the UHR-STF and / or UHR-LTF fields.

[0149] The PHY preamble may also include other relevant information for facilitating the allocation of Identification Resource Units (RUs) and / or each of the target receiving wireless devices. In some embodiments, this may include providing at least one of the following for one or more of the first or second non-access point wireless devices: CBF-specific associated access point identifier information (e.g., CBF-specific BSS_COLOR) or CBF-specific non-access point wireless device identifier information. For example, if CBF-specific BSS_COLOR or CBF-specific wireless device identifier information is assigned earlier in a CBF data frame sequence (e.g., in an advertisement frame, ICF, synchronization frame, etc.), these values ​​can be used to identify which part of the information corresponds to which wireless device in the CBF data frame preamble.

[0150] As an alternative possibility, both associated access point identifier information (e.g., BSS_COLOR or another indicator) and non-access point radio device identifier information (e.g., STA-ID) can be used to provide RU allocation and / or otherwise identify which part of the information corresponds to which radio device in the CBF data frame preamble. Using both types of information can be another way to avoid potential ambiguity in situations where radio devices associated with different BSSs may have the same intra-BSS radio device identifier information. In some implementations, instead of BSS_COLOR or anything else, abbreviated indicators of the associated access point identifier information can be used. For example, a 1-bit BSS indicator can be defined such that a value of "0" indicates a radio device associated with the shared initiating access point (e.g., the first access point radio device), while a value of "1" indicates a radio device associated with the shared access point (e.g., the second access point radio device).

[0151] Another possibility could be the use of multiple content channels in the PHY preamble. For example, a first content channel (e.g., a 20MHz sub-channel) could provide RU allocation information for a BSS provided by a first access point radio device, while a second content channel could provide RU allocation information for a BSS provided by a second access point radio device.

[0152] According to at least some implementations, the PHY preamble may also include PHY Protocol Data Unit (PPDU) type information, which indicates that the CBF data frame is a CBF PPDU. It should be noted that in some implementations, partial bandwidth CBF data frames may also be transmitted. For example, a first access point wireless device and a second access point wireless device may concurrently transmit on the CBF bandwidth portion of a partial bandwidth CBF data frame, while only the first access point wireless device transmits on the non-CBF bandwidth portion of the partial bandwidth CBF data frame. In some implementations, if such partial bandwidth CBF data frame transmission is supported, the PHY preamble PPDU type field may include a value configured to indicate that the CBF data frame is a partial bandwidth CBF data frame.

[0153] There are several possibilities for how the PHY preamble can be constructed to provide the various possible types of information described herein. Several specific examples of such possibilities are described in the following sections. However, it should be noted that many variations and alternatives are possible. As one possibility, it is possible that a 3-bit subfield across U-SIG1 and U-SIG2 in the PHY preamble (e.g., bit 25 (verification bit) of the U-SIG1 field and bits 0-1 of the U-SIG2 field) is configured to indicate the CBF PPDU type of the CBF data frame. In the case that the CBF data frame is a partial bandwidth CBF data frame, bit 25 of the U-SIG1 field and bits 0-1 of the U-SIG2 field of the PHY preamble can indicate that the CBF PPDU type of the CBF data frame is a partial bandwidth CBF data frame. Similarly, in this case, the user field of the non-access point radio device that allocates the second half-bandwidth portion of the partial bandwidth CBF data frame can be the last user field of the PHY preamble and can have an Orthogonal Frequency Division Multiple Access (OFDMA) format. As another possibility, the CBF data frame can be a partial bandwidth CBF frame, where a 2-bit subfield (e.g., bits 19-20) of the UHR SIG common field of the PHY preamble indicates that the CBF PPDU type of the CBF data frame is a partial bandwidth CBF data frame. At least according to some embodiments, in this case, a 6-bit subfield (e.g., bits 0-5) of the UHR SIG common field of the PHY preamble may indicate the BSS_COLOR of the shared access point radio device of the CBF data frame, and a 2-bit subfield (e.g., bits 17-18) of the UHR SIG common field of the PHY preamble may indicate the total number of non-OFDMA users addressed in the CBF data frame. In some cases, bits 7-12 of the U-SIG1 field of the PHY preamble may be configured to indicate the BSS_COLOR of the shared initiating access point radio device of the CBF data frame. As another possibility, a 6-bit subfield (e.g., bits 0-5) of the UHR-SIG common field of the PHY preamble can be configured to indicate the BSS_COLOR of the shared access point radio device in the CBF data frame. As yet another possibility, a 2-bit subfield (e.g., bits 17-18) of the UHR-SIG common field of the PHY preamble can be configured to indicate the total number of users addressed in the CBF frame. As yet another possibility, bits 20-25 of the U-SIG1 field of the PHY preamble can be configured to indicate the BSS_COLOR of the shared access point radio device in the CBF frame. As a further possibility, reserved bits (e.g., bit 20) of each user field of the PHY preamble can be configured to indicate the associated access point radio device of a non-access point radio device.In some implementations, the UHR-SIG modulation and decoding scheme (MCS) field of the PHY preamble (e.g., bits 9-10 of U-SIG2) can be set to 0, for example, to indicate that the UHR-SIG field uses UHR-MCS0. This can be beneficial because timing synchronization errors may exist between the shared initiating access point and the shared access point, for example, by providing a robust MCS for more reliable decoding of UHR-SIG.

[0154] One or more Block Acknowledgment (BA) frames (608) may be received in response to a CBF data frame. For example, a first access point radio device may receive BA frames at least from a first non-access point radio device, and a second access point radio device may receive BA frames at least from a second non-access point radio device. In some embodiments, orthogonal frequency division multiple access (OFDMA) may be used to receive BA frames concurrently in time. In some embodiments, BA information for the second non-access point radio device may be provided from the first access point radio device to the second access point radio device via a backhaul link. According to various embodiments, such arrangements may be negotiated during a CBF announcement / response exchange, and / or such frames may be requested by a CBF data frame. As another possibility, BA frames may be received in a time-interleaved manner. For example, the first access point radio device may provide a BA request (BAR) frame after a CBF PPDU to request and receive BA from the first non-access point radio device, and then the second access point radio device may provide a BAR frame to request and receive BA from the second non-access point radio device. In some implementations, a cross-BSS trigger frame may be provided to request such interleaved BA transmissions from both the first and second non-access point radio devices. The cross-BSS trigger frame may, for example, include identification information for the first and second non-access point radio devices, to prevent them from returning to eMLSR listening operations.

[0155] Therefore, according to Figure 6 The method, according to at least some implementations, can perform a coordinated beamforming data frame exchange sequence including a multi-user initial control frame, which can provide effective security, NAV protection, and signaling across multiple basic service sets involved in the sequence, as well as various possible benefits.

[0156] According to some implementations, similar techniques can also be used to perform Coordinated Spatial Reuse (C-SR) frame exchange sequences. According to some implementations, for example, announcement / response frame exchange can be performed between a first access point radio device, a second access point radio device, and possibly one or more other access point and / or non-access point radio devices, for example, to request interest indications, negotiate scheduling, and other configuration parameters. As part of the announcement / response frame exchange, the first access point radio device can send an announcement frame for the C-SR data frame exchange sequence, which can be addressed to at least the second access point radio device. For example, in a scenario where the same announcement frame structure can be used for announcement / response frame exchange of both C-SR and CBF data frame exchange sequences, the announcement frame can indicate whether it is for the C-SR or CBF data frame exchange sequence. The first access point radio device can receive response frames for the C-SR data frame exchange sequence from the second access point radio device and / or one or more other access point and / or non-access point radio devices.

[0157] A first access point radio device may transmit a first ICF for a C-SR data frame exchange sequence, the first ICF being addressable to at least a first non-access point radio device associated with the first access point radio device. The first access point radio device may receive an ICR frame from at least the first non-access point radio device in response to the first ICF. A second access point radio device may similarly transmit a second ICF for a C-SR data frame exchange sequence, the second ICF being addressable to at least a second non-access point radio device associated with the second access point radio device. The second access point radio device may receive an ICR frame from at least the second non-access point radio device in response to the second ICF.

[0158] In some implementations, either or both of the ICFs may also request an ICR from another access point radio device, in which case that access point radio device may also provide the ICR. Therefore, it is possible that the first ICF is also addressed to the second access point radio device, and the first access point radio device receives an ICR frame from the second access point radio device in response to the first ICF. Similarly, it is possible that the second ICF is also addressed to the first access point radio device, and the second access point radio device receives an ICR frame from the first access point radio device in response to the second ICF.

[0159] It should be noted that in a C-SR scenario, it is possible that the first access point radio device is not within the coverage area of ​​the second non-access point radio device, and / or the second access point radio device is not within the coverage area of ​​the first non-access point radio device. Therefore, to determine the timing of the transmission of the second ICF, as one possibility, the second access point radio device may decode the duration indication in the first ICF and determine the time to start transmitting the second ICF based on the decoded duration indication. As another possibility, if requested by the first ICF, the second access point radio device may respond with its ICR and determine to start transmitting the second ICF after a configured amount of time (e.g., one possibility is SIFS).

[0160] At least in some embodiments, synchronization frames can also be used in the C-SR data frame exchange sequence. It is possible that the synchronization frame is sent by one or the other of the first or second access point radio device. In some embodiments, it is possible that the access point radio device initiating the C-SR data frame exchange sequence (e.g., the first access point radio device that sent the C-SR announcement frame) also sends the synchronization frame. As another possibility, the access point radio device sending the synchronization frame can be negotiated. In some embodiments, the access point radio device sending the synchronization frame can be implicitly determined between the first and second access point radio devices. For example, in some embodiments, one of the supporting access points can indicate that it is serving "legacy" non-access point radio devices in the C-SR data frame exchange sequence. In such scenarios, it can be implicitly determined that the access point also sends the synchronization frame. In some embodiments, the synchronization frame can be a trigger frame. In some other embodiments, the synchronization frame can be a CTS frame. Synchronization frames may carry additional parameters for subsequent data and / or block acknowledgment transmissions, and may optionally include padding to give another AP sufficient time to prepare for subsequent data and / or block acknowledgment transmissions. Parameters for data transmission may include BSS color code, STA ID, TXOP duration, bandwidth, puncturing pattern, number of long training fields (LTF), modulation and decoding scheme (MCS), and / or other parameters.

[0161] Figures 7 to 37 and additional information

[0162] Figures 7 to 37 Examples of combinable Figures 5 to 6 The method used is another aspect. However, it should be noted that in Figures 7 to 37 The exemplary details illustrated and described with respect to these figures are not intended to limit this disclosure as a whole: many variations and alternatives to the details provided below are possible and should be considered within the scope of this disclosure.

[0163] In a wireless LAN environment, concurrent coordinated beamforming and null transmission from two or more APs can potentially provide increased network capacity. Figure 7 Example aspects of such possible transmissions according to some embodiments are illustrated. According to some embodiments, the AP that initiates a transmission opportunity (TXOP) and determines to share the TXOP with another AP through coordinated beamforming may be referred to herein as the "sharing initiator" AP, while the AP that shares the TXOP with it for coordinated beamforming may be referred to herein as the "shared" AP. Other terms for these roles are also possible. As shown, the sharing initiator AP may transmit beamforming signals to associated STA1 and STA2, and transmit nulling signals to overlapping basic service sets (OBSS) STA3 and STA4, for example, to suppress interference effects of transmissions to STA1 and STA2 on STA3 and STA4. The shared AP may coordinately transmit beamforming signals to associated STA3 and STA4, and transmit nulling signals to OBSS STA1 and STA2, similarly to suppress interference effects of transmissions to STA3 and STA4 on STA1 and STA2.

[0164] To achieve this type of coordinated beamforming (CBF) operation, it is possible that the AP periodically performs probes with candidate STAs for CBF operation and sends subsequent CBF physical layer protocol data units (PPDUs) based on the probe feedback. Figure 8 An example timeline is illustrated according to some implementation schemes, in which such CBF probing and subsequent CBF PPDU sending can occur between AP1 (shared initiation), AP2 (shared), STA1 (associated with AP1), and STA2 (associated with AP2).

[0165] There are several methods available for handling the detection timing of CBF. Figure 9Two example timelines of two such methods for a scenario with AP1 (shared initiator), AP2 (shared), and STA (associated with AP1) according to some implementation schemes are illustrated. As shown, in the sequential method, after the initial control frame (ICF) and initial control response (ICR) exchange and null data frame advertisement (NDPA), AP1 can provide a null data frame (NDP) and request a BFR from STA1 using a beamforming report (BFR) polling (BFRP) frame. Then, possibly after further ICF / ICR exchanges, AP1 can provide another NDPA, STA2 can provide an NDP, and AP1 can provide a BFRP to request a BFR from STA1. Thus, AP1 and AP2 can perform probing sequentially with STA1. In the joint method, after the ICF and ICR exchange and NDPA, AP1 and AP2 can provide NDPs concurrently. AP1 can then provide a BFRP to request a BFR from STA1, and STA1 can provide a BFR including beamforming report information for both AP1 and AP2. In some cases, beamforming reports using such joint detection can result in better throughput, such as for partial nulling, but may also require higher capabilities on the STA side.

[0166] However, according to Figure 9 The sequence of NDP transmissions from the shared AP and / or BFR decoding at the shared AP may be potentially susceptible to transmissions from hidden nodes. Figure 10 Examples of scenarios where such hidden node interference can affect CBF probe operations according to some implementation schemes are illustrated. As shown, a STA_H within AP2's range but hidden from AP1 performs a transmission during a scheduled NDP transmission period, causing AP2's NDP transmission to fail (e.g., idle channel assessment may fail, thus preventing AP2 from transmitting NDP). As another possibility (and also shown), such hidden node transmission may also, or alternatively, interfere with the reception of BFRs transmitted by STA1. Such interference can hinder effective CBF operation, including that of AP2.

[0167] Therefore, according to at least some implementation schemes, it may be beneficial to include NAV protection from both the sharing initiating AP and the shared AP when performing CBF probing. Figure 11 Example aspects of a possible joint probe method are illustrated, which includes NAV protection from both AP1 (shared initiator) and AP2 (shared) when a CBF probe is performed with STA1 (associated with AP1). Figure 12An example aspect of another possible joint probing method is illustrated, which includes NAV protection from both AP1 (shared initiator) and AP2 (shared) when performing CBF probing with STA1 (associated with AP1), wherein NAV protection is provided until the start of BFRP frame transmission. This method can be used, for example, in some cases where AP2 can obtain BFR via backhaul, to avoid overprotection. Figure 13 Example aspects of a possible sequential probe method are illustrated, which includes NAV protection from both AP1 (shared initiator) and AP2 (shared) when a CBF probe is performed with STA1 (associated with AP1).

[0168] As shown in the figure, control frame exchange between APs can be used to protect the NAV during CBF probes. In the illustrated scenario, failure to receive an ICR from AP2 may be an early indication of a probe sequence failure. It should be noted that an NAV within a single TXOP can be configured to protect more than one probe sequence, where each probe sequence can be a joint or sequential probe sequence. The ICF and ICR can also carry payloads of one or more of the following for configuring subsequent frames in the probe sequence: Empty Data Packet Advertisement (NDPA) frames, Empty Data Packet (NDP) frames, Beamforming Report Polling (BFRP) frames, etc.

[0169] Providing a process for one AP to notify another AP of probe problems and / or probe requests may also be useful, potentially by defining one or more reason codes to provide further information. Such fault notification / recovery techniques can provide a way for the shared AP to report to the sharing initiating AP in the event of any failure in the ICR response to the ICF-A, NDP transmission from the shared AP, or BFR decoding at the shared AP. As a possibility, during message exchange between APs in the TXOP for CBF PPDU, the shared AP may reject the sharing initiating AP's request and indicate a lack of valid probe information or request the sharing initiating AP to re-probe.

[0170] Figure 14 Further details of possible fault handling methods for CBF detection according to some implementation schemes are illustrated. As noted, if AP2 (the shared one) detects any error or special circumstance that, for some reason, prevents CBF from being performed with AP1 (the shared initiator), it may be important to provide AP2 with a way to notify AP1 to stop CBF transmission and / or take remedial measures to continue CBF transmission.

[0171] As an option (e.g., "Option 1" as illustrated), if any error condition, such as an NDP or BFR problem, is detected during CBF probing, or if STA2 has changed its address (e.g., including an associated identifier (AID)), the shared AP may transmit a report after CBF probing. This report may also include remedial information, such as the updated address of STA2 (e.g., which may include the AID), so that AP1 knows which beamforming matrix to use to zero out STA2.

[0172] As another option (e.g., the illustrated "Option 2"), after receiving a notification frame from the sharing initiating AP1 (e.g., for requesting feedback from the shared AP to determine whether the AP is willing to participate in CBF and / or for more details about the resource request, such as priority or pending data), the shared AP2 may also report similar information to the sharing initiating AP1 in that frame.

[0173] As another option (e.g., "Option 3" as illustrated), similar information to that in Option 1 can be provided in the ICF from the shared initiator AP2. If AP2 wants AP1 to cancel the CBF with both AP1 and AP2, AP2 could potentially address the ICF to AP1, allowing AP1 to continue using the remaining TXOPs at least in some cases.

[0174] In some situations, a device may have reasons not to participate in CBF operations. For example, for some devices, it may be potentially determined not to participate in CBF operations when battery reserves are low and high throughput is not the highest priority. Therefore, at least in some implementations, supporting AP and / or STA opt-out of CBF operations may be useful. For AP operations, in some cases, scheduling implementations can be used to handle such options. For STA operations, management frames such as association or reassociation frames, or new management frames (e.g., similar to Operation Mode Notification (OMN) frames), can include capability or preference information to indicate whether the STA opts to join or leave CBF operations. In some cases, A-Control (e.g., Operation Mode Indication (OMI)) fields in data frames or management frames, or control frames such as ICR, may also potentially be used by the STA to indicate opt-out of CBF operations.

[0175] For concurrent NDPs from multiple APs used for joint probing, given that each AP can have a different BSS_COLOR parameter, there are multiple ways to configure the preamble to be the same (e.g., to support OBSS detection and NAV settings). For sequential probing, it may also be necessary to define the usage of BSS_COLOR so that the STA associated with the first AP can decode / filter NDPs from the second AP.

[0176] As an option, both APs can be configured to set BSS_COLOR to 0 (or another pre-configured value) in the PHY preamble for CBF probe of NDP. When such a BSS_COLOR indication is used for CBF probe operations, the STA can be configured accordingly to decode the NDP and provide subsequent BFR.

[0177] As an alternative possibility, BSS_COLOR can be set to the BSS color code of the first (e.g., shared-initiated) AP that transmits the corresponding NDPA. In this case, for the STA that needs to decode the NDPA and is associated with the first AP, the decoding behavior may remain unchanged as in non-CBF operation. For the first AP (to which the STA is associated), the transmission behavior may similarly remain unchanged as in non-CBF operation. For a second (e.g., shared) AP to which the STA is not associated, the second AP can set BSS_COLOR to the BSS color code of the first AP, which may differ for the second AP from non-CBF operation.

[0178] According to some implementations, there are several possible methods for handling the BSS_COLOR indication in BFR transmissions. In a CBF, a second (e.g., shared) AP may need to decode a BFR transmitted by a STA associated with a first (e.g., shared initiating) AP, for example, if the BFR is part of a CBF probe sequence involving the second AP, for example, to facilitate the second AP setting the STA to zero during subsequent CBF data operations. As one possibility, the STA can be configured to set the BSS_COLOR to 0 in the preamble of the BFR. In this case, both the first and second APs can be configured to utilize such a setting to decode the BFR. As another possibility, the BSS_COLOR of the first AP transmitting the corresponding NDPA can be used. In this case, the second AP can configure its filter to enable it to decode the BFR. It should be noted that, at least in some implementations, the first AP can potentially decode the BFR in this case without any additional configuration.

[0179] Once CBF probing is performed, CBF data frame exchange can be carried out. Depending on the implementation, multiple frame exchange sequences are possible for CBF data frame communication. Figure 15This is a timing diagram illustrating an example aspect of such a possible frame exchange sequence. As shown, in the illustrated scenario, announcement and response frame exchanges can be performed between AP1 (shared initiator) and AP2 (shared), where, for example, CBF configuration and parameters for upcoming CBF data frame communication can be negotiated. AP1 and STA1 (associated with AP1) can perform ICF / ICR exchanges, followed by ICF / ICR exchanges between AP2 and STA2 (associated with AP2). A synchronization frame can be sent by AP1, followed by concurrent CBF PPDU transmissions by AP1 and AP2, and then concurrent BA transmissions by STA1 and STA2.

[0180] In the illustrated scenario, according to the IEEE 802.11be eMLSR rule, STA1 may return to listen operation after receiving an ICF from AP2 in the illustrated frame exchange sequence, which could potentially lead to CBF PPDU failure. Therefore, at least in some embodiments, to mitigate this possibility, AP1 may instruct STA1 to remain on the link for a longer period (e.g., not immediately return to listen operation upon detecting an ICF from the OBSS AP). As one possibility, this instruction could be the duration for which STA1 is requested to wait on the link before switching back to listen operation. As another possibility, this instruction could be the number of PPDUs that STA1 needs to decode before switching back to listen operation. This instruction may include an identifier for STA1, such as its AID. In various embodiments, this instruction may be carried in any or all of the announcement, ICF, ICR, or synchronization frames.

[0181] Similarly, protecting TXOPs from hidden node transmissions during CBF probe operations can be important. However, providing NAV protection that takes into account the fact that the radio devices involved in the CBF data frame exchange sequence belong to multiple different BSSs can be challenging. For example, in some implementations, based on baseline NAV rules, ICF / ICR from the shared initiating AP will block ICF / ICR / CBF PPDUs from the shared AP. Similarly, in some implementations, ICF / ICR / CBF PPDUs from the shared AP will block CBF PPDUs from the shared initiating AP. Therefore, as a possibility, certain exceptions to the NAV rules can be implemented for CBF operations. These exceptions in the NAV rules can allow the transmission of ICF, ICR, Sync, and CBF PPDUs such that a PPDU transmitted by one participating device in the CBF does not prevent PPDU transmission from another participating device in the CBF sequence.

[0182] According to some implementation schemes, it can also support Figure 15Fault recovery options for the frame exchange sequence. For example, as a possible fault handling scenario, when the ICR from STA1 fails, AP2 can be configured to abandon its ICF if it does not hear the ICR from STA1. To support this possibility, AP2 can monitor the ICR from STA1. As another possible fault handling scenario, when the ICF from AP2 fails, AP1 can be configured to perform PIFS recovery to transmit the PPDU within the BSS even if AP1 does not detect the ICF from AP2. As a further possible fault handling scenario, when the ICR from STA2 fails, AP2 can use PIFS recovery to notify AP1 of the fault, based on which AP1 can adjust its CBF PPDU (e.g., continue even without STA2). Another possibility for this fault handling scenario could include AP1 directly monitoring the ICR from STA2 and, if not detected, transmitting a non-CBF PPDU instead of a CBF PPDU. Yet another possibility could include continuing the original CBF PPDU even if the ICR from STA2 fails.

[0183] Figure 16Example aspects of another possible frame exchange sequence that can be used for CBF data exchange according to some implementation schemes are illustrated. It is worth noting that, in addition to the announcement / response frames that can be used for CBF scheduling, multi-user ICF / ICR exchange can also be used, for example, for AP2 to indicate its intention to participate in the CBF, for AP1 and AP2 to indicate / select participating STAs (e.g., STA1 and STA2 in the illustrated example), for AP1 and AP2 to negotiate parameters of the CBF PPDU (e.g., preamble settings), and how to schedule BAs. The ICF may include Access Point Identifier information and AID information, such as (BSS_COLOR, AID) tuples, to resolve possible AID conflicts between STA1 and STA2. The ICF may have a unique CBF TA (and / or RA) defined in the wireless communication standard specification, making it easy for STAs to identify / filter it. The ICF may request ICR frames from all participating STAs for NAV protection and check whether the STAs respond. In some implementations, the ICR frame from AP2 may be optional; for example, if AP1 determines that it requests an ICR from AP2 to obtain better NAV protection, AP1 may include a user information field addressed to AP2 in the multi-user ICF. In some implementations, the ICF may be an extended multi-user request-to-transmit (MU-RTS) frame, and the ICR may be a clear-transmit (CTS) frame. Other ICF / ICR formats are also possible. In some implementations, the ICF may assign an AID to STA1 and / or STA2 for decoding the CBF PPDU (e.g., a CBF-specific AID). In the illustrated example, once the multi-user ICF / ICR exchange is complete, AP1 and AP2 may perform concurrent CBF PPDU transmissions, followed by concurrent BA transmissions by STA1 and STA2.

[0184] It can also be used for Figure 16 The illustrated CBF data exchange method provides fault handling techniques. For example, according to some implementations, if no response frame is received from AP2, AP1 can be configured to relinquish the TXOP. If the response frame refuses to share, AP1 can be configured to send its own data or poll another AP to participate in CBF data exchange. If no CTS is received from any STA, AP1 can be configured to relinquish the CBF PPDU, while if any (but not all) CTS is received from any STA, AP1 can be configured to continue CBF PPDU. Other techniques are also possible.

[0185] Figure 17Example aspects of another possible frame exchange sequence for CBF data exchange, according to some implementations, are illustrated. The illustrated exchange sequence allows AP1 to retain the TXOP even if AP2 fails to respond (e.g., due to media busy), and in at least some cases, this can potentially be achieved by making relatively few changes to the eMLSR state machine operation and using synchronization messages. As shown, the advertisement frame in the illustrated example exchange sequence can optionally request a response from STA1 (and / or other APs not illustrated) simultaneously. According to various implementations, this response can be in a TB PPDU (e.g., potentially supporting an ID indicating STA1) or a CTS. As one possibility, the advertisement frame can set a NAV to protect the media until ICF begins. As various possibilities, the response frame can set a NAV to protect the media until ICF, Sync, or CBF PPDU begins. The ICR can be transmitted in a TB PPDU; AP1 may or may not request an ICR from AP2; using a TB PPDU allows AP1 or AP2 to know whether STA2 has responded. The Sync message can indicate the IDs of AP2, STA1, and / or STA2, allowing AP1 (or AP2) to know whether STA2 has responded. Furthermore, at least according to some implementations, using the IDs in the Sync message allows STA1 and STA2 to remain on the link instead of switching back to listening operation (e.g., based on 802.11be eMLSR rules).

[0186] Figure 18 Example aspects of another possible frame switching sequence that can be used for CBF data exchange, according to some implementation schemes, are illustrated. As shown in the figure, similar to... Figure 17In certain scenarios, announcement / response frame exchange can help AP1 determine whether AP2 and / or one or more other (not shown) APs have requested to join coordinated beamforming. Depending on the implementation, the response may be in a non-HT (dup) PPDU or a TB PPDU. In some cases, it is not necessary to exchange announcement / response frames as part of the frame exchange sequence, for example, where APs can exchange such information using wired or other backhaul links. In some implementations, NAV protection for each AP's ICF may be set according to the AP-specific implementation, as is possible in various ways, such as potentially up to the next ICF frame, Sync frame, the start of a CBF PPDU, or the end of a BA transmission. At least according to some implementations, it is possible that the specification supports at least a "long" NAV option (e.g., spanning the entire frame exchange sequence to the end), for example, to facilitate more reliable coordinated beamforming operation when hidden nodes are present or may be present. In some implementations, this may apply not only to eMLSR or Dynamic Power Saving (DPS) STAs, but also to non-eMLSR, non-DPS STAs. Either AP1 or AP2 may transmit a Sync frame before the CBF PPDU via SIFS, depending on which AP's clock is used for CFO correction before the CBF PPDU. In this case, AP1 may indicate in the advertisement frame and / or ICF frame whether the Sync frame is transmitted by itself or by AP2. If the advertisement frame includes a third AP in addition to AP2, the ICF frame from AP1 may also indicate which AP is selected for CBF PPDU transmission by including the ID of AP2 or the ID of the third AP.

[0187] In at least some cases, after the first ICF indicates the duration for which STA1 will wait on the link, it can be specified that AP1 should not attempt to transmit to STA1 on a different link during that duration (e.g., even if STA1 is a multi-link operating (MLO) STA). As a possibility, when calculating the delay for STA1 to switch from frame switching to listen operation, AP1 can consider that duration along with the link switching delay for eMLSR or eMLMR operation. A similar approach can be applied to AP2 and STA2: in at least some cases, AP2 can indicate the duration for which STA2 will remain on the link of its PPDU, in which case it can be specified that AP2 should not attempt to transmit to STA2 on a different link during that duration. When using the “long” NAV option, it is possible that either or both of the first or second ICF can set the carrier sensing (CS) requirement subfield to 0, for example, allowing STA1 and / or STA2 to avoid carrier sensing before their response.

[0188] To prevent STA1 and / or STA2 from leaving the primary channel (e.g., for Non-Primary Channel Access (NPCA) as defined according to one or more versions of the IEEE 802.11 specification), it is possible to introduce explicit indications in one or more of the ICF, ICR, advertisement frames, response frames, and / or synchronization frames, for example, to prohibit NPCA based on any of these frames. For example, if any of these frames is a trigger frame, reserved fields defined for trigger frames in IEEE 802.11be can be used for such indications. Similarly, if any of these frames is a multi-STA block Ack frame, reserved fields defined for multi-STA block Ack frames in IEEE 802.11be can be used for such indications.

[0189] According to some implementations, similar frame-switching sequences can be used to support Coordinated Spatial Multiplexing (C-SR) communication. In a C-SR scenario, it is possible that two (or more) APs within communication range can coordinate to communicate with their respective associated STAs, where each AP's associated STA is sufficiently far from (or otherwise protected from) the other AP to be relatively unaffected by interference from the other AP. Therefore, at least according to some implementations, C-SR can differ from CBF because the coordinating APs do not send null signals.

[0190] Figure 19Example aspects of a possible frame exchange sequence for C-SR data exchange according to some implementations are illustrated. As shown, AP1 (“share initiator”) and AP2 (“shared”) (and possibly one or more potential participating STAs) can exchange announcement / response frames that can be used for C-SR scheduling, for example, for AP2 to indicate its intention to participate in C-SR, for AP1 and AP2 to indicate / select participating STAs (e.g., STA1 and STA2 in the illustrated example), for AP1 and AP2 to negotiate parameters of the C-SR PPDU, how to schedule BAs, etc. One or more multi-user ICF / ICR exchanges can be used, for example, for AP1 and AP2 to request ICR frames from all participating STAs for NAV protection and to check whether the STAs respond. In some implementations, ICR frames from AP2 in response to an ICF from AP1 and ICR frames from AP1 in response to an ICF from AP2 can be optional; for example, if AP1 determines that it is requesting an ICR from AP2 to obtain better NAV protection, AP1 may include a user information field addressed to AP2 in the multi-user ICF. In some implementations, the ICF can be an extended Multi-User Request Transmission (MU-RTS) frame, and the ICR can be a Clear Transmission (CTS) frame. Other ICF / ICR formats are also possible. In the illustrated example, once the multi-user ICF / ICR exchange is complete, AP1 can send a synchronization frame (e.g., to confirm which APs / STAs are participating in the C-SR data frame, to provide final configuration details of the data frame and / or the corresponding BlockAck frame, etc.), and AP1 and AP2 can perform concurrent C-SR PPDU transmissions, followed by concurrent BA transmissions from STA1 and STA2.

[0191] As previously mentioned, for C-SR, it's possible that STA2 is not within range of AP1 and STA1 is not within range of AP2. Considering this, to enable AP2 to determine when to send its ICF, it's possible that AP2 decodes the duration indication in the ICF from AP1 (e.g., using the duration field or UL length subfield in the ICF) and determines the start time for its ICF transmission based on that indication. Alternatively, if requested by an ICF frame from AP1, AP2 may respond to the ICF with its own ICR based on that request and send its ICF after a configured time amount (e.g., SIFS). A similar approach can be used to enable AP1 to determine when to send a synchronization frame. For example, AP1 may decode the duration indication from AP2 (e.g., using the duration field or UL length subfield in the ICF) and determine the start time for the synchronization frame transmission based on that indication. As another possibility, if AP1 receives a request from AP2 via an ICF frame, it can respond to the ICF with its own ICR based on that request and send a synchronization frame after a configured amount of time (e.g., SIFS). It should be noted that while the same start time can be used to send C-SR PPDU frames (e.g., as illustrated in the figure), in some implementations, a configured offset can also be used between the start times of the C-SR PPDUs (e.g., as a possibility, corresponding to the preamble length of the C-SR PPDU).

[0192] Figure 20Further example aspects of possible C-SR data frame exchange sequences according to some implementation schemes are illustrated. In some implementation schemes, it is possible that one of these APs determines to transmit to a STA operating according to a different version of the wireless communication standard (e.g., a "legacy" version) than another AP determines to transmit to it. For example, as a possibility, one AP may determine to serve a "legacy" 802.11be STA, while another AP determines to serve an 802.11bn UHR STA. To support this scenario, it is possible that whether service is being provided to a legacy STA can be indicated in one or more of the following: advertisement frames, response frames, ICF, ICR, or synchronization frames. As shown, it is possible that either of these APs (e.g., AP1 or AP2) can send a synchronization frame. It should be noted that it is still possible that only one of these APs sends the synchronization frame, and the AP sending the synchronization frame is implicitly or explicitly determined based on which AP is providing its C-SR PPDU to the legacy STA. For example, an AP providing its C-SR PPDU to a legacy STA can also be an AP sending a synchronization frame; at least according to some implementations, this can help keep the legacy STA on the link and prevent it from missing subsequent C-SR PPDUs due to returning to eMLSR listening operations. As is possible, the synchronization frame can be a trigger frame or a CTS-to-self frame.

[0193] In some implementations, C-SR PPDUs from one AP to a traditional STA and C-SR PPDUs from another AP to a UHRSTA may be aligned in start time, length, and content in the L-STF, L-LFT, and L-SIG portions of their preambles so that nearby devices can reliably decode the length of the C-SR transmission. Although in Figure 19 In the example scenario, these BAs are exemplified as being sent concurrently after the C-SR PPDU, but in other implementations, these BAs can be sent in an interleaved manner, such as... Figure 24 Option 2 is shown. To assist the legacy STA in transmitting its BA in this situation, at least according to some implementations, the AP transmitting the C-SR PPDU to the legacy STA may request the BA from the legacy STA in the C-SR PPDU or in a BAR frame following the C-SR PPDU, such that the transmission of the BA from the legacy STA occurs before the transmission of the BA from the UHR STA.

[0194] It should be noted that other C-SR data frame exchange sequence designs are also possible. Figure 21Another possible configuration of this kind is illustrated. As shown in the example scenario, AP1 and AP2 can simultaneously send ICF and ICF' frames to request ICR and ICR' frames from STA1 and STA2, respectively. Depending on one possible design, the ICF and ICF' frames may have different content; for example, the ICF may be for STA1 only, while the ICF' may be for STA2 only. Since STA1 is not within range of AP2 and STA2 is not within range of AP1, it is possible, at least in some implementations, that STAs can decode and respond to the ICF and ICF' frames without significant interference. However, in this scenario, it is also possible that other STAs (e.g., within range of both AP1 and AP2) may be unable to decode the ICF and / or ICF', and in some cases, this may disrupt the C-SR sequence accordingly. To reduce the probability of this possibility, a design may also be adopted where the ICF and ICF' have the same content, such as including (BSS_COLOR and AID) tuples to identify both STA1 and STA2, and using special TA and / or RA to indicate that these frames are for C-SR. According to at least some implementations, such methods could potentially provide better NAV protection, although potentially at the cost of greater complexity.

[0195] NAV control for various possible CBF (and potential C-SR) scenarios, such as Figure 22 As shown, as one possibility, a notification frame can protect the NAV until the multi-user ICF begins. As another possibility, a response frame can protect the NAV until the multi-user ICF begins. The multi-user ICF can protect the NAV until the BA ends. The remaining frames (e.g., response, ICR, CBF / C-SRPPDU, BA) can inherit baseline rules to derive the NAV, for example, including deriving the duration from previous frames.

[0196] As another possibility, such as Figure 23 As shown, the notification frame protects the NAV until the ICF begins, the notification frame indicates the start time of the CBF / C-SR PPDU, and the response frame protects the NAV until the CBF / C-SR PPDU begins, which can be derived at least in part based on the start time indicated in the notification frame. In this case, AP2 may not utilize the ICR to respond to the multi-user ICF. The remaining frames (e.g., response, ICR, CBF / C-SR PPDU, BA) can inherit baseline rules to derive the NAV, for example, including deriving the duration from previous frames.

[0197] The security of the CBF message exchange sequence can be handled in any of a few possible ways. As one option, the response frame can carry a fingerprint, which STA2 can decode and verify (e.g., using the key between AP2 and STA2 for Message Integrity Check (MIC) value verification via low-power radio), and only respond to subsequent multi-user ICFs if verification is successful. Alternatively, the response frame can carry a similarly constructed fingerprint, which AP2 can replay in subsequent multi-user ICFs; STA2 can use the key between AP2 and STA2 to verify the fingerprint received in the multi-user ICF to determine whether to respond with an ICR. Another possibility is that a shared key can be defined across the two BSSs. AP1 can use this shared key to add a fingerprint to the multi-user ICF. STA1 and STA2 can use this shared key to verify the multi-user ICF and determine whether to respond with an ICR. Other security techniques are also possible.

[0198] According to some implementations, CBF support can be configured such that CBF PPDUs need to have the same bandwidth. This helps reduce implementation complexity, for example, by avoiding the need for different tone planning or more complex joint probe operations (where additional probes are required to obtain beamforming feedback for the additional bandwidth covered only by one of these APs), and by avoiding APs needing to perform zeroing on some bandwidths but not others. Similarly, it may be possible to specify that concurrent CBF PPDUs use the same punching pattern (e.g., according to the wireless communication standards followed by the APs and STAs in the communication system), for similar reasons of reducing implementation complexity. Alternatively, as described below, at least some of these techniques may also be supported in some implementations.

[0199] Depending on the implementation scheme, there are several options for how to perform BA transmission for CBF data exchange operations. As one option, BAs can be transmitted in parallel using Orthogonal Frequency Division Multiple Access (OFDMA) technology, for example, as... Figure 24 As illustrated in "Option 1". In this case, if one CBF PPDU does not request a BA, another BA can be configured to occupy the full bandwidth for a SIFS burst, for example, to maintain control of the radio medium. In some implementations, a longer guard interval (GI) (e.g., as a possibility, 3.2 ms) and / or MCS0 can be used. As another option, interleaved BA transmissions can be performed, for example, as... Figure 24 As illustrated in "Option 2" (e.g., where the BAR frame can be optional). In this case, the eMLSR state machine operation can be modified to support remaining on the link rather than returning to listen mode until the BA transmission is complete, for example in Figure 24In the scenario where STA2 is an eMLSR STA, as various possibilities exist, the indication for STA1 or multiple STAs to remain on the link instead of returning to listen mode until the BA can be carried in a previous announcement, response, ICF, or CBF PPDU. In some implementations, the first BAR (if present) and the first BA can instruct STA2 to avoid NPCA. Depending on various implementations, the indication to avoid NPCA can include using a short NAV or an explicit indication. In some cases, it can also be specified that AP2 should not send to STA2 on a different link for the duration of the previous PPDU indication from AP2. Figure 24 In the illustrated option 3, possibly an extension of option 1, AP1 can request a BA for both APs via OFDMA. AP1 can then transmit STA2's BA information to AP1, for example, using over-the-air or backhaul communication. In this case, the BAR frame can also be embedded as an embedded trigger frame in the CBF PPDU, similar to option 1. Figure 24 In the illustrated option 4, which may be an extension of option 2, interleaved BA transmissions can be triggered across BSS (e.g., MU-BAR as a possibility; other types of BARs are also possible). In this case, at least according to some implementations, the first BAR frame may need to include the IDs of STA1 and STA2 so that STA2 does not return to eMLSR listening operations.

[0200] In some implementations, options 1 and 3 may be more efficient in terms of call duration and may require fewer changes to non-APSTA operations; the corresponding BA can be requested in an OFDMA manner using the embedded trigger frame in each CBF PPDU. If the first CBF PPDU needs to respond to the BA, but the second CBF PPDU does not, the requested BA can be configured to occupy the full bandwidth of the CBF PPDU, for example, if additional frame switching is expected after the BA (e.g., for a SIFS burst after the BA).

[0201] In at least some implementations, aligning at least a portion of the preamble (content) of the CBF PPDU (e.g., similar to a PPDU within the CBF probe phase) may be important, for example, to enable bystander STAs to decode it for either traditional or new functionality. Thus, for example, it's possible that the CBF PPDU transmitted by the AP includes a non-beamforming (omnidirectional broadcast) PHY preamble portion and a spatially nulled beamforming portion. To support this alignment of the omnidirectional broadcast PHY preamble portion, techniques for unifying BSS_COLOR and STA_ID settings can be provided, particularly to handle scenarios where STA1 and STA2 may have the same AID. Figure 25This highlights various aspects of the potential challenges in the design of CBF data exchange sequences according to some implementation schemes.

[0202] As an option, a special STA_ID can be defined for the STA of the shared AP during CBF in the wireless communication standard specification. Figure 26 Example aspects of possible scenarios in which such methods are used according to some implementation schemes are illustrated. In scenarios where the maximum number of concurrent service STAs of the shared AP is bounded (e.g., 3 in the illustrated example; other numbers are also possible), the specification may assign certain special STA_IDs to the STAs of the shared AP (e.g., 2042-2044 in the illustrated example; other ranges or sets are also possible). In the illustrated example, this may be in a second ICF or synchronization frame, or possibly in a multi-user ICF (e.g., as described herein). Figure 16 As in the scenario described in the image and several other diagrams, an alternative AID is assigned to STA2. According to some implementations, the same frame may also assign BSS_COLOR to STA2 to monitor CBF operations.

[0203] As another possibility, the resource unit (RU) allocation in the PHY signaling can be extended for CBF based on BSS_COLOR+STA_ID, while inheriting other existing multi-user multiple-input multiple-output (MU-MIMO) rules. In various implementations, BSS_COLOR can be 6 bits (e.g., to indicate the full BSS_COLOR value), or it may be only 1 bit (e.g., as a possibility, to indicate "shared initiating AP" or "shared AP"). Figure 27 Example aspects of possible scenarios in which such methods are used according to some implementation schemes are illustrated. As shown in the figure, a flag can be set to indicate a CBF PPDU, and for a CBF PPDU, an enhanced user field with BSS_COLOR information can be provided; if the flag does not indicate a CBF PPDU, a non-CBF format can be used for the user field.

[0204] As an alternative, the first content channel can carry RU allocation for one BSS, and the second content channel can carry RU allocation for another BSS. This approach may be simpler to implement and has lower overhead. However, in this case, the number of shared APs may be limited by bandwidth; for example, for 20MHz, CBF may not be allowed if this method is used; for 40MHz and above, at least in some implementations, it is possible to configure one shared AP for one CBF. Figure 28Example aspects of possible scenarios using such methods according to some implementation schemes are illustrated. As shown, a flag can be set to indicate that a CBF PPDU is being deployed using a special content channel. Then, a first content channel can carry the RU allocation of the shared initiating AP, and a second content channel can carry the RU allocation of the shared AP. At least in some implementation schemes, an explicit BSS_COLOR indication can be provided in a common field.

[0205] Figure 29 Examples of implementation schemes available for use are shown. Figures 27 to 28 Further details of the possible PPDU signaling formats for one or more of the methods are provided. As shown, a CBF PPDU type indication can be provided; for example, one bit can be added to the PPDU type to signal the CBF PPDU (e.g., the PPDU type field can be combined with the adjacent authentication bit B25 in U-SIG1). For example, B25 in U_SIG1 can be set to 0 to indicate a CBF PPDU; B0-B1 can be combined with B25 in U_SIG1 to indicate a Coordinated Spatial Multiplexing (CSR) or Partial Bandwidth CBF PPDU. Another option ( Figure 29 (Not shown in the image) may include combining the PPDU type field with B2 in U_SIG2 for use as a PPDU type indicator.

[0206] For a shared AP, the BSS color code field can be set to the BSS color code of the initiating AP. As an option, the BSS color code of the shared AP can be signaled in the common field of the UHR-SIG. In some implementations, it can be assumed that spatial multiplexing on the CBF PPDU is not allowed; in this case, a 4-bit spatial multiplexing field can be combined with 2 ignored bits for the BSS color code of the shared AP. Some reconfiguration of the field is also possible in this case. The total number of users in the CBF PPDU can also be indicated, possibly reducing the number of bits used for this indication to 2 bits to accommodate a maximum of 4 users. Figures 30 to 31 Example aspects of this possible PHY signaling format method for the U-SIG1 and UHR-SIG common fields for non-OFDMA CBF transmission are illustrated according to some implementation schemes.

[0207] Figure 32 Another aspect of a possible PHY signaling format approach is illustrated, in which two APs can be signaled with BSS color codes. As shown, the BSS color code field can be set to share the BSS color code of the initiating AP. According to some implementations, 6 bits of ignore and verification bits in U-SIG can be used to indicate the BSS color code of the shared AP, such as B20-B25.

[0208] Figure 33Examples of possible PHY signaling format methods, according to some implementation schemes, that can be used to distinguish user fields from different APs, such as those used for combining... Figure 27 The example methods illustrated and described herein are used. As shown, a 1-bit explicit indication can be provided in the user field to signal that the CBF PPDU used for MU-MIMO uses the user field format. Reserved bits (e.g., B20 in the illustrated example) can indicate which AP the signaling STA is associated with; for example, B20 can be set to 0 to indicate that the STA signaling by that user field is associated with the sharing initiating AP, while B20 can be set to 1 to indicate that the STA signaling by that user field is associated with the shared AP.

[0209] As mentioned earlier in this article, in some implementations, partial bandwidth CBF can be supported. Figure 34 Example aspects of such a possible scenario according to some implementation schemes are illustrated, where CBF PPDU transmission is performed on the primary bandwidth channel from two APs, and CBF PPDU transmission is performed on the secondary bandwidth channel from one of the APs. In some cases, it is possible that such partial BW CBF is supported only for PPDU BWs equal to or greater than 160MHz. Partial BW CBF can be performed on the primary half of the bandwidth, while the secondary half of the bandwidth is utilized by only one AP and is limited to a single RU allocated to a single user. Figure 35 Examples of possible UHR-SIG user fields for OFDMA transmissions used in such partial BW CBF operations are illustrated according to some embodiments. In some embodiments, it is possible that preamble puncturing is not used for the second half of the bandwidth. For partial bandwidth CBF, it is possible that the second half of the bandwidth can only be used by the sharing initiating AP, although this restriction may not be enforced in other embodiments. The sharing initiating AP can be the TXOP initiator, so it is possible that the shared AP cannot add bandwidth for that TXOP. The user field of the CBF PPDU can be in non-OFDMA format. However, for partial BW CBF PPDU, it is possible that the user field of the STA allocated to the second half of the BW uses OFDMA format. At least in some embodiments, the bandwidth of U-SIG can be the entire BW.

[0210] In some implementations, B0-B2 in U-SIG2 can be used to indicate a partial bandwidth CBF PPDU. For example, in Figure 36 In the illustrated U-SIG format, PPDU type 000 can be used to indicate a full-bandwidth CBF PPDU, and type 010 can be used to indicate a partial-bandwidth CBF PPDU. Other formats may also be used. In some implementations, formats such as... Figure 31The illustrated UHR-SIG common field is used for non-OFDMA transmission. In some implementations, the UHR-SIG common field for OFDMA transmission can be used if preamble puncturing is supported; it is also possible that preamble puncturing is not supported. In some implementations, the user field of the STA allocated to the second half of the bandwidth shared by the initiating AP can be in OFDMA format and can be placed as the last user information field. Therefore, if B17-18 in the UHR-SIG common field indicates N users, then at least in some cases, the first N user fields can be in MU-MIMO format, and the N+1 user field can be in OFDMA format. For a partial bandwidth CBF PPDU, the UHR-SIG field can be the same as that of a full bandwidth CBF PPDU, except for the additional user field at the end.

[0211] As an alternative to signaling the transmission of a partial bandwidth CBF PPDU, 2 bits in the UHR SIG common field can be used to indicate a partial BW CBF PPDU; this can support the use of a secondary bandwidth channel by either the initiating AP or the AP being shared. For example, it can be used... Figure 37 The illustrated UHR SIG common field format, where B19-B20 values ​​of 00 indicate a full-bandwidth CBF PPDU, 01 indicate a partial-bandwidth CBF PPDU, where the sharing initiating AP uses the secondary channel for another user and the shared AP uses only the primary channel for CBF, and 10 indicates a partial-bandwidth CBF PPDU, where the shared AP uses the secondary channel for another user and the sharing initiating AP uses only the primary channel for CBF. At least in some implementations, if any AP is using the secondary channel for an OFDMA user, the last user field of the corresponding AP can be used for the OFDMA user on the bandwidth secondary channel, and this user field can be in OFDMA format.

[0212] It should be noted that, at least according to some implementation schemes, some or all of the techniques described herein for performing CBF data phase communication can also be applied to other multi-AP communication schemes, such as coordinating spatial multiplexing (e.g., as described herein in conjunction with...). Figures 19 to 21 (As described) and joint transmission (where two APs transmit concurrently). For example, at least according to some implementations, any or all of the frame exchange sequences, eMLSR state machine configuration techniques, NAV settings, fault recovery, acknowledgment procedures, security, and / or options for CBF PPDU alignment described herein may also be used or alternatively used in such scenarios.

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

[0214] In addition to the exemplary embodiments described above, further embodiments of this disclosure may be implemented in any of a variety of forms. For example, some embodiments may be implemented as computer-implemented methods, computer-readable storage media, or computer systems. Other embodiments may be implemented using one or more custom-designed hardware devices such as ASICs. Other embodiments may be implemented using one or more programmable hardware elements such as FPGAs.

[0215] In some embodiments, a non-transitory computer-readable storage medium may be configured to store program instructions and / or data, wherein, if executed by a computer system, the program instructions cause the computer system to perform a method, such as any method embodiment of the method embodiments described herein, or any combination of method embodiments described herein, or any subset or combination of any such subset of any method embodiments described herein.

[0216] In some implementations, the device (e.g., AP 104 or STA 106) may be configured to include a processor (or a set of processors) and a memory medium, wherein the memory medium stores program instructions, and the processor is configured to read from the memory medium and execute the program instructions, wherein the program instructions are executable to implement any method implementation (or any combination of method implementations described herein, or any subset of any method implementations described herein, or any combination of such subsets) of the various method implementations described herein. The device may be implemented in any of a variety of forms.

[0217] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A first access point wireless device, the first access point wireless device comprising: One or more antennas; One or more radio components, said one or more radio components being operatively coupled to said one or more antennas; and A processor, the processor being operatively coupled to the one or more radio components; The first access point wireless device is configured as follows: Sending an Initial Control Frame (ICF) to the second access point wireless device, the ICF initiating a Transmission Opportunity (TXOP) for Coordinated Beamforming (CBF) Probe, wherein the ICF includes an indication of a first duration configured to determine the Network Allocation Vector (NAV); and Receive an initial control response (ICR) from the second access point wireless device, the ICR including an indication of a second duration configured to determine the NAV.

2. The first access point wireless device according to claim 1, wherein the first access point wireless device is further configured to: Perform joint CBF probe frame exchange, wherein the joint CBF probe frame exchange is performed with at least the second access point wireless device and a non-access point wireless device associated with one of the first access point wireless device or the second access point wireless device.

3. The first access point wireless device according to claim 1, wherein the first access point wireless device is further configured to: Perform sequential CBF probe frame exchange, wherein the sequential CBF probe frame exchange is performed with at least the second access point wireless device and a non-access point wireless device associated with one of the first access point wireless device or the second access point wireless device.

4. The first access point wireless device according to claim 1, The first duration indicated in the ICF and the second duration indicated in the ICR are configured to provide NAV protection for multiple CBF probe frame sequences within the TXOP.

5. The first access point wireless device according to claim 1, wherein the first access point wireless device is further configured to: Receive information from the second access point wireless device indicating that one or more error conditions have been detected for the CBF probe.

6. The first access point wireless device of claim 5, wherein the information indicating that one or more error conditions have been detected for the CBF probe is received in one or more of the following: Unsolicited error report frame; A CBF response frame received in response to a CBF announcement frame provided by the first access point wireless device; or ICF.

7. The first access point wireless device of claim 5, wherein the information indicating that one or more error conditions have been detected for the CBF probe further indicates one or more of the following: Error conditions associated with null data packets (NDPs) sent during the CBF probe; Error conditions associated with the beamforming report (BFR) sent during the CBF detection; or This includes address changes of non-access point wireless devices detected by the CBF.

8. The first access point wireless device according to claim 1, wherein the first access point wireless device is further configured to: The receiving wireless device selects to exit CBF operation with the first access point wireless device, wherein the instruction is received using one or more of the following: Management frames; The A-Control field in a data frame or management frame; or Control frame.

9. The first access point wireless device according to claim 1, The first duration indicated in the ICF and the second duration indicated in the ICR are configured to provide NAV protection up to the start of the beamforming report polling (BFRP) frame of the CBF probe frame sequence.

10. A method for operating in wireless communication, the method comprising: The second access point wireless device receives an initial control frame (ICF) from the first access point wireless device. This ICF initiates a transmission opportunity (TXOP) for coordinated beamforming (CBF) detection, wherein the ICF includes an indication of a first duration configured to determine the network allocation vector (NAV); and An initial control response (ICR) is sent from the second access point wireless device to the first access point wireless device, the ICR including an indication of a second duration configured to determine the NAV.

11. The method of claim 10, wherein the method further comprises: The CBF probe frame exchange is performed by the second access point wireless device, wherein the CBF probe frame exchange is performed with at least the first access point wireless device and a non-access point wireless device associated with either the first access point wireless device or the second access point wireless device, wherein the CBF probe frame exchange includes one of the following: Joint CBF probe exchange, wherein the first access point radio device and the second access point radio device concurrently perform null data packet (NDP) transmission; or Sequential CBF probe frame exchange, wherein NDP transmission is performed sequentially by the first access point radio device and the second access point radio device.

12. The method of claim 10, wherein the method further comprises: The second access point wireless device sends information to the first access point wireless device indicating that one or more error conditions were detected during CBF probing. The information indicating that one or more error conditions were detected during CBF probing is sent in one or more of the following ways: Unsolicited error report frame; A CBF response frame sent in response to a CBF announcement frame received from the first access point wireless device; or ICF, The information indicating that one or more error conditions were detected during CBF probing also indicates one or more of the following: Error conditions associated with null data packets (NDPs) sent during the CBF probe; Error conditions associated with the beamforming report (BFR) sent during the CBF detection; or This includes address changes of non-access point wireless devices detected by the CBF.

13. The method of claim 10, wherein the method further comprises: Send an empty data packet (NDP) for the CBF detection, wherein the BSS_COLOR indicator is set to 0 or to the BSS_COLOR value associated with the first access point radio device in the physical layer (PHY) preamble of the NDP for the CBF detection.

14. The method of claim 10, wherein the method further comprises: A beamforming report (BFR) frame is received from a first non-access point wireless device associated with the first access point wireless device, wherein the BSS_COLOR indicator is either set to 0 or set to the BSS_COLOR value associated with the first access point wireless device in the physical layer (PHY) preamble of the BFR frame; and The BFR frame is decoded at least in part based on the BSS_COLOR indicator being set to 0 in the PHY preamble of the BFR frame or being set to the BSS_COLOR value associated with the first access point wireless device.

15. A processor, the processor including a memory, the memory being configured to cause the processor to perform operations including: Receive from an access point wireless device an initial control response (ICR) associated with a transmission opportunity (TXOP) for coordinated beamforming (CBF) detection, including an indication of duration; wherein the access point wireless device is a shared access point wireless device for CBF detection; and The network allocation vector (NAV) for CBF probing is determined at least in part based on the duration indicated in the ICR.

16. The processor of claim 15, wherein the memory is further configured such that the processor performs operations including: The shared access point radio device receives null data packets (NDPs) from the TXOP for CBF detection, wherein the BSS_COLOR indicator is set to 0 in the physical layer (PHY) preamble of the NDP for CBF detection; and The NDP is used to generate beamforming report (BFR) frames for the CBF probe, at least in part based on the BSS_COLOR indicator being set to 0 in the PHY preamble of the NDP, wherein the BSS_COLOR indicator is set to 0 in the PHY preamble of the BFR frame.

17. The processor of claim 15, wherein the memory is further configured such that the processor performs operations including: The shared access point radio device receives null data packets (NDPs) from the TXOP for CBF detection, wherein the BSS_COLOR indicator is set to 0 in the physical layer (PHY) preamble of the NDP for CBF detection; and The NDP is used to generate beamforming report (BFR) frames for the CBF probe, at least in part, based on the BSS_COLOR indicator being set to 0 in the PHY preamble of the NDP, wherein the BSS_COLOR indicator is set to the BSS_COLOR value of the associated access point radio device in the PHY preamble of the BFR frame.

18. The processor of claim 15, wherein the memory is further configured such that the processor performs operations including: The shared access point radio device receives a null data packet (NDP) from the TXOP for the CBF probe, wherein the BSS_COLOR indicator is set to the associated access point radio device's BSS_COLOR value in the physical layer (PHY) preamble of the NDP for the CBF probe; and The NDP generates beamforming report (BFR) frames for the CBF probe at least in part based on the BSS_COLOR indicator being set to the BSS_COLOR value of the associated access point radio device in the PHY preamble of the NDP, wherein the BSS_COLOR indicator is set to the BSS_COLOR value of the associated access point radio device in the PHY preamble of the BFR frame.

19. The processor of claim 15, wherein the memory is further configured such that the processor performs operations including: Generate an instruction to exit the CBF operation.

20. The processor of claim 19, wherein the instruction to select exit CBF operation is included in one or more of the following: Management frames; The A-Control field in a data frame or management frame; or Control frame.

Images