Inter-node communication framework for coordinated wireless node mechanisms

Abstract

Certain aspects of the present disclosure provide a method of wireless communication that can be performed at a first wireless node (e.g., a first access point (AP)). The method can involve establishing a session with a second wireless node (e.g., a second AP) by exchanging information with the second wireless node regarding one or more features of a coordinated communication scheme supported by the first wireless node and the second wireless node.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application No. 19 / 084,558, filed March 19, 2025, which claims the benefit and priority to U.S. Provisional Application No. 63 / 567,895, filed March 20, 2024, each of which is assigned to the assignee of this application and is expressly incorporated herein by reference in its entirety, as fully set forth below and for all applicable purposes. Technical Field

[0003] This disclosure relates in general to wireless communications, and more specifically to coordination mechanisms.

[0004] Related technical descriptions

[0005] A Wireless Local Area Network (WLAN) can be formed by one or more wireless access points (APs) that provide a shared wireless communication medium for use by multiple client devices (also known as wireless stations (STAs)). The basic building block of a WLAN conforming to the IEEE 802.11 family of standards is the Basic Service Set (BSS) managed by the AP. Each BSS is identified by a Basic Service Set Identifier (BSSID) advertised by the AP. The AP periodically broadcasts beacon frames to enable any STA within the AP's wireless range to establish or maintain a communication link with the WLAN. Summary of the Invention

[0006] One aspect provides a method for wireless communication at a first wireless node. The method includes: obtaining a first frame indicating that a second wireless node is capable of supporting a coordinated communication scheme, wherein the first wireless node is associated with a first basic service set (BSS) and the second wireless node is associated with a second BSS; establishing a session with the second wireless node by exchanging information with the second wireless node about one or more features of the coordinated communication scheme supported by the first wireless node and the second wireless node; and participating in the session using the coordinated communication scheme, the participation being based on one or more parameters associated with the exchange of information.

[0007] Other aspects provide: an apparatus operable to, configured to, or otherwise adapted to perform one or more of the methods described herein and / or those elsewhere in the document; a non-transitory computer-readable medium comprising instructions that, when executed by a processor of the apparatus, cause the apparatus to perform the methods described herein and those elsewhere in the document; a computer program product embodied on a computer-readable storage medium comprising: code for performing the methods described herein and those elsewhere in the document; and / or an apparatus comprising components for performing the methods described herein and those elsewhere in the document. By way of example, an apparatus may include a processing system, a device having a processing system, or a processing system cooperating via one or more networks.

[0008] For illustrative purposes, the following description and figures illustrate certain features. Attached Figure Description

[0009] Figure 1 A schematic diagram of an example wireless communication network is shown.

[0010] Figure 2 and Figure 3 An example Protocol Data Unit (PDU) is shown that can be used for communication between a wireless access point (AP) and one or more wireless stations (STA).

[0011] Figure 4 The hierarchical format of an example physical layer PDU (PPDU) that can be used for communication between a wireless AP and one or more wireless STAs is shown.

[0012] Figure 5 A block diagram of an example multi-link device (MLD) deployment is shown.

[0013] Figure 6 An example state diagram of a Coordinated AP (CAP) session is shown, which can also be referred to as a Multi-AP Coordination (MAPC) session.

[0014] Figure 7 A sample call flowchart for establishing a MAPC session is shown according to various aspects of this disclosure.

[0015] Figure 8 An example frame format for exchanging information about features of the MAPC scheme, according to various aspects of this disclosure, is shown.

[0016] Figure 9 Example frames for exchanging information about features of the MAPC scheme according to various aspects of this disclosure are shown.

[0017] Figure 10 Example frames for exchanging information about features of the MAPC scheme according to various aspects of this disclosure are shown.

[0018] Figure 11 An example frame format for exchanging information about features of the MAPC scheme, according to various aspects of this disclosure, is shown.

[0019] Figure 12 An example frame format for exchanging information about features of the MAPC scheme, according to various aspects of this disclosure, is shown.

[0020] Figure 13 A flowchart illustrating example processes that can be performed by a wireless node according to various aspects of this disclosure is shown.

[0021] Figure 14 A block diagram of an example wireless communication device according to various aspects of this disclosure is shown.

[0022] Similar reference numerals and names in the various figures indicate similar elements. Detailed Implementation

[0023] Certain mechanisms can be applied to communication between wireless nodes, such as communication between access points (APs) and non-AP stations (STAs), between APs, and / or between non-AP STAs.

[0024] For example, Ultra High Reliability (UHR) / Wi-Fi 8 may introduce certain Multi-AP Coordination (MAPC) mechanisms, also known as Coordinated AP (CAP) mechanisms, where multiple APs can coordinate in some way to enhance communication. CAP and MAPC are used interchangeably. For example, such mechanisms can allow two or more APs to coordinate their resources in various ways to achieve or improve resource sharing.

[0025] For example, Coordinated Time Division Multiple Access (C-TDMA) can be used to coordinate resources in the time domain, Coordinated Spatial Reuse (C-SR) can be used to coordinate resources in the spatial domain, and Coordinated Listening Interval (CLI) can be used to coordinate access to the radio medium. In this context, CLI may include Coordinated Service Periods (SPs), such as Coordinated Target Wake-Up Time (C-TWT), Coordinated Limited Target Wake-Up Time (C-RTWT), Inter-AP Coordinated Intervals / Periods, Inter-AP Service Intervals / Periods, and AP Coordinated Intervals / Periods. Similarly, Coordinated Beamforming (C-BF) and / or Coordinated Preemption (C-Preemption) can be used to coordinate preemption between adjacent (e.g., friendly) APs. Furthermore, two or more APs may be part of a Multi-Link Device (MLD) (e.g., a Single Mobile Domain (SMD) MLD or a similar central entity) and may provide seamless roaming functionality to associated clients (e.g., non-AP STAs).

[0026] These schemes may involve APs exchanging information with each other. Such communication can occur on the backhaul and therefore does not involve the (802.11) air interface. However, for various reasons (e.g., if inter-vendor interoperability is desired), aspects of this disclosure provide a framework for over-the-air (OTA) communication between APs. UHRs can benefit from this framework for APs to communicate with each other (e.g., exchange information to enable / enhance various MAPC features).

[0027] This disclosure provides techniques and mechanisms for forming a framework for inter-AP communication for MAPC sessions. These techniques and mechanisms can be applied to any coordination feature, including (but not limited to) C-TDMA, C-SR, CLI, C-BF, and / or C-preemption. Therefore, the techniques provided herein can improve resource utilization and overall user experience.

[0028] Example wireless communication network

[0029] Figure 1A schematic diagram of an example wireless communication network 100 is shown. The wireless communication network 100 includes various wireless nodes (such as AP STAs and non-AP STAs). Depending on some aspects, the wireless communication network 100 may be an example of a wireless local area network (WLAN) (such as a Wi-Fi network). For example, the wireless communication network 100 may be a network implementing at least one of the IEEE 802.11 wireless communication protocol standard families (such as those defined by the IEEE 802.11-2020 specification or its revisions, including but not limited to 802.11ay, 802.11ax, 802.11az, 802.11ba, 802.11bd, 802.11be, 802.11bf, and 802.11bn). In some other examples, the wireless communication network 100 may be an example of a cellular radio access network (RAN), such as a 5G RAN or 6G RAN implementing one or more cellular protocols (such as those specified in one or more 3GPP standards). In some other examples, the wireless communication network 100 may include a WLAN that operates in an interoperable or converged manner with one or more cellular RANs to provide greater or enhanced network coverage to wireless communication devices within the wireless communication network 100, or to enable these devices to connect to the core of the cellular network, such as to access network management capabilities and functionality provided by the cellular network core.

[0030] Wireless communication network 100 may include numerous wireless communication devices, such as at least one wireless access point (AP) 102 and any number of wireless stations (STA) 104. Although Figure 1 Only one AP 102 is shown, but the wireless communication network 100 may include multiple APs 102. AP 102 may be or represent various different types of network entities, including but not limited to home networking APs, enterprise APs, single-band APs, dual-band synchronous (DBS) APs, tri-band synchronous (TBS) APs, standalone APs, non-standalone APs, software-enabled APs (software APs), and multi-link APs (also known as AP multi-link devices (MLDs)), as well as cellular (such as 3GPP, 4G LTE, 5G, or 6G) base stations or other cellular network nodes (such as Node B, evolved Node B (eNB), gNB, Transmit Receive Point (TRP)) or another type of equipment or apparatus included in the radio access network (RAN), including open RAN (O-RAN) network entities such as central units (CUs), distributed units (DUs), or radio units (RUs).

[0031] Each STA 104 may also be referred to as a mobile station (MS), mobile device, mobile phone, wireless phone, access terminal (AT), user equipment (UE), subscriber station (SS), or subscriber unit, etc. STA 104 can represent a variety of devices such as mobile phones, other handheld or wearable communication devices, netbooks, laptops, tablets, laptops, Chromebooks, augmented reality (AR), virtual reality (VR), mixed reality (MR), or extended reality (XR) wireless headsets or other peripherals, wireless earbuds, other wearable devices, display devices (e.g., televisions, computer monitors, or video game consoles), video game controllers, navigation systems, music or other audio or stereo devices, remote control devices, printers, kitchen appliances (including smart refrigerators) or other home appliances, remote keys (e.g., for passive keyless entry and start (PKES) systems), Internet of Things (IoT) devices, vehicles, etc.

[0032] A single AP 102 and its associated set of STA 104s may be referred to as a Basic Service Set (BSS), which is managed by the respective AP 102. Figure 1 Additionally, an example coverage area 108 of AP 102 is shown, which may represent the Basic Service Area (BSA) of wireless communication network 100. The BSA can be identified by STA 104 and other devices via a Service Set Identifier (SSID) and a Basic Service Set Identifier (BSSID), which may be the Media Access Control (MAC) address of AP 102. AP 102 may periodically broadcast beacon frames (“beacons”) including the BSSID to enable any STA 104 within the wireless range of AP 102 to “associate” or reassociate with AP 102 to establish or maintain a corresponding communication link 106 (also referred to hereinafter as a “Wi-Fi link”) with AP 102. For example, the beacon may include an identifier or indication of the primary channel used by the corresponding AP 102, and a Timing Synchronization Function (TSF) for establishing or maintaining timing synchronization with AP 102. AP 102 can provide access to external networks to each STA 104 in the wireless communication network 100 via the corresponding communication link 106.

[0033] To establish a communication link 106 with AP 102, each STA 104 is configured to perform a passive or active scanning operation (“scan”) on frequency channels in one or more frequency bands (e.g., 2.4 GHz, 5 GHz, 6 GHz, 45 GHz, or 60 GHz bands). To perform a passive scan, STA 104 listens for beacons transmitted by the corresponding AP 102 at periodic time intervals (referred to as the Target Beacon Transmission Time (TBTT)). To perform an active scan, STA 104 generates probe requests and transmits these requests sequentially on each channel to be scanned, and listens for probe responses from AP 102. Each STA 104 can identify, determine, detect, or select an AP 102 to associate with based on the scanning information obtained through passive or active scanning, and performs authentication and association operations to establish a communication link 106 with the selected AP 102. The selected AP 102 assigns an association identifier (AID) to STA 104 at the end of the association operation, and AP 102 uses the association identifier (AID) to track STA 104.

[0034] As wireless networks become increasingly prevalent, STA 104 may have the opportunity to choose from one of many BSSs within its range or from multiple APs 102 that together form an Extended Service Set (ESS) (comprising multiple connected BSSs). For example, wireless communication network 100 may be connected to a wired or wireless distribution system capable of connecting multiple APs 102 in such an ESS. Therefore, STA 104 may be covered by more than one AP 102 and may be associated with different APs 102 at different times for different transmissions. Additionally, after associating with an AP 102, STA 104 may periodically scan its surroundings to find a more suitable AP 102 to associate with. For example, STA 104 moving relative to its associated AP 102 may perform a “roaming” scan to find another AP 102 with more desirable network characteristics, such as a larger Received Signal Strength Indicator (RSSI) or reduced traffic load.

[0035] In some cases, STA 104 can form a network without AP 102 or other equipment besides STA 104 itself. An example of such a network is an ad hoc network (or wireless ad hoc network). Ad hoc networks may also be referred to as mesh networks or peer-to-peer (P2P) networks. In some cases, ad hoc networks can be implemented within a larger network, such as wireless communication network 100. In such examples, while STA 104 may be able to communicate with each other via communication link 106 through AP 102, STA 104 may also communicate directly with each other via direct wireless communication link 110. Additionally, two STA 104 may communicate via direct communication link 110, regardless of whether the two STA 104 are associated with and served by the same AP 102. In such ad hoc systems, one or more STAs among STA 104 may assume the role played by AP 102 in the BSS. Such STA 104 may be referred to as the group owner (GO) and may coordinate transmissions within the ad hoc network. Examples of direct wireless communication links 110 include Wi-Fi direct connections, connections established by using Wi-Fi Tunneling Direct Link Establishment (TDLS) links, and other P2P group connections.

[0036] In some networks, AP 102 or STA 104, or both, can support applications associated with high throughput or low latency requirements, or provide lossless audio to one or more other devices. For example, AP 102 or STA 104 can support applications and use cases associated with ultra-low latency (ULL), such as ULL gaming, or streaming lossless audio and video to one or more personal audio devices (such as peripherals) or AR / VR / MR / XR headsets. In scenarios where a user uses two or more peripherals, AP 102 or STA 104 can support extended personal audio networks that enable communication with these two or more peripherals. Additionally, AP 102 and STA 104 can support additional ULL applications with ULL and high throughput requirements, such as cloud-based applications (such as VR cloud gaming).

[0037] As indicated above, in some implementations, AP 102 and STA 104 may operate and communicate according to one or more of the IEEE 802.11 wireless communication protocol family of standards (via the corresponding communication link 106). These standards define WLAN radio and baseband protocols for the physical (PHY) layer and MAC layer. AP 102 and STA 104 transmit and receive wireless communications to and from each other in the form of PHY Protocol Data Units (PPDUs) (also referred to below as "Wi-Fi communication" or "wireless packets").

[0038] Each PPDU is a composite structure comprising a PHY preamble and a payload in the form of a PHY Service Data Unit (PSDU). The information provided in the preamble can be used by the receiving device to decode subsequent data in the PSDU. In instances where the PPDU is transmitted on a bound channel or a wideband channel, the preamble field may be copied and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble can be used for other purposes such as packet detection, automatic gain control, and channel estimation. The legacy preamble is also typically used to maintain compatibility with legacy equipment. The format, decoding, and information provided in the non-legacy portion of the preamble are associated with the specific IEEE 802.11 wireless communication protocol to be used to transmit the payload.

[0039] AP 102 and STA 104 in WLAN 100 can transmit PPDUs on unlicensed spectrum, which can be a portion of the spectrum including bands traditionally used by Wi-Fi technologies, such as the 2.4 GHz band, 5 GHz band, 6 GHz band, 45 GHz band, and 60 GHz band. Some examples of AP 102 and STA 104 described herein can also communicate in other bands that can support both licensed and unlicensed communication. For example, AP 102 or STA 104, or both, may also be able to communicate on licensed operating bands, where multiple operators may have corresponding licenses to operate in the same or overlapping frequency ranges. Such licensed operating frequency bands may be specified or associated with frequency ranges mapped to or associated with FR1 (410MHz to 7.125GHz), FR2 (24.25GHz to 52.6GHz), FR3 (7.125GHz to 24.25GHz), FR4a or FR4-1 (52.6GHz to 71GHz), FR4 (52.6GHz to 114.25GHz), and FR5 (114.25GHz to 300GHz).

[0040] Each of these frequency bands may include multiple sub-bands and frequency channels (also referred to as sub-channels). For example, PPDUs conforming to revisions of the IEEE 802.11n, 802.11ac, 802.11ax, 802.11be, and 802.11bn standards may be transmitted on one or more of the 2.4 GHz, 5 GHz, or 6 GHz frequency bands, each of which is divided into multiple 20 MHz channels. Therefore, these PPDUs are transmitted on physical channels with a minimum bandwidth of 20 MHz, but larger channels can be formed through channel bonding. For example, PPDUs may be transmitted on physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, 240 MHz, 320 MHz, 480 MHz, or 640 MHz by bonding multiple 20 MHz channels together.

[0041] Figure 2 An example Protocol Data Unit (PDU) 200 is shown that can be used for wireless communication between a wireless AP 102 and one or more wireless STAs 104. For example, the PDU 200 can be configured as a PPDU. As shown, the PDU 200 includes a PHY preamble 202 and a PHY payload 204. For example, the preamble 202 may include a legacy portion, which itself includes a legacy short training field (L-STF) 206 consisting of two symbols, a legacy long training field (L-LTF) 208 consisting of two symbols, and a legacy signal field (L-SIG) 210 consisting of two symbols. The legacy portion of the preamble 202 can be configured according to the IEEE 802.11a wireless communication protocol standard. The preamble 202 may also include a non-legacy portion, which includes one or more non-legacy fields 212, for example, conforming to one or more of the IEEE 802.11 series of wireless communication protocol standards.

[0042] L-STF 206 generally enables the receiving device to perform coarse timing and frequency tracking, as well as automatic gain control (AGC). L-LTF 208 generally enables the receiving device to perform fine timing and frequency tracking, and also to perform initial estimation of the radio channel. L-SIG 210 generally enables the receiving device to determine (e.g., acquire, select, identify, detect, determine, calculate, or compute) the duration of the PDU and use the determined duration to avoid transmission over the PDU. The legacy portion of the preamble can be modulated according to a binary phase shift keying (BPSK) modulation scheme, including L-STF 206, L-LTF 208, and L-SIG 210. The payload 204 can be modulated according to a BPSK modulation scheme, a quadrature BPSK (Q-BPSK) modulation scheme, a quadrature amplitude modulation (QAM) modulation scheme, or another suitable modulation scheme. Payload 204 may include a PSDU containing a data field (DATA) 214, which in turn may carry higher-level data in the form of, for example, MAC Protocol Data Unit (MPDU) or Aggregated MPDU (A-MPDU).

[0043] Figure 3 An example physical layer (PHY) protocol data unit (PPDU) 350 capable of being used for communication between a wireless AP and one or more wireless STAs is shown. For example, the AP and STA can be reference... Figure 1Examples of AP 102 and STA 104 are described below. As shown, PPDU 350 includes a PHY preamble (which includes a legacy portion 352 and a non-legacy portion 354) and a payload 356 (which includes a data field 374). The legacy portion 352 of the preamble includes L-STF 358, L-LTF 360, and L-SIG 362. The non-legacy portion 354 of the preamble includes a repetition of L-SIG (RL-SIG) 364 and multiple wireless communication protocol version-related signal fields following RL-SIG 364. For example, the non-legacy portion 354 may include a general signal field 366 (referred to herein as "U-SIG 366") and an EHT signal field 368 (referred to herein as "EHT-SIG 368"). The presence of RL-SIG 364 and U-SIG366 indicates to STA 104, which is EHT compliant or later, that PPDU 350 is an EHT PPDU or any later (post-EHT) version of a PPDU conforming to a new wireless communication protocol (conforming to the future IEEE 802.11 wireless communication protocol standard). One or both of U-SIG366 and EHT-SIG 368 can be constructed as other wireless communication protocol versions associated with revisions to the IEEE series of standards above EHT and carry version-related information for those protocol versions. For example, U-SIG 366 can be used by receiving devices (such as AP 102 and STA 104) to interpret bits in one or more of EHT-SIG 368 or data field 374. Similar to L-STF 358, L-LTF 360, and L-SIG 362, in instances involving the use of bound channels, the information in U-SIG 366 and EHT-SIG 368 can be repeated and transmitted in each of the component 20MHz channels.

[0044] The non-legacy portion 354 also includes an additional short training field 370 (referred to herein as "EHT-STF 370," but which can be constructed for other wireless communication protocol versions above EHT and carries version-related information for those protocols) and one or more additional long training fields 372 (referred to herein as "EHT-LTF 372," but which can be constructed for other wireless communication protocol versions above EHT and carry version-related information for those protocols). EHT-STF 370 can be used for timing and frequency tracking and AGC, while EHT-LTF 372 can be used for more refined channel estimation.

[0045] EHT-SIG 368 can be used by AP 102 to identify one or more STAs 104 and notify those STAs that AP 102 has scheduled uplink (UL) or downlink (DL) resources for them. EHT-SIG 368 can be decoded by each compatible STA 104 served by AP 102. EHT-SIG 368 can generally be used by the receiving device to interpret the bits in data field 374. For example, EHT-SIG 368 may include resource element (RU) allocation information, spatial flow configuration information, and per-user (e.g., STA-specific) signaling information. Each EHT-SIG 368 may include a common field and at least one user-specific field. In the context of OFDMA, the common field may indicate the RU distribution across multiple STAs 104, indicate RU assignment in the frequency domain, indicate which RUs are allocated for MU-MIMO transmission and which RUs correspond to OFDMA transmission, and the number of users in the allocation, etc. The user-specific field is assigned to a specific STA 104 and carries STA-specific scheduling information, such as user-specific MCS values ​​and user-specific RU allocation information. This information enables the corresponding STA 104 to identify and decode the corresponding RU in the associated data field 374.

[0046] Figure 4 A layered format of an example PPDU capable of being used for communication between a wireless AP 102 and one or more wireless STAs 104 is shown. As described, each PPDU 400 includes a PHY preamble 402 and a PSDU 404. Each PSDU 404 may represent (or “carry”) one or more MAC Protocol Data Units (MPDUs) 416. For example, each PSDU 404 may carry an aggregated MPDU (A-MPDU) 406, which includes an aggregation of multiple A-MPDU subframes 408. Each A-MPDU subframe 406 may include an MPDU frame 410, which includes a MAC delimiter 412 and a MAC header 414 preceding the accompanying MPDU 416, which includes the data portion (“payload” or “frame body”) of the MPDU frame 410. Each MPDU frame 410 may also include a Frame Check Sequence (FCS) field 418 for error detection (e.g., the FCS field may include Cyclic Redundancy Check (CRC)) and padding bits 420. MPDU 416 may carry one or more MAC Service Data Units (MSDUs) 422. For example, MPDU 416 may carry an aggregated MSDU (A-MSDU) 422, which comprises multiple A-MSDU subframes 424. Each A-MSDU subframe 424 contains a corresponding MSDU 430, which is preceded by a subframe header 428 and, in some cases, followed by padding bits 432.

[0047] Returning to reference MPDU frame 410, MAC delimiter 412 can be used as a marker for the start of associated MPDU 416 and to indicate the length of associated MPDU 416. MAC header 414 may include multiple fields containing information defining or indicating the characteristics or attributes of the data encapsulated within frame body 416. MAC header 414 includes a duration field indicating the duration from the end of the PPDU to at least the end of an acknowledgment (ACK) or block ACK (BA) to be sent by the receiving wireless communication device to the PPDU. The use of the duration field is to reserve the radio medium for the indicated duration and to enable the receiving device to establish its Network Allocation Vector (NAV). MAC header 414 also includes one or more fields indicating the address of the data encapsulated within frame body 416. For example, MAC header 414 may include a combination of source address, transmitter address, receiver address, or destination address. MAC header 414 may also include a frame control field containing control information. The frame control field may specify the frame type, such as a data frame, control frame, or management frame.

[0048] Overview of multi-link devices

[0049] A multi-link device (MLD) typically refers to a single device or apparatus comprising two or more station (STA) instances or entities implemented in the physical (PHY) / media access control (MAC) layer and configured to communicate over a separate radio link. In some examples, each MLD may include a single higher-layer entity, such as a MAC Service Access Point (SAP) that can assign MAC Protocol Data Units (MPDUs) for transmission by individual STA instances.

[0050] Figure 5 A block diagram depicts an example multi-link device (MLD) deployment.

[0051] like Figure 5 As shown, Access Point (AP) MLD 502 can communicate with non-AP MLD 504. Each of the AP MLD and non-AP MLD can include at least two STA entities 514 (hereinafter referred to as "STAs") that can communicate with an associated STA of another MLD. In the AP MLD, the STA can be an AP STA 512 (a STA that acts as an AP or simply "AP"). In the non-AP MLD, the STA can be a non-AP STA (a STA that does not act as an AP). Also as described above, the MLD can utilize Multi-Link Aggregation (MLA) (which includes packet-level aggregation), thereby enabling the transmission of MPDUs from the same Traffic ID (TID) via two or more radio links.

[0052] Various communication modes can be employed in the implementation of MLD. For example, MLD can communicate in asynchronous or synchronous mode. Asynchronous mode provides flexibility to adapt to channel load, allowing MLD to perform channel access, transmission, and reception of data asynchronously via multiple links. However, synchronous mode may be preferred if RF leakage exists between channels, as synchronous transmission on all links is unaffected by RF leakage.

[0053] In asynchronous mode, the STA / AP can count down on both radio links (e.g., via Random Backoff (RBO)). The start / end of the Physical Layer Convergence Protocol (PLCP) Protocol Data Unit (PPDU) can occur independently on each radio link. As a result, asynchronous mode can potentially provide latency and aggregation gain. In some cases, relatively complex (and expensive) filters may be required (e.g., in the case of 5GHz+6GHz aggregation).

[0054] In synchronous mode, the STA / AP can also perform backoff countdowns on multiple radio links as part of the channel access procedure. If the first link gains access to the medium through the channel access procedure, multiple links can transmit PPDUs simultaneously. Therefore, this mode may require some limitations to minimize interference within the device.

[0055] Synchronous mode can operate in 5GHz+6GHz aggregation and may require relatively low filter performance while still providing latency and aggregation gain. However, due to the tiling architecture of STA, this latency and aggregation gain may be difficult to achieve.

[0056] Although not shown, the third communication mode may include a basic (e.g., multi-master channel single-link transmission) mode. In basic mode, the STA / AP may also count down on two wireless links. However, transmission may only occur on the wireless link that has gained access to the medium. The other wireless link may be blocked by in-device interference greater than -62 dBm. In this mode, aggregation gain may not be achievable.

[0057] In some cases, APs (e.g., non-coordinated APs located in different physical locations) can be connected as auxiliary APs to a single AP MLD. Therefore, when a STA (e.g., a non-AP MLD) moves between these APs, the STA can bypass the MLO (re)association and four-way handshake process. These techniques, often referred to as seamless roaming or establish-before-disconnect handover processes, avoid data interruptions and reduce latency during handover.

[0058] Seamless roaming can be considered a useful feature in ultra-high reliability (UHR) networks, enabling client devices to move from one serving AP to another without re-associating. Seamless roaming may involve the UHR AP providing information related to a single mobility domain (SMD) entity (e.g., an SMD AP MLD), advertising candidate APs for clients to choose from for roaming, and potentially transferring context between APs. Such a handover can be initiated by a non-AP MLD (e.g., a STA), or the network can recommend to a non-AP MLD different sets of serving APs to move to (e.g., co-located or non-co-located).

[0059] Overview of Coordinated Communication

[0060] In downlink (DL) multiple-user multiple-input multiple-output (MU-MIMO), multiple stations can belong to a basic service set (BSS) transmitting in the DL. Other BSSs (OBSSs) within "listening" range can postpone (not transmit on the medium) in response to detecting an ongoing transmission. Different BSSs within each other's listening range can use time-division multiplexing (TDM) to transmit in the DL. In coordinated UL MU-MIMO, multiple BSSs perform simultaneous UL transmissions. Unused receive spatial dimensions at the AP can be used to eliminate interference from transmissions from other BSSs (OBSSs). This achieves a greater degree of spatial multiplexing when unused spatial dimensions exist within a BSS. In other words, unused spatial dimensions allow concurrent OBSS transmissions in the DL.

[0061] Using coordinated DL MU-MIMO, signals from each (coordinated) AP can be sent only to stations within its corresponding BSS. While data transmissions from APs may interfere with other OBSS stations, unused dimensions at the AP can be used to eliminate (e.g., zero out) interference from one or more OBSS APs.

[0062] In uplink (UL) multiple-user multiple-input multiple-output (MU-MIMO), multiple stations belonging to one BSS can transmit in the UL. Other BSSs within range can defer transmissions to ongoing transmissions. Different BSSs within each other's ranges can use time-division multiplexing (TDM) to transmit in the UL. In coordinated UL MU-MIMO, multiple BSSs transmit simultaneously in the UL. Similar to DL MU-MIMO, unused receive space dimensions at the AP can be used to eliminate interference from transmissions from other BSSs (OBSSs), thus achieving greater spatial multiplexing and allowing concurrent OBSS transmissions.

[0063] Using coordinated UL MU-MIMO, signals from each STA can be sent to only one AP within its corresponding BSS. While data transmissions from STAs may interfere with other OBSS APs, the unused spatial dimensions at each AP can be used to mitigate (e.g., reduce or zero) interference from OBSS STAs.

[0064] Coordinated beamforming (CoBF) may include one or more protocols for coordinating (e.g., synchronizing) transmissions from different entities, such as forming null values ​​to control interference with STAs of other OBSSs while transmitting to STAs of their own BSSs.

[0065] In a CoBF (Co-Bandwidth Filter), multiple APs can coordinate to suppress OBSS (Obstruction of Biological Surface Classes) interference in the airspace. Therefore, CoBF typically provides gains in an opportunistic manner, for example, when intra-BSS (Bandwidth Surface Class) transmissions do not fully utilize the spatial dimension of that BSS AP.

[0066] Various types of CoBF exist, such as symmetric CoBF with synchronous and / or asynchronous transmission and asymmetric CoBF with synchronous and / or asynchronous transmission. With a symmetric CoBF, all APs can participate in coordinated beamforming and suppress their OBSS interference to other victim STAs within other BSSs. With an asymmetric CoBF, one device (e.g., or a set of devices) may have a higher or lower priority than other devices and / or may lack the ability to suppress OBSS interference.

[0067] Generally, multiple access points (APs) can participate in a MAPC scheme (such as CoBF). However, for ease of understanding, this paper will describe the example technique with reference to a MAPC scenario involving two APs. The technique described in this paper can be extended to systems involving any number of APs.

[0068] Inter-node communication framework for coordinated wireless node mechanisms

[0069] This disclosure provides techniques and mechanisms for forming a framework for inter-AP communication for MAPC sessions. These techniques and mechanisms can be applied to any coordination feature, including (but not limited to) C-TDMA, C-SR, CLI, C-BF, and / or C-preemption.

[0070] To implement the general CAP framework, various structures that can be used as containers for inter-AP communication are proposed in aspects of this disclosure. Such containers can be used to carry information to support the CAP protocol. See reference for examples and details of such containers. Figures 8 to 12 Describe it.

[0071] Various aspects of this disclosure also propose procedures for exchanging CAP information (which can form the basis of a protocol), supporting the notification, discovery, collection / exchange of CAP information, and the establishment of CAP sessions. The exchange of information can be used for enabling / negotiating CAP features, updating CAP parameters, and / or tearing down CAP sessions.

[0072] Information exchange can refer to Figure 6 Let's understand it using example state diagram 600.

[0073] As indicated at 602, an AP may initially be in a MAPC inactive state (e.g., when the AP is started). While in this state, the AP may not yet be able to participate in any CAP features with neighboring APs. In order to participate in CAP features with neighboring APs, the AP must first perform CAP discovery.

[0074] If an AP intends to invite other neighboring APs to participate in the CAP feature, as indicated at 604, the AP may advertise its CAP information in a broadcast frame (e.g., a beacon, extended beacon, probe response, or CAP advertisement frame). As indicated at 606, the AP can discover its neighboring APs when it receives MAPC advertisement information from these neighboring APs.

[0075] As indicated at 608, upon discovery, the AP may perform MAPC session establishment (e.g., to activate the MAPC session). After establishment, the CAP session may be updated, or the MAPC session may be disabled, as indicated at 610. The CAP session may be torn down, causing the AP to return to a CAP inactive state.

[0076] This disclosure provides various options for how an AP can enter or exit a MAPC disabled state. For example, an AP may enter a MAPC disabled state from a MAPC active / enabled state after receiving a frame (e.g., with a frame or element) instructing the AP to disable CAP operation. In some cases, an AP may transition from a CAP disabled state to a CPA inactive state (e.g., during an inactive period or after signaling via a frame or element), or after a period in which the AP indicates its willingness to participate in a MAPC session (as described below). In some cases, an AP may transition from a CAP disabled state to a MAPC active / enabled state after receiving a frame (e.g., with a frame or element) instructing the AP to reactivate / re-enable CAP operation.

[0077] Figure 7 Example call flowchart 700 illustrates an application of various aspects of this disclosure for establishing a MAPC session between two APs (AP1 and AP2) via information exchange. In some cases, AP1 and / or AP2 may be... Figure 1The example shown is AP 102. In some cases, AP1 and AP2 may be part of an MLD (such as an SMD MLD). In some cases, AP1 and AP2 may be associated with different BSSs.

[0078] As indicated at 702, AP1 receives a frame (e.g., an announcement frame) indicating that AP2 is capable of supporting a coordinated communication scheme. As indicated at 704, AP1 and AP2 may establish a session by exchanging information about one or more features of the coordinated communication scheme supported by each other. In some cases, the information exchanged may include parameters that may be relevant (e.g., deemed necessary) to the MAPC features of AP1 and AP2 participating in a CAP session.

[0079] As indicated at 706, AP1 and AP2 may participate in a CAP session based on one or more parameters associated with information exchange (e.g., parameters determined as part of the information exchange). In some cases, as indicated at 708, CAP session maintenance may be performed, for example, by updating one or more parameters and / or enabling / disabling one or more CAP features. As indicated at 710, AP1 and AP2 may participate in MAPC session teardown, which typically refers to the process of terminating a CAP session. After teardown, each of AP1 and AP2 may return to a MAPC inactive state.

[0080] In some cases, CAP announcements can be performed by including the MAPC element in a broadcast frame sent by an AP. Broadcast frames carrying the CAP element (e.g., beacon, extended beacon, probe response, or CAP announcement frames) can be sent periodically by each AP intending to participate in CAP (e.g., once per beacon interval or every 20 milliseconds). In some cases, discovery of neighboring APs can be performed via echo.

[0081] In some cases, during CAP discovery / announcement, the AP may proactively indicate how long it is willing / able to participate in a MAPC session. After this time, the AP may exit the MAPC session without any further indication. In some cases, this signaling may be global (e.g., applicable to all types of CAP operations the AP is participating in) or specific to each type of CAP operation. Depending on whether the signaling is global or type-specific, it may be carried in the common portion of the CAP Information Element (IE) or in each CAP type profile. Alternatively, the signaling may be carried in a separate field or element within a frame.

[0082] In some systems, the information carried in a MAPC element can be organized in the form of segments or profiles, with each profile (or segment) carrying feature-specific information. For example, if the transmitting device supports C-TDMA, C-SR, and CLI, the CAP element may have three profiles, one for each supported CAP feature (or behavior). The C-TDMA profile may carry C-TDMA-specific information. A common section may exist, carrying information applicable to all CAP behaviors supported by the transmitting device. Additionally, a standard-defined encoding scheme may exist to identify each feature. For example, a 3-bit field carried at the beginning of the profile may identify the CAP feature represented by the profile. As an example, a value of 000 may represent C-TDMA, a value of 001 may represent CLI, a value of 010 may represent C-SR, and so on.

[0083] In some cases, information related to CAP session establishment can be carried in elements such as the MAPC element. In some systems, during discovery or CAP capability exchange, the CAP element may carry the minimum content (e.g., a limited amount of information) required to enable CAP establishment or other CAP actions, thus preventing information bloat (e.g., unnecessary information overhead). In some systems, the CAP element may carry complete information during CAP establishment or CAP negotiation. A CAP profile may include all elements and fields specific to the corresponding CAP characteristic.

[0084] In some systems, when carrying complete information, inheritance can be applied across profiles, so that any information applicable to more than one type of CAP feature does not need to be repeated. For example, if a C-TDMA profile carries most of the information applicable to other profiles, the C-TDMA profile can be carried as the first profile, and subsequent profiles (such as those containing information for C-SR) can inherit one or more elements or fields from the C-TDMA profile. Profiles may also include elements indicating non-inheritance (e.g., by including a non-inherited element as the last element). If an element is not present in a particular CAP profile, and the element is not listed among the non-inherited elements (if included) in the profile for that CAP feature, the device receiving the frame can consider the element to be part of that CAP profile, and the content of the element's information fields is applicable to that CAP feature.

[0085] The general purpose of a CAP element is to inform neighboring APs that the AP is interested in participating in CAP features together with neighboring APs. Any further exchanges with neighboring APs can be accomplished via unicast CAP action frames during CAP session setup. In some respects, the minimum information in a CAP element may include CAP capabilities (e.g., C-TDMA supported, C-SR not supported, C-BF not supported, CLI supported) in the CAP common information field, a list of enabled CAP features, CAP capacity, and / or MAPC status fields. Per-CAP information fields are typically not included in the minimum information of a CAP element.

[0086] If an AP receives a frame carrying CAP elements from a neighboring AP and discovers that the neighboring AP intends to establish a MAPC session with that neighboring AP, then that AP can send a unicast CAP action frame to the neighboring AP to establish / negotiate / enable the CAP feature.

[0087] When an AP discovers a neighboring AP that supports one or more CAP features (e.g., and is willing to participate in CAP features), the AP can initiate a MAPC session establishment with the neighboring AP. CAP session establishment can establish a trust relationship with the neighboring AP and may also include sharing CAP-related (e.g., public and feature-specific) capabilities, as well as various parameters that the AP may need to participate in CAP features through the established CAP session.

[0088] CAP session establishment can be configured across all CAP features or individually for each CAP feature. In some aspects, CAP establishment may include a negotiation step, where each AP provides its preferred parameters for one or more CAP features, and another AP accepts, rejects, or provides alternative parameters. If the establishment is successful, the final set of parameters used for the CAP scheme will be a set of parameters agreed upon by both APs.

[0089] In some respects, the establishment of a CAP session with a neighboring AP may include the exchange of CAP request / response frames (e.g., and / or other frames, such as notification / acknowledgment frames).

[0090] During this setup process, the AP may exchange detailed CAP information. This information may include, for example, the set of CAP features to be set (e.g., C-TDMA and CLI), and parameters of the requested CAP features (e.g., for C-TDMA, the minimum and maximum shared TXOP durations the AP is willing to share / receive). In some aspects, these CAP request / response frames may be exchanged via a secure channel. For example, CAP request / response frames may use an AP PeerKey or certificate-based security (e.g., where the certificate is issued by a trusted third party).

[0091] If negotiation is involved, one or more frames (e.g., request / response frames or notification / acknowledgment frames) can be exchanged between APs. For example, once a MAPC response frame with a status code equal to (e.g., indicating) success is received, a CAP session is established between the initiating AP and the responding AP. For an AP pair, CAP establishment only needs to be performed once unless the CAP session is torn down, in which case CAP (re)establishment can be performed (again) between the two APs.

[0092] According to certain aspects of this disclosure, the scope of a MAPC session can vary. In some aspects, a single CAP session can be extended to all CAP features. This can be advantageous because the AP does not need to perform CAP session setup at the per-CAP feature level, which would otherwise result in more signaling overhead. Alternatively, in some aspects, MAPC sessions can be maintained on a per-feature basis. For example, a first CAP session (CAP session 1) may be applicable to a first CAP feature (feature 1), while a second CAP session (CAP session 2) may be applicable to a second CAP feature (feature 2).

[0093] A CAP session is typically defined by a comprehensive protocol between two APs to participate in and maintain parameters of one or more CAP features (e.g., depending on the scope of the CAP session). Such a MAPC session can encompass multiple “sub-protocols” used for coordination. For example, multiple feature-specific sessions may exist within a comprehensive CAP session (e.g., multiple TWT service periods for C-RTWT, each TWT service period identified by a TWT ID).

[0094] In some respects, an optional CAP information gathering phase (e.g., similar to the probe characteristics defined for AP-STA communication) may exist between CAP discovery and CAP session establishment. CAP information gathering can be performed using the same frames as CAP session establishment (e.g., CAP request / response frames or notification / acknowledgment frames). Fields in the frame (e.g., request code field) can indicate whether the frame is requesting information or requesting establishment. Alternatively, different frames (such as MAPC information request / response frames) can be defined. The AP can use the CAP information gathering phase to determine whether a neighboring AP is suitable to perform CAP session establishment, especially when the minimal information obtained during CAP discovery may not be sufficient to make such a determination.

[0095] In some respects, when both the initiating AP and the receiving AP are attached to an MLD, the initiating AP can request CAP session establishment on two or more links. In this case, the CAP element can be included within the multi-link element. For example, with the link ID... j The corresponding CAP element can be included when the link ID field is set to jThis is described in the profile for each STA. This can provide some benefits by allowing two APs to establish coordination across multiple links on which they both operate and / or by allowing setup / update / discovery on a single link. Even if CAP session setup / discovery / maintenance can be performed on a single link for multiple links, the scope of a MAPC session may be link-specific. That is, a separate CAP session may be required on each link before an AP can participate in one or more CAP features on the corresponding link.

[0096] This framework also allows for cross-link CAP session establishment. For example, the sending AP can include a multi-link link information element to indicate that the CAP session establishment requested in the CAP request frame does not apply to the link on which the frame was sent, but rather to the different links indicated in the link ID bitmap field of the multi-link link information element.

[0097] As noted above, after the initial CAP session is established, the AP can perform actions to maintain the CAP session. This may involve dynamically updating CAP parameters (e.g., these CAP parameters can be common parameters or per-CAP feature parameters), and / or enabling / disabling (e.g., temporarily suspending) one or more CAP features. CAP session maintenance can be based on the service characteristics of the AP's BSS. For example, if a non-AP STA begins transmitting or receiving latency-sensitive services from the AP, the AP may enable the MAPC feature; otherwise, it may disable the CAP feature.

[0098] In some cases, CAP session maintenance may involve the exchange of CAP notification frames to dynamically enable / disable CAP features. CAP notification frames may be exchanged based on the BSS requirements of a single AP (e.g., the presence of low-latency services).

[0099] In some respects, two or more CAP notification frames may be exchanged between each AP pair. For example, the initiating AP may transmit a MAPC notification frame to enable a feature (e.g., enable C-TDMA with certain parameters). The responding AP may transmit a MAPC notification frame to accept enable, reject enable, or suggest alternative enable (e.g., enable with alternative parameters). If the responding AP suggests alternative enable, the initiating AP may transmit another CAP notification frame with different parameters, and this sequence may continue until enable is ultimately successful or rejected.

[0100] To disable the MAPC feature, an AP can transmit a MAPC notification frame with the enable flag set to 0. When disabling is complete, a responding AP can transmit a MAPC notification frame. In some respects, a responding AP may not be allowed to refuse disabling.

[0101] When an AP is attached to an MLD, enabling / disabling can be performed on one link at a time or across multiple links, and related information can be included in the multi-link element. In some aspects, the sending AP may include a multi-link information element to indicate that the information indicated in the CAP frame does not apply to the link on which the frame was sent, but rather to the different links indicated in the link ID bitmap field of the multi-link information element.

[0102] In some respects, updates to the CAP parameters of an AP can be announced by that AP or other APs attached to that AP's MLD in broadcast management frames (e.g., beacon / extended beacon / probe response frames / CAP announcement frames). Such updates can utilize critical update procedures for the CAP parameters.

[0103] Updates to the CAP parameters of an AP can also be transmitted to neighboring APs in a unicast CAP notification frame. For example, a unicast CAP notification frame may be appropriate when the CAP parameters only affect a subset of neighboring APs with which the affected AP has established a MAPC session. When an AP identifies that the MAPC parameters of a neighboring AP have been updated, the AP may transmit a MAPC notification frame to update its CAP settings with the neighboring APs (e.g., where applicable).

[0104] When the MAPC feature is enabled, an AP can participate in the CAP feature together with its neighboring APs. For example, an AP can share a Transmission Opportunity (TXOP) with a neighboring AP as a sharing AP, or receive a shared TXOP as a shared AP. As another example, an AP can end its TXOP before another AP's CLI service period (SP).

[0105] When an AP is no longer interested in participating in MAPC features with its neighboring AP (with which the AP has a MAPC setup), the AP can perform a MAPC teardown process. CAP session setup is conceptually similar to an “association” between an AP and a non-AP STA. In the baseline 802.11 standard, a non-AP STA needs to associate with an AP before it can “enable / disable” different modes. Similarly, in CAP, two APs may need to perform a “CAP session setup” to “enable / disable” CAP features (e.g., C-TDMA / C-SR, etc.).

[0106] When an AP has established a CAP session with a neighboring AP, and the AP no longer intends to participate in the CAP feature with that neighboring AP, the AP can initiate the teardown of the CAP session. In some respects, the scope of CAP session teardown is the same as the scope of CAP session establishment. In other words, if the CAP session is common across all CAP features, then the teardown can also be common across all CAP features. Similarly, if the CAP session is specific to a particular CAP feature, then the teardown can also be specific to that particular CAP feature.

[0107] According to certain aspects of this disclosure, CAP teardown can be performed by sending a separately addressed CAP request frame. In some aspects, fields in the frame (e.g., request code) can be set to special values ​​to indicate a teardown request (distinct from a request for session establishment or information collection). In some aspects, neighboring APs receiving the frame may not be allowed to refuse the request to tear down the CAP session. In some aspects, neighboring APs may be required to send a MAPC response with a status code set to success, indicating successful teardown. In some aspects, the MAPC session can be automatically torn down after the timeout period expires (e.g., without receiving a CAP response frame).

[0108] Alternatively, separate CAP teardown frames can be defined. For example, if an AP intends to tear down all established CAP sessions, the AP can send separately addressed CAP request (e.g., teardown) frames to all APs with which it has established sessions. This can be advantageous because each receiving AP can confirm / acknowledge receipt of the teardown request frame.

[0109] In some respects, an AP may send a group-addressed CAP request (e.g., teardown) frame to a specific characteristic group address. In this case, individual receiving APs may not respond to the teardown request. However, the AP may send a trigger frame (e.g., similar to a Null Data Packet (NDP) Feedback Report Polling (NFRP)) to solicit a response from the receiving APs (such as to confirm receipt of the teardown request).

[0110] In some cases, an AP may send a broadcast CAP request (e.g., teardown) frame. In such cases, neighboring APs will not send a response frame to confirm the teardown request.

[0111] Implementing AP power saving (PS) features provides numerous advantages for UHR. Two main variants of AP PS include static AP PS based on service hours and dynamic AP PS that allows the AP to be "wake up" as needed. The "wake-up" operation is implemented using an Initial Control Frame (ICF), which includes padding fields to enable the AP to transition from low-power mode to normal mode.

[0112] If the first AP is in dynamic PS mode, another AP intending to communicate with the first AP may have an ICF (e.g., a MU-RTS trigger frame) preceding its unicast CAP frame (e.g., along with any other frames transmitted to the first AP). A group-addressed frame may also precede the ICF frame, containing a user information field for each AP addressed by the group-addressed frame. In some aspects, if the first AP is operating in dynamic AP PS mode, it may require another AP to transmit (e.g., individually addressed or group-addressed) frames to the first AP, even if that other AP transmits broadcast CAP frames to other adjacent APs.

[0113] If the first AP is in static PS mode, another AP intending to communicate with the first AP may be required to transmit frames to the first AP only during the SP period when the first AP is in active / wake-up mode. During these active / wake-up periods, the other AP may be allowed to transmit individually addressed frames, group-addressed frames, or broadcast CAP frames.

[0114] For AP Example container for inter-communication

[0115] This disclosure provides procedures / protocols for inter-AP information exchange, for exchanging CAP session-related parameters as described above. To implement the CAP framework disclosed herein, certain components are proposed that can be used as containers for inter-AP communication.

[0116] Such containers can carry the information required to support the CAP protocol, as well as the procedures / protocols for exchanging CAP information (e.g., as described above). These procedures / protocols for exchanging CAP information include the notification of CAP information and discoveries, information collection, establishment of CAP sessions, enabling / negotiation of CAP features, updating of CAP parameters, teardown of CAP sessions, and security considerations.

[0117] Figure 8 An example of a frame format 800 that can be used to exchange CAP information is shown. As illustrated, the category field 802 defines the category of the action frame, while the action field 804 defines the specific action performed by the action frame.

[0118] Various aspects of this disclosure provide various options for frame formats used to exchange CAP information. For example, according to the first option, existing frame formats, such as common action (or other types of action) frames, can be used. For example, using existing frame formats may be advantageous by leveraging existing infrastructure to define CAP communication. Common action frames can be used for inter-BSS communication (e.g., exchanged between two APs). According to the second option, new management frame formats (e.g., for action frames) are specifically designed for / intended for inter-BSS communication.

[0119] like Figure 9 As illustrated, according to the first option, a new common action frame can be defined by using one or more of the reserved / available values ​​of the common action field 804. As illustrated, the category field 802 of various CAP action frames can be set to a value (e.g., value 4) to indicate that the frame is a common action frame. Setting the value of the common action field to a new value (such as a currently reserved value) indicates that the common action frame will be used for CAP communication.

[0120] In some respects, more than one common action frame can be defined for different CAP tasks. For example, a MAPC notification frame (e.g., which can be a management frame) can be defined for notification / discovery, a MAPC request / response frame can be defined for CAP session establishment, information collection, or session teardown, a MAPC notification frame can be defined for enabling / disabling / negotiating, and a MAPC acknowledgment frame (e.g., for confirmation / verification) can be defined.

[0121] like Figure 9 As illustrated, each new common action frame can be defined by a unique value in the common action field. As shown, values ​​54, 55, 56, 57, or 58 can indicate that the common action frame is a MAPC announcement frame, a MAPC request frame, a MAPC response frame, a MAPC notification frame, or a MAPC acknowledgment frame, respectively. However, these values ​​and the order in which they represent different CAP frames are merely illustrative examples; wireless communication standards may define different values ​​and / or different orders.

[0122] like Figure 9 As illustrated, frame content 806 (e.g., a common action frame) may carry one or more fields and / or elements. The number, order, and names of these fields / elements may depend on the value of the common action field. Such fields may include a dialogue token field, a request code field, a status code field, an enable / disable flag, a MAPC element, and / or a multi-link element. The enable / disable flag may be a bitmap, where each bit corresponds to a specific CAP feature.

[0123] like Figure 10 As illustrated, according to the second option, one or more new CAP action frames can be defined by using one of the reserved values ​​of the category field 802. For example, the current reserved value of the category field (e.g., 35) can indicate that the frame is a MAPC action frame. The action field 804 can then be referred to as the CAP action field. These CAP action frames can be used for inter-BSS communication.

[0124] In some respects, more than one CAP action frame can be defined for different CAP tasks. For example, a MAPC announcement frame can be defined for notification / discovery, a MAPC request / response frame can be defined for CAP session establishment, information collection, or session teardown, a MAPC notification frame can be defined for enabling / disabling / negotiating, and / or a MAPC acknowledgment frame (e.g., for confirmation / verification) can be defined.

[0125] Each new CAP action frame can be defined by a unique value in the CAP action field. For example, values ​​0, 1, 2, 3, and 4 can indicate that the CAP action frame is a MAPC announcement frame, a MAPC request frame, a MAPC response frame, a MAPC notification frame, and a MAPC acknowledgment frame, respectively. However, these values ​​and the order in which they represent different CAP frames are merely illustrative examples, and wireless communication standards may define different values ​​and / or different orders.

[0126] like Figure 10 As illustrated, the frame content 806 of a frame (e.g., a CAP action frame) may carry one or more fields and elements. The number, order, and names of these fields / elements may depend on the value of the CAP action field. Such fields may include a session token field, a request code field, a status code field, an enable / disable flag, a MAPC element, and / or a multi-link element. The enable / disable flag may be a bitmap, where each bit corresponds to a specific CAP feature.

[0127] Various techniques for addressing CAP frames are provided in various aspects of this disclosure. In some aspects, for example, MAPC advertisement frames (e.g., which may be management frames) may be transmitted with a broadcast receiver address (RA). In some aspects, MAPC advertisement frames may be sent to a group address or a separate address (e.g., the RA receiving the AP). In some aspects, CAP request / response frames, CAP notification frames, and CAP acknowledgment frames may be transmitted with a separately addressed RA (e.g., the RA receiving the AP).

[0128] Some aspects of this disclosure may utilize group addressing schemes and allow APs to set the RA field to these group addresses. In some aspects, feature-specific group addresses may be utilized. For example, a first group address may be available for C-TDMA, and a second group address may be available for C-SR. Therefore, when a MAPC frame is transmitted to a C-TDMA group address, all APs participating in C-TDMA with the AP can receive and decode the frame. In some aspects, these group addresses may be defined in the wireless communication standard by a coordinating AP (e.g., acting as a local controller / coordinator) or by a central controller (e.g., an SMD MLD, if these APs are attached to an SMD MLD).

[0129] In some respects, the same set of frames may apply to all CAP features. In some cases, certain frames may be "common" (e.g., applicable to all CAP features). In some respects, feature-specific frames may be used for certain actions. For example, discovery / announcement and notification may be associated with common CAP frames, while setup and teardown may be feature-specific (e.g., CLI setup request) frames.

[0130] In some respects, the first AP (AP1) may support both C-TDMA and C-SR features, while the second AP (AP2) may support only C-TDMA. In such cases, frames transmitted by AP1 (e.g., within a MAPC session) may include information for both C-TDMA and C-SR (e.g., capabilities and operating parameters), while frames transmitted by AP2 (e.g., within a CAP session) may include only information for C-TDMA.

[0131] Various aspects of this disclosure provide MAPC elements with flexible designs (e.g., which can be included / carried in a frame) that allow the exchange of minimal information during discovery (e.g., to minimize bloat / excessive overhead), the exchange of partial sets of information during enable / disable, and the exchange of complete information during setup.

[0132] For example, Figure 11 An example CAP element 1100 is illustrated that can be used across discovery, setup, activation, and updates. As illustrated, CAP element 1100 can be flexible, allowing it to carry information about specific CAP features (e.g., C-TDMA only) or information about all CAP features. Furthermore, CAP elements can be forward compatible, enabling new CAP features defined in future generations to utilize the same element for signaling purposes.

[0133] In some aspects, CAP control field 1102 may include a bitmap indicating which subfields exist in CAP public information field 1104. Each CAP information field 1106 may include parameters associated with a single capability.

[0134] In some respects, the CAP public information field 1104, the CAP profile field, or both may include a "length" field for forward compatibility with elements. An AP receiving the length field from the public information field and the CAP profile field can decode the subfields of the public information / CAP profile field that it can interpret and ignore the remainder of the value carried in the length field. For example, if the length field indicates that the length of the CAP public information field is 12 octets, but the receiving AP can only interpret the first 7 octets of the CAP public information field (because the remaining 5 octets are defined in a later generation / version), then the receiving AP can decode the first 7 octets and ignore the remaining 5 octets of the CAP public information field. After ignoring these 5 octets, the receiving AP can infer that each CAP information field 1106 has begun and can begin processing the CAP profile field.

[0135] In some respects, the MAPC information field within the CAP profile field can provide a bitmap of the presence indicators of the optional fields carried in the CAP profile field. This bitmap can indicate to the receiver which fields are present, enabling the receiver to correctly decode the CAP profile field.

[0136] In some respects, CAP capacity indicates the total number of APs with which an AP can coordinate. In other respects, CAP status indicates how many APs an AP is currently coordinating with (e.g., it indicates how many more APs an AP can still coordinate with). The CAP capacity and CAP status fields can be "public" (e.g., across all CAP features) or feature-specific. If CAP capacity and CAP status are public, they can be carried in the CAP public information field. Otherwise, if CAP capacity and CAP status are applicable at the CAP feature level, they can be carried in the CAP profile field.

[0137] In some respects, the CAP element may indicate a preference for receiving CAP updates (e.g., via broadcast, via unicast, etc.). The CAP element may also indicate a preferred mode for resource requirement collection to understand how many resources neighboring APs require (e.g., BSRP / NFRP, etc.) and / or which features are currently enabled (e.g., via bitmap). In some respects, the CAP element may also indicate the duration before the negotiated CAP session expires.

[0138] Figure 12 Certain variations of the illustrated MAPC element 1200 (e.g., variation 2) can be used as feature-specific CAP elements. As illustrated, CAP element 1200 may include a MAPC information field 1202. As illustrated, CAP information field 1202 may include elements similar to those referenced above. Figure 11 The CAP public information field 1104 is similar to the described field. In some cases, the CAP information field 1202 may also include different fields or other fields (e.g., as supplements or alternatives).

[0139] In some cases, a hybrid option can be used (e.g., in...) Figure 11 and Figure 12 (Among the variants shown). For example, some variants of the CAP element can be defined using two information elements (IEs), which are defined with different element ID extension values. In such cases, when a variant 1 CAP element is carried in a “CAP public frame,” a feature-specific CAP element (e.g., variant 2) can be included as a child element within each CAP information field. In such cases, when a feature-specific CAP element (e.g., variant 2) is included in a feature-specific frame (e.g., a CLI setup request frame), the CAP element can be carried by itself.

[0140] Figure 13 An example of a wireless communication process or method 1300 capable of being performed by or at a first wireless station is shown. Operation of process 1300 may be implemented by a wireless station or its components as described herein. For example, process 1300 may be implemented by a wireless communication device (such as a reference cipher) operating as or within a wireless station. Figure 14 The wireless communication device 1400 described herein shall be used to perform this action.

[0141] Method 1300 begins at step 1305, wherein a first frame indicating that the second wireless node is capable of supporting a coordinated communication scheme is obtained, wherein the first wireless node is associated with a first Basic Service Set (BSS), and the second wireless node is associated with a second BSS. In some cases, the operation of this step refers to, as described in reference... Figure 14 The described acquisition component (e.g., the circuitry and / or code used for acquisition), or the component that can be executed by the acquisition component.

[0142] Then, method 1300 proceeds to step 1310, wherein a session is established with the second wireless node by exchanging information with the second wireless node about one or more features of the coordinated communication scheme supported by the first and second wireless nodes. In some cases, this step refers to the operation as described in reference... Figure 14 The described building components (e.g., circuits and / or code used for building), or those that can be executed by the building components.

[0143] Then, method 1300 proceeds to step 1315, where a coordinated communication scheme is used to participate in the session, the participation being based on one or more parameters associated with the exchange of information. In some cases, the operation of this step refers to, as referenced... Figure 14 The described participating component (e.g., circuitry for participation and / or code for participation), or the component that can perform the participation.

[0144] Figure 14 A block diagram of a wireless communication device or wireless node 1400 (e.g., AP, non-AP STA, non-AP MLD, STA) according to some aspects of this disclosure is shown. For example, the wireless communication device 1400 may be configured or be able to operate to perform reference... Figure 13 The process described is one or more processes of process 1300.

[0145] Wireless communication device 1400 may include one or more chips, SoCs, chipsets, packages, components, or devices that individually or collectively constitute or include a processing system. The processing system may interface with other components of wireless communication device 1400 and typically processes information (such as inputs or signals) received from and outputs information (such as outputs or signals) to such other components. In some aspects, an example chip may include a processing system, a first interface for outputting or transmitting information, and a second interface for receiving or acquiring information. For example, the first interface may refer to an interface between the chip's processing system and a transmitting component, allowing device 1400 to transmit information output from the chip. In such an example, the second interface may refer to an interface between the chip's processing system and a receiving component, allowing device 1400 to receive information subsequently passed to the processing system. In some such examples, the first interface may also acquire information, for example, from a transmitting component, and the second interface may also output information, for example, to a receiving component.

[0146] The processing system of the wireless communication device 1400 includes processor (or “processing”) circuitry in the form of one or more processors, microprocessors, processing units (such as a central processing unit (CPU), graphics processing unit (GPU), or digital signal processor (DSP)), processing blocks, application-specific integrated circuits (ASICs), programmable logic devices (PLDs) (such as field-programmable gate arrays (FPGAs)), or other discrete gate or transistor logic components or circuits (all of which may herein be individually referred to as “processors” or collectively as “processors” or “processor circuitry”). One or more of these processors may be individually or collectively configured to perform the various functions or operations described herein. The processing system may also include memory circuitry in the form of one or more memory devices, memory blocks, memory elements, or other discrete gate or transistor logic components or circuitry, each of which may include tangible storage media such as random access memory (RAM) or read-only memory (ROM) or combinations thereof (all of which herein may herein be individually referred to as “memory” or collectively as “memory” or “memory circuitry”). One or more of these memories may be coupled to one or more processors and may store processor-executable code, individually or collectively, which, when executed by one or more processors, configures one or more processors to perform the various functions or operations described herein. Additionally or alternatively, in some examples, one or more processors may be pre-configured to perform the various functions or operations described herein without software configuration. The processing system may also include or be coupled to one or more modems (such as a Wi-Fi (e.g., IEEE compliant) modem or a cellular (e.g., 3GPP 4G LTE, 5G, or 6G compliant) modem). In some embodiments, one or more processors of the processing system include or implement one or more modems. The processing system may also include or be coupled to multiple radio components (collectively, “radio components”), multiple RF chains, or multiple transceivers, each of which may in turn be coupled to one or more antennas. In some embodiments, one or more processors of the processing system include or implement one or more of the radio components, RF chains, or transceivers.

[0147] In some examples, the wireless communication device 1400 may be used in an AP or AP MLD (such as reference 1400). Figure 1The device described in AP 102). In some other examples, wireless communication device 1400 may be an AP including such a processing system and other components including multiple antennas. Wireless communication device 1400 is capable of transmitting and receiving wireless communications, for example, in the form of wireless packets. For example, wireless communication device 1400 may be configured or configured to transmit and receive packets in the form of physical layer PPDUs and MPDUs conforming to one or more of the IEEE 802.11 series of wireless communication protocol standards. In some other examples, wireless communication device 1400 may be configured or configured to transmit and receive signals and communications conforming to one or more 3GPP specifications, including those for 5G NR or 6G. In some examples, wireless communication device 1400 also includes one or more application processors or may be coupled to one or more application processors, which may also be coupled to one or more other memories. In some examples, wireless communication device 1400 also includes at least one external network interface coupled to the processing system, which enables communication with a core network or backhaul network that allows wireless communication device 1400 to access external networks, including the Internet.

[0148] In some examples, the wireless communication device 1400 may be used for STA or non-AP STA (such as reference STA). Figure 1 The device used in the described STA 104). In some examples, the wireless communication device 1400 also includes a user interface (UI) (such as a touchscreen or keypad) and a display that can be integrated with the UI to form a touchscreen display. In some examples, the wireless communication device 1400 may also include one or more sensors, such as, for example, one or more inertial sensors, accelerometers, temperature sensors, pressure sensors, or altitude sensors.

[0149] Wireless communication device 1400 includes an acquisition component 1402, an establishment component 1404, an engagement component 1406, and a switching component 1408. A portion of one or more of components 1402 to 1408 may be implemented at least partially in hardware or firmware. For example, the acquisition component 1402 and the establishment component 1404 may be implemented at least partially by a modem. In some examples, at least some of the components (such as 1402, 1404, 1406, and / or 1408) are implemented at least partially by at least one processor and are implemented as software stored in memory. For example, a portion of one or more of components 1402, 1404, 1406, and / or 1408 may be implemented as non-transitory instructions (or "code") executable by a processor to perform the function or operation of the corresponding module.

[0150] Various components of the wireless communication device 1400 can provide for performing reference Figure 13 The described process 1300 or any aspect thereof. Components for receiving or obtaining may include references. Figure 1 The transceiver and / or antenna of the described AP 102 (or STA 104), and / or the obtaining component 1402 of the wireless communication device 1400. Components for transmitting, transmitting, or outputting (e.g., for transmitting) may include references. Figure 1 The transceiver and / or antenna of the described AP 102 (or STA 104), and / or the output component 1404 of the wireless communication device 1400.

[0151] In some cases, instead of actually transmitting, for example, signals and / or data, the wireless communication device 1400 may have an interface (a component for outputting or providing) for outputting or providing signals and / or data for transmission. For example, a processor may output signals and / or data to the radio frequency (RF) front end of the wireless communication device 1400 via a bus interface for transmission. In various aspects, the RF front end may include various components, including transmit and receive processors, transmit and receive MIMO processors, modulators, demodulators, etc.

[0152] In some cases, instead of actually receiving signals and / or data, the wireless communication device 1400 may have an interface (for acquisition components) for acquiring signals and / or data received from another device. For example, a processor may acquire (or receive) signals and / or data from the RF front end of the wireless communication device 1400 via a bus interface for reception. In various aspects, the RF front end may include various components, including transmit and receive processors, transmit and receive MIMO processors, modulators, demodulators, etc. In various aspects, the acquisition components, the establishment components, the output components, and the participation components, the exchange components, and / or the use components may include one or more processors (such as one or more processors / components illustrated in the figures and / or described above).

[0153] Example Terms

[0154] Specific implementation examples are described in the following numbered clauses.

[0155] Clause 1: A method for wireless communication at a first wireless node, the method comprising: obtaining a first frame indicating that a second wireless node is capable of supporting a coordinated communication scheme, wherein the first wireless node is associated with a first basic service set (BSS) and the second wireless node is associated with a second BSS; establishing a session with the second wireless node by exchanging information with the second wireless node about one or more features of the coordinated communication scheme supported by the first wireless node and the second wireless node; and participating in the session using the coordinated communication scheme, the participation being based on one or more parameters associated with the exchange of information.

[0156] Clause 2: The method described in Clause 1, wherein the first frame is associated with a logical identifier, which is associated with a group of wireless nodes.

[0157] Clause 3: The method according to any one of Clauses 1 to 2, wherein the session is established with the second wireless node and at least the third wireless node.

[0158] Clause 4: The method described in Clause 3, wherein the session is associated with a logical identifier.

[0159] Clause 5: The method according to any one of Clauses 1 to 4, wherein one or more of the features involve at least one of the following: coordinated time division multiple access (TDMA), coordinated spatial reuse (SR), coordinated restricted target wake-up time (C-RTWT), coordinated orthogonal frequency division multiple access (OFDMA), coordinated beamforming (BF), coordinated preemption, or other coordinated techniques.

[0160] Clause 6: The method according to any one of Clauses 1 to 5, wherein: the first wireless node and the second wireless node are attached to a single mobile domain (SMD) multi-link device (MLD).

[0161] Clause 7: The method according to any one of Clauses 1 to 6, wherein establishing the session includes establishing media access coordination on the same channel on which the second wireless node establishes media access coordination.

[0162] Clause 8: The method according to any one of Clauses 1 to 7 further includes outputting a second frame indicating that the first wireless node is capable of supporting the coordinated communication scheme, wherein the first frame is obtained after the output of the second frame.

[0163] Clause 9: The method according to any one of Clauses 1 to 8, wherein the first frame includes a management frame.

[0164] Clause 10: The method according to any one of Clauses 1 to 9, wherein the exchange of information involves one or more action frames.

[0165] Clause 11: The method according to any one of Clauses 1 to 10, wherein the first frame indicates at least one of: one or more features of the coordinated communication scheme supported by the second wireless node; or at least one of the status or capacity of one or more features of the coordinated communication scheme.

[0166] Clause 12: The method according to any one of Clauses 1 to 11, wherein the exchange of information involves at least one of the following: at least one request frame and at least one response frame; or at least one notification frame and at least one acknowledgment frame.

[0167] Clause 13: The method according to any one of Clauses 1 to 12, wherein the one or more parameters include at least one duration of willingness of at least one of the first wireless node or the second wireless node to participate in the coordinated communication scheme.

[0168] Clause 14: The method according to any one of Clauses 1 to 13, wherein the one or more parameters include at least one of minimum shared transmission opportunity duration or maximum shared transmission opportunity duration.

[0169] Clause 15: The method according to Clause 14, wherein the exchange of the at least one request frame and the at least one response frame involves / uses a security key.

[0170] Clause 16: The method according to any one of Clauses 1 to 15, wherein one or more of the parameters remain applicable outside the duration of the session.

[0171] Clause 17: The method according to any one of Clauses 1 to 16, wherein one or more parameters apply only during the duration of the session.

[0172] Clause 18: The method according to any one of Clauses 1 to 17 further includes exchanging additional information with the second wireless node to perform at least one of the following: dynamically enabling one or more features of the coordinated communication scheme, or dynamically disabling one or more features of the coordinated communication scheme.

[0173] Clause 19: The method according to Clause 18, wherein: the first wireless node and the second wireless node are multi-link devices (MLDs); and the exchange of additional information dynamically enables or dynamically disables one or more features of the coordinated communication scheme for multiple links.

[0174] Clause 20: The method according to any one of Clauses 1 to 19 further includes: exchanging additional information to update the one or more parameters.

[0175] Clause 21: The method according to any one of Clauses 1 to 20 further includes participating in the process of terminating the session.

[0176] Clause 22: The method described in Clause 21, wherein the process involves at least one of the following: at least one individual addressing request; at least one individual addressing request; or at least one group addressing request.

[0177] Clause 23: The method according to any one of Clauses 1 to 22, wherein: at least one of the first wireless node or the second wireless node is in a power-saving mode; and one or more frames involved in the establishment of the session are at least one of the following: output during a service period after a frame intended to wake up the first wireless node or the at least one of the second wireless nodes in power-saving mode, or when the first wireless node or the at least one of the second wireless nodes in power-saving mode is in an active mode or a wake-up state.

[0178] Clause 24: The method according to any one of Clauses 1 to 23, wherein the exchange of information involves at least one action frame having a field set to a value to indicate one or more (e.g., common) action frames of information to be used for the coordinated communication scheme.

[0179] Clause 25: The method according to Clause 24, wherein the at least one action frame includes a plurality of profile segments, each profile segment including information on different features of the coordinated communication scheme.

[0180] Clause 26: The method according to Clause 25, wherein each profile segment includes an identifier of the corresponding feature to which the information in the profile segment applies.

[0181] Clause 27: The method according to Clause 25, wherein the first profile in the profile includes public information inherited from at least a second profile in the profile that lacks the public information, wherein the inheritance indicates that the public information is applicable to the characteristics of the coordinated communication scheme associated with the second profile.

[0182] Clause 28: The method according to Clause 24, wherein: different types (e.g., common) action frames are used to exchange information on different features of the coordinated communication scheme; and the field is set to a specific value to indicate one of the different types (e.g., common) action frames.

[0183] Clause 29: The method described in Clause 28, wherein at least one of the number of fields, field order, field name, or element name in the action frame depends on the corresponding (e.g., public) action frame type.

[0184] Clause 30: The method according to Clause 24, wherein at least one common type of the at least one action frame is used to exchange information for different features of the coordinated communication scheme.

[0185] Clause 31: According to the method of Clause 30, wherein the at least one public type is associated with at least one or more fields for conveying information for the different characteristics.

[0186] Clause 32: According to the method of Clause 24, the at least one action frame or at least one of the one or more (e.g., common) action frames includes an information element (IE) for exchanging information about different features of the coordinated communication scheme.

[0187] Clause 33: The method described in Clause 32, wherein the IE includes a bitmap indicating which subfields exist.

[0188] Clause 34: According to the method of Clause 32, the at least one action frame includes one or more indications to at least one of the following: a preference for receiving updates to parameters associated with the coordinated communication scheme; a preferred mode for resource information collection; one or more currently enabled features of the coordinated communication scheme; or the duration before the session expires.

[0189] Clause 35: An apparatus comprising: at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the apparatus to perform the method according to any combination of Clauses 1 to 34.

[0190] Clause 36: An apparatus comprising: a component for performing the method according to any combination of Clauses 1 to 34.

[0191] Clause 37: A non-transitory computer-readable medium comprising executable instructions that, when executed by at least one processor of a device, cause the device to perform the method according to any combination of Clauses 1 to 34.

[0192] Clause 38: A computer program product embodied on a computer-readable storage medium, the computer-readable storage medium including code for performing the methods described in any combination of Clauses 1 to 34.

[0193] Clause 39: A first wireless node (e.g., an access point), the first wireless node comprising: at least one transceiver; at least one memory including executable instructions; and at least one processor configured to execute the executable instructions and cause the device to perform the method according to any combination of Clauses 1 to 34, wherein the at least one transceiver is configured to receive the first frame.

[0194] Additional considerations

[0195] As used herein, the term "determine" encompasses a wide variety of actions, and therefore, "determine" can include calculation, computation, processing, derivation, investigation, searching (such as by searching in a table, database, or other data structure), reasoning, probing, measurement, and similar actions. Additionally, "determine" can include receiving (such as receiving information), accessing (such as accessing data stored in memory), sending (such as sending information), etc. Furthermore, "determine" can include parsing, selecting, obtaining, choosing, building, and other similar actions.

[0196] As used herein, the phrase “at least one of the items” refers to any combination of those items, including a single member. For example, “at least one of a, b, or c” is intended to cover: a, b, c, ab, ac, bc, and abc. As used herein, “or” is intended to be interpreted in an inclusive sense unless otherwise expressly indicated. For example, “a or b” could include only a, only b, or a combination of a and b.

[0197] As used herein, unless otherwise expressly indicated, “based on” is intended to be interpreted in an inclusive sense. For example, unless otherwise expressly indicated, “based on” may be used interchangeably with “at least partially based on,” “associated with,” or “according to.” Specifically, unless the phrase in the context means “based on only one” or an equivalent, it may be based solely on “one” or on a combination of “one” and one or more other factors, conditions, or information, whether it is “based on one” or “at least partially based on one.”

[0198] The various exemplary components, logic units, logic blocks, modules, circuits, operations, and algorithmic processes described in conjunction with the examples disclosed herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. This interchangeability of hardware, firmware, and software has been generally described in terms of its functionality and exemplified in the various exemplary components, blocks, modules, circuits, and processes described above. Whether this functionality is implemented in hardware, firmware, or software depends on the specific application and the design constraints imposed on the overall system.

[0199] As used herein, "processor," "at least one processor," or "one or more processors" generally refers to a single processor configured to perform one or more operations, or multiple processors configured to collectively perform one or more operations. In the case of multiple processors, the execution of one or more operations may be divided among different processors, but one processor may perform multiple operations, and multiple processors may collectively perform a single operation. Similarly, "memory," "at least one memory," or "one or more memory" generally refers to a single memory configured to store data and / or instructions, or multiple memories configured to collectively store data and / or instructions.

[0200] In some cases, instead of actually transmitting signals, a device (e.g., a wireless node or device) may have an interface for outputting signals for transmission. For example, a processor may output signals to a radio frequency (RF) front-end via a bus interface for transmission. Therefore, components for output may include such an interface as an alternative (or addition) to a transmitter or transceiver. Similarly, instead of actually receiving signals, a device (e.g., a wireless node or device) may have an interface for receiving signals from another device. For example, a processor may receive (or acquire) signals from an RF front-end for reception via a bus interface. Therefore, components for acquisition may include such an interface as an alternative (or addition) to a receiver or transceiver.

[0201] While this disclosure may describe certain operations as being performed by one type of wireless node, the same or similar operations may also be performed by another type of wireless node. For example, an operation performed by an AP STA may also (or alternatively) be performed by a non-AP STA. Similarly, an operation performed by a non-AP STA may also (or alternatively) be performed by an AP STA.

[0202] Furthermore, while this disclosure may describe certain types of communication between different types of wireless nodes (e.g., between AP STAs and non-AP STAs), the same or similar types of communication may occur between the same type of wireless nodes (e.g., in a peer-to-peer scenario, between AP STAs or between non-AP STAs). Additionally, communication may occur in the reverse order described.

[0203] Various modifications to the examples described herein will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples without departing from the spirit or scope of this disclosure. Therefore, the claims are not intended to be limited to the examples shown herein, but are to be granted the widest scope consistent with this disclosure, the principles disclosed herein, and the novel features.

[0204] Additionally, the various features described in this specification in the context of individual examples may also be implemented in combination in a single specific implementation. Conversely, the various features described in the context of a single specific implementation may also be implemented individually or in any suitable sub-combination in multiple examples. Thus, although features may be described above as functioning in a particular combination, and even initially claimed in this way, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0205] Similarly, although operations are depicted in a specific order in the diagrams, this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or to perform all illustrated operations to achieve the desired result. Furthermore, the accompanying figures may schematically depict one or more example processes in the form of flowcharts or flow diagrams. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some environments, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the examples described above should not be construed as requiring such separation in all examples, but rather should be understood as meaning that the described program components and systems can generally be integrated together in a single software product or encapsulated in multiple software products.

Claims

1. An apparatus for wireless communication, the apparatus comprising: At least one memory, the at least one memory including computer-executable instructions; and One or more processors, the one or more processors being configured to execute the computer-executable instructions to cause the device to: A first frame is obtained indicating that the wireless node is capable of supporting a coordinated communication scheme, wherein the device is associated with a first basic service set (BSS) and the wireless node is associated with a second BSS; A session is established with the wireless node by exchanging information about one or more features of the coordinated communication scheme supported by the device and the wireless node. as well as Participation in the session is based on one or more parameters associated with the exchange of information, using the coordinated communication scheme described above.

2. The apparatus of claim 1, wherein said one or more features relate to at least one of the following: Coordinated Time Division Multiple Access (TDMA), Coordinated Space Reuse (SR), Coordinated Constrained Target Wake-up Time (C-RTWT), Coordinated Orthogonal Frequency Division Multiple Access (OFDMA), Coordinated Beamforming (BF), Coordinated Preemption, or other coordinated techniques.

3. The apparatus of claim 1, wherein the apparatus and the wireless node are associated with a single mobile domain (SMD) multi-link device (MLD).

4. The apparatus of claim 1, wherein the one or more processors are further configured to cause the apparatus to: The output indicates that the device is capable of supporting the coordinated communication scheme, wherein the first frame is obtained after the second frame is output.

5. The apparatus of claim 1, wherein the exchange of information involves at least one of the following: At least one request frame and at least one response frame; or At least one notification frame and at least one acknowledgment frame.

6. The apparatus of claim 5, wherein the exchange of the at least one request frame and the at least one response frame involves or uses a security key.

7. The apparatus of claim 1, wherein the one or more processors are further configured to cause the apparatus to exchange additional information with the wireless node to perform at least one of the following: Dynamically enable one or more features of the coordinated communication scheme, or Dynamically disable one or more features of the coordinated communication scheme.

8. The apparatus according to claim 7, wherein: The device and the wireless node are multi-link devices (MLDs); and The exchange of additional information dynamically enables or disables one or more features of the coordinated communication scheme for multiple links.

9. The apparatus of claim 1, wherein the one or more processors are further configured to cause the apparatus to participate in the process of terminating the session.

10. The apparatus according to claim 1, wherein: At least one of the device or the wireless node is in a power-saving mode; and The session or the frames involved in the establishment of the session are at least one of the following: After a frame indicating an intention to wake up at least one of the devices or wireless nodes in power-saving mode, or Output during service hours when at least one of the devices or wireless nodes in power-saving mode is in active mode or awake state.

11. The apparatus of claim 1, wherein the exchange of information involves at least one action frame having a field set to a value to indicate one or more action frames of information to be used in the coordinated communication scheme.

12. The apparatus of claim 11, wherein the at least one action frame comprises a plurality of profile segments, each profile segment comprising information for different features of the coordinated communication scheme.

13. The apparatus according to claim 11, wherein: Different types of action frames are used to exchange information about different features of the coordinated communication scheme; and The field is set to a specific value to indicate one of the different types of action frames.

14. The apparatus of claim 13, wherein at least one of the number of fields, the order of fields, the field name, or the element name in the action frame depends on the corresponding action frame type.

15. The apparatus of claim 11, wherein at least one common type of the at least one action frame is used to exchange information for different features of the coordinated communication scheme.

16. The apparatus of claim 15, wherein the at least one common type is associated with at least one or more fields for conveying information for the different characteristics.

17. The apparatus of claim 11, wherein the at least one action frame or at least one of the one or more action frames includes an information element (IE) for exchanging information about different features of the coordinated communication scheme.

18. The apparatus of claim 17, wherein the IE includes a bitmap indicating which subfields exist.

19. A first access point, the first access point comprising: At least one transceiver; At least one memory, the at least one memory including computer-executable instructions; and One or more processors, the one or more processors being configured to execute the computer-executable instructions and cause the first access point to: A first frame indicating that a second access point can support a coordinated communication scheme is received via the at least one transceiver, wherein the first access point is associated with a first basic service set (BSS) and the second access point is associated with a second BSS; A session is established with the second access point by exchanging information about one or more features of the coordinated communication scheme supported by the first and second access points. as well as Participation in the session is based on one or more parameters associated with the exchange of information, using the coordinated communication scheme described above.

20. A method for performing wireless communication at a first wireless node, the method comprising: A first frame is obtained indicating that the second wireless node is capable of supporting a coordinated communication scheme, wherein the first wireless node is associated with a first basic service set (BSS) and the second wireless node is associated with a second BSS; A session is established with the second wireless node by exchanging information with the second wireless node about one or more features of the coordinated communication scheme supported by the first wireless node and the second wireless node. as well as Participation in the session is based on one or more parameters associated with the exchange of information, using the coordinated communication scheme described above.

Images