Method and apparatus for defining structure of trigger frame for co-SR / co-BF transmission in wireless LAN system

Abstract

Proposed are a method and an apparatus for defining a structure of a trigger frame for Co-SR / Co-BF transmission in a wireless LAN system. Specifically, a first AP transmits a coordination invitation frame to a second AP. The first AP receives a coordination response frame from the second AP. The first AP transmits a coordination trigger frame to the second AP. The coordination invitation frame is defined as a trigger frame for MAPC transmission. The trigger frame for the MAPC transmission comprises a common information field, a feedback user field, and a user information field. A value of a GI And UHR-LTF type field of the common information field is set to 3. A value of a first AID12 field of a feedback user information field is set to 2008.

Description

Method and apparatus for defining the structure of a trigger frame for performing CO-SR / CO-BF transmission in a wireless LAN system

[0001] This specification relates to a technique for defining the structure of a trigger frame for performing Co-SR / Co-BF transmission in a wireless LAN system, and more specifically, to a procedure for exchanging frames by including information necessary for Co-SR / Co-BF transmission in the common information field, special user information field, feedback user information field, or user information field of said trigger frame.

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability when transmitting signals to STAs, and to this end, various technologies are being considered to support high throughput, low latency, and extended range. For example, multiple APs can cooperate to perform a TXOP sharing procedure.

[0003] This specification proposes a method and apparatus for defining the structure of a trigger frame for performing Co-SR / Co-BF transmission in a wireless LAN system.

[0004] One example of the present specification proposes a method for defining the structure of a trigger frame for performing Co-SR / Co-BF transmission.

[0005] This embodiment can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi). The next-generation wireless LAN system is a wireless LAN system that improves upon the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0006] This embodiment may be performed at a first AP. The first AP may be a MAPC requesting AP that initiates MAPC negotiation with the second AP regarding at least one MAPC technique. The second AP may be a MAPC responding AP that responds to the MAPC requesting AP. Additionally, the first and second APs may be established as a coordinating AP or a coordinated AP through the MAPC negotiation.

[0007] The present embodiment proposes a trigger frame-based trigger procedure for performing Co-SR / Co-BF transmission. Specifically, the present embodiment defines the structure of a cooperative invitation frame or a cooperative trigger frame and proposes a method for transmitting and receiving by including information necessary for said Co-SR / Co-BF transmission.

[0008] The first AP (access point) sends a Coordination Invite frame to the second AP.

[0009] The first AP receives a cooperation response frame from the second AP.

[0010] The first AP transmits a cooperation trigger frame to the second AP.

[0011] The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP. The second AP is a coordinated AP that participates in the MAPC transmission.

[0012] The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission. The above trigger frame for the above MAPC transmission includes a common information field, a special user field, a feedback user field, and a user information field.

[0013] At this time, the value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3. The above GI And UHR-LTF type field may be referred to as the GI And HE / EHT / UHR-LTF type field or the TXS (TXOP Sharing) mode field. By setting the value of the above GI And UHR-LTF type field to 3, the trigger frame for the above MAPC transmission can be defined as a trigger frame containing common information for the above MAPC transmission or information specific to the above MAPC technique. At this time, the above trigger frame for the above MAPC transmission is a SU transmission and may be a BSRP trigger frame or a MU-RTS TXS trigger frame. The response frame to the above trigger frame for the above MAPC transmission may be a non-TB (Trigger Based) PPDU or a non-HT (dup) PPDU.

[0014] Additionally, the value of the first AID12 field of the feedback user information field is set to 2008. The feedback user information field may be a user information field that does not include user-specific information but includes feedback information. The feedback user information field may be identified by the first AID12 field having a value of 2008 and may optionally exist in a BSRP NTB trigger frame generated by a UHR STA.

[0015] That is, the present embodiment defines the structure of a trigger frame for performing Co-SR / Co-BF transmission and proposes a procedure for exchanging frames by including information necessary for Co-SR / Co-BF transmission in the common information field, special user information field, feedback user information field, or user information field of said trigger frame.

[0016] According to the embodiments proposed in this specification, each cooperative AP can clearly receive necessary PHY / MAC parameters through frames of the same structure. Accordingly, parameters such as transmission timing, MCS, beam pattern, and transmission power can be precisely adjusted between multiple APs, thereby minimizing interference and improving beam alignment during Co-BF execution. Furthermore, by utilizing spatial reuse information included in the trigger frame, each AP can perform dynamic power control considering the transmission power and channel conditions of adjacent APs; this improves spatial reuse efficiency within the same channel and increases overall frequency resource utilization efficiency. Moreover, by explicitly sharing transmission-related PHY information among multiple APs through frame-level information exchange, transmission timing and power control can be performed with minimized interference. Consequently, collisions or interference between PPDUs can be effectively mitigated even when multiple APs transmit simultaneously. In addition, since the transmission sequence and transmission conditions between cooperative APs are clearly defined according to the structural definition of the trigger frame, explicit and highly reliable synchronization can be achieved compared to the existing implicit synchronization method, thereby improving the stability of the MAPC procedure. As a result, the configuration according to the present embodiment can increase the DL transmission throughput of the entire network by reducing interference and improving space reuse efficiency, and can achieve the effect of enabling stable and high-speed data transmission even in environments where multiple APs are densely packed.

[0017] FIG. 1 shows an example of a transmitting device and / or receiving device of the present specification.

[0018] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).

[0019] Figure 3 is a diagram illustrating a general link setup process.

[0020] FIG. 4 illustrates an example of a multi-link (ML).

[0021] FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present specification.

[0022] Figure 6 is a diagram showing the arrangement of resource units (RU) used for a 20 MHz PPDU.

[0023] Figure 7 is a diagram showing the arrangement of resource units (RU) used for a 40 MHz PPDU.

[0024] Figure 8 is a diagram showing the arrangement of resource units (RU) used for an 80 MHz PPDU.

[0025] Figure 9 shows the operation according to UL-MU.

[0026] Figure 10 shows an example of a channel used / supported / defined within the 2.4 GHz band.

[0027] FIG. 11 illustrates an example of a channel used / supported / defined within the 5 GHz band.

[0028] FIG. 12 illustrates an example of a channel used / supported / defined within the 6 GHz band.

[0029] FIG. 13 shows a modified example of a transmitting device and / or receiving device of the present specification.

[0030] Figure 14 illustrates operation according to a conventional STX operation.

[0031] Figure 15 illustrates an example of C-OFDMA (Coordinated OFDMA).

[0032] Figure 16 illustrates an example of Coordinated Beamforming (CBF).

[0033] Figure 17 illustrates an example of AP selection.

[0034] Figure 18 illustrates an example of JTX / JT.

[0035] Figure 19 shows an example of the operation of a MU-RTS TXS trigger frame with a value of 2 in the TXOP Sharing Mode subfield.

[0036] Figure 20 shows an example of coordinated TDMA operation.

[0037] Figure 21 illustrates an example of a BSRP TF-based Co-SR / Co-BF transmission trigger procedure.

[0038] FIG. 22 illustrates an example of a Co-SR / Co-BF transmission trigger procedure following a BSRP TF-based polling procedure.

[0039] Figure 23 illustrates Example-1 of a BSRP TF format based on existing GI values.

[0040] Figure 24 illustrates Example-2 of a BSRP TF format based on existing GI values.

[0041] Figure 25 illustrates Example-3 of a BSRP TF format based on existing GI values.

[0042] Figure 26 illustrates Example-1 of the BSRP (UHR) TF format based on the new GI = 3 value.

[0043] Figure 27 illustrates an example of Common and Special User Info fields of BSRP TF based on a new GI = 3 value.

[0044] Figure 28 illustrates Example-2 of the BSRP (UHR) TF format based on the new GI 3 value.

[0045] FIG. 29 illustrates an example of a method using Special User Info (2007) and Feedback User Info (2008).

[0046] FIG. 30 illustrates an example of a method including Co-BF Per-User information.

[0047] Figure 31 illustrates an example of a method for including all Co-BF PHY Common information in the Feedback User Info field.

[0048] Figure 32 illustrates an example of a method for including all Co-BF PHY Common information in the User Info field.

[0049] FIG. 33 illustrates Example-1 of a method including Co-BF Per-User information based on the Feedback Type field.

[0050] FIG. 34 illustrates Example-2 of a method including Co-BF Per-User information based on the Feedback Type field.

[0051] Figure 35 illustrates Example-1 of a method containing all Co-BF information with two signaling fields.

[0052] Figure 36 illustrates an example of a BSRP (UHR) Trigger frame that serves as an ICF in the Polling procedure.

[0053] FIG. 37 illustrates an example of a BSRP (UHR) TF format containing information related to Co-BF transmission within the padding.

[0054] Figure 38 illustrates an example of Common / User Info in the BSRP TF format based on existing GI And UHR-LTF Type values.

[0055] FIG. 39 illustrates Special User Info Example-1 of the BSRP TF format based on existing GI And UHR-LTF Type values.

[0056] FIG. 40 illustrates Special User Info Example-2 of the BSRP TF format based on existing GI And UHR-LTF Type values.

[0057] Figure 41 illustrates Special User Info Example-3 in BSRP TF format based on existing GI And UHR-LTF Type values.

[0058] FIG. 42 illustrates an example of utilizing Common reuse, Special User (2007), and new Special User (2008 or later).

[0059] Figure 43 illustrates an example of reusing some information and utilizing reserved information from Common and Special User (2007).

[0060] FIG. 44 illustrates an example of a method including Co-BF Per-User information.

[0061] FIG. 45 illustrates an example in which all information is included in the Feedback User or User Info field.

[0062] FIG. 46 illustrates an example of a method for including Co-BF Sync Per-User information based on a Feedback Type field.

[0063] FIG. 47 illustrates an example of the BSRP TF format based on the new GI And UHR-LTF Type value, Example-1: Special User utilization.

[0064] FIG. 48 illustrates an example of the BSRP TF format based on the new GI And UHR-LTF Type value, Example-2: Special User not utilized.

[0065] FIG. 49 illustrates an example-3 of a BSRP TF format based on a new GI And UHR-LTF Type value: an example excluding some information.

[0066] Figure 50 illustrates Special User Info Example-4 in BSRP TF format based on a new GI 3 value.

[0067] Figure 51 illustrates an example of a BSRP (UHR) Trigger frame in a Triggering procedure.

[0068] FIG. 52 illustrates an example of a BSRP (UHR) TF format containing information related to Co-BF transmission within the padding.

[0069] FIG. 53 illustrates an example of a BSRP TF format containing information related to Co-BF transmission using a PHY Version Identifier value.

[0070] FIG. 54 illustrates an example of a MU-RTS TXS TF-based Co-BF transmission trigger procedure.

[0071] FIG. 55 illustrates Example-1 of a procedure in which a DAP that receives a MU-RTS TXS TF configures and transmits a Co-BF PPDU.

[0072] FIG. 56 illustrates Example-2 of a procedure in which a DAP that receives a MU-RTS TXS TF configures and transmits a Co-BF PPDU.

[0073] FIG. 57 illustrates an example-1 of the Common Info field within the MU-RTS TXS TF for triggering Co-BF transmission.

[0074] FIG. 58 illustrates an example of a User Info field within a MU-RTS TXS TF for triggering Co-BF transmission.

[0075] FIG. 59 illustrates an example of the configuration of the UHR Special User Info field-(1).

[0076] FIG. 60 illustrates an example of the configuration of the Common Info field and UHR Special User Info field-(2).

[0077] FIG. 61 illustrates an example of a MU-RTS Trigger frame for triggering Co-BF transmission.

[0078] FIG. 62 illustrates an example-1 of a MU-RTS TXS TF format containing Co-BF transmission-related information within the padding.

[0079] FIG. 63 illustrates an example-1 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0080] FIG. 64 illustrates an example-2 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0081] FIG. 65 illustrates an example-3 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0082] Figure 66 illustrates Example-1 of a BSRP TF format based on existing GI And HE / EHT / UHR-LTF Type / TXS Mode values.

[0083] Figure 67 illustrates Example-2 of a BSRP TF format based on existing GI values.

[0084] Figure 68 illustrates Example-3 of a BSRP TF format based on existing GI values.

[0085] Figure 69 illustrates Example-4 of a BSRP TF format based on existing GI values.

[0086] FIG. 70 illustrates an example of a BSRP TF format based on new GI3 values: an example using Common Info and User Info.

[0087] FIG. 71 illustrates an example of a BSRP TF format based on a new GI3 value, Example-2(a): using Common Info.

[0088] FIG. 72 illustrates an example of a BSRP TF format based on a new GI3 value, Example-2(b): using Common Info.

[0089] FIG. 73 illustrates an example of using Special User Info in the BSRP TF format based on the new GI3 value, Example-2(c): Special User Info.

[0090] FIG. 74 illustrates an example of a BSRP TF format based on a new GI3 value, Example-3(a): using new User Info.

[0091] FIG. 75 illustrates an example of using Feedback User Info in the BSRP TF format based on the new GI3 value, Example-3(b): Feedback User Info.

[0092] FIG. 76 illustrates an example of a BSRP TF format including one or more User Info fields: an example using Co-SR Info Type.

[0093] Figure 77 illustrates an example of a BSRP (UHR) Trigger frame that serves as an ICF in the Polling procedure.

[0094] FIG. 78 illustrates an example of a BSRP (UHR) TF format containing information related to Co-SR transmission within the padding.

[0095] Figure 79 illustrates Example-1 of a BSRP TF format based on existing GI values.

[0096] Figure 80 illustrates Example-2 of a BSRP TF format based on existing GI values.

[0097] FIG. 81 illustrates Example 3(a) of a BSRP TF format based on existing GI values.

[0098] FIG. 82 illustrates Example-3(b) of a BSRP TF format based on existing GI values.

[0099] Figure 83 illustrates Example-4 of a BSRP TF format based on existing GI values.

[0100] FIG. 84 illustrates an example of a BSRP TF format based on new GI3 values, Example-1: using Common and User Info.

[0101] FIG. 85 illustrates an example-2 of a BSRP TF format based on new GI3 values: using Common and Special User Info.

[0102] FIG. 86 illustrates an example of a BSRP TF format based on new GI3 values, Example-2: using Common and Special (new) Info.

[0103] FIG. 87 illustrates an example of a BSRP TF format based on new GI3 values: an example using Special User and Feedback User Info.

[0104] Figure 88 shows Example-3 of the BSRP (UHR) TF format based on the new GI = 3 value.

[0105] Figure 89 illustrates an example of a BSRP (UHR) Trigger frame that serves as an ICF in a Triggering procedure.

[0106] FIG. 90 illustrates an example of a BSRP (UHR) TF format containing information related to Co-SR transmission within the padding.

[0107] FIG. 91 illustrates an example of a BSRP TF format containing information related to Co-SR transmission using a PHY Version Identifier value.

[0108] FIG. 92 illustrates an example of a BSRP (GI3) TF format containing information related to Co-SR transmission using a PHY Version Identifier value.

[0109] FIG. 93 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.

[0110] FIG. 94 is a flowchart illustrating the operation of a receiving device according to the present embodiment.

[0111] FIG. 95 is a flowchart illustrating the procedure for receiving a cooperative trigger frame to perform Co-SR / Co-BF transmission according to the present embodiment.

[0112] FIG. 96 is a flowchart illustrating the procedure for transmitting and configuring a cooperative trigger frame to perform Co-SR / Co-BF transmission according to the present embodiment.

[0113] In this specification, “A or B” may mean “only A,” “only B,” or “both A and B.” Alternatively, in this specification, “A or B” may be interpreted as “A and / or B.” For example, in this specification, “A, B or C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.”

[0114] As used herein, a slash ( / ) or a comma may mean “and / or.” For example, “A / B” may mean “and / or B.” Accordingly, “A / B” may mean “only A,” “only B,” or “both A and B.” For example, “A, B, C” may mean “A, B, or C.”

[0115] In this specification, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in this specification, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted as synonymous with “at least one of A and B.”

[0116] Additionally, parentheses used in this specification may mean “for example.” Specifically, when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be proposed as an example of “control information.” In other words, the “control information” of this specification is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be proposed as an example of “control information.” Furthermore, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be proposed as an example of “control information.”

[0117] Additionally, as used herein, “a / an” may mean “at least one” or “one or more.” Also, terms ending in “(s)” may mean “at least one” or “one or more.”

[0118] Additionally, the expressions “based on,” “on the basis of,” or “according to” as used herein mean “based at least in part on,” and do not mean “based only on one.”

[0119] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0120] The following examples of this specification may be applied to various wireless communication systems. For example, the following examples of this specification may be applied to wireless local area network (WLAN) systems. For example, this specification may be applied to IEEE 802.11a / g / n / ac / ax / be / bn standards. In addition, the examples of this specification may be applied to Ultra High Reliability (UHR) standards or next-generation wireless LAN standards that enhance IEEE 802.11bn. In addition, the examples of this specification may be applied to mobile communication systems. For example, they may be applied to mobile communication systems based on Long Term Evolution (LTE) and its evolution based on 3GPP (3rd Generation Partnership Project) standards.

[0121] To explain the technical features of this specification, the technical features to which this specification can be applied are described below.

[0122] FIG. 1 shows an example of a transmitting device and / or receiving device of the present specification.

[0123] An example of FIG. 1 can perform various technical features described below. FIG. 1 relates to at least one STA (station). For example, the STA (110, 120) of this specification may also be referred to by various names such as mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, or simply user. The STA (110, 120) of this specification may also be referred to by various names such as network, base station, Node-B, Access Point (AP), repeater, router, relay, etc. The STA (110, 120) of this specification may also be referred to by various names such as receiving apparatus, transmitting device, receiving STA, transmitting STA, receiving device, transmitting device, etc.

[0124] For example, the STA (110, 120) can perform the role of an access point (AP) or a non-AP. That is, the STA (110, 120) of this specification can perform the functions of an AP and / or a non-AP. In this specification, an AP may also be indicated as an AP STA.

[0125] The STA (110, 120) of this specification may support various communication standards other than the IEEE 802.11 standard. For example, it may support communication standards according to 3GPP standards (e.g., LTE, LTE-A, 5G NR standards). In addition, the STA of this specification may be implemented in various devices such as mobile phones, vehicles, and personal computers. Furthermore, the STA of this specification may support communication for various communication services such as voice calls, video calls, data communication, and self-driving.

[0126] In this specification, the STA (110, 120) may include a medium access control (MAC) that complies with the provisions of the IEEE 802.11 standard and a physical layer interface for the wireless medium.

[0127] Based on side drawing (a) of Fig. 1, STA (110, 120) is described as follows.

[0128] The first STA (110) may include a processor (111), memory (112), and a transceiver (113). The illustrated processor, memory, and transceiver may each be implemented as separate chips, or at least two blocks / functions may be implemented through a single chip.

[0129] The transceiver (113) of the first STA performs the operation of transmitting and receiving signals. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).

[0130] For example, the first STA (110) can perform the intended operation of the AP. For example, the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmitted signal, and perform control for transmitting the signal. The memory (112) of the AP can store the signal received through the transceiver (113) (i.e., the received signal) and the signal to be transmitted through the transceiver (i.e., the transmitted signal).

[0131] For example, the second STA (120) can perform the intended operation of a Non-AP STA. For example, the non-AP transceiver (123) performs the operation of transmitting and receiving signals. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).

[0132] For example, the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmitted signal, and perform control for transmitting the signal. The memory (122) of the Non-AP STA can store the signal received through the transceiver (123) (i.e., the received signal) and can store the signal to be transmitted through the transceiver (i.e., the transmitted signal).

[0133] For example, the operation of the device indicated as AP in the following specification may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is the AP, the operation of the device indicated as AP is controlled by the processor (111) of the first STA (110), and related signals may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110). Additionally, control information related to the operation of the AP or the transmission / reception signals of the AP may be stored in the memory (112) of the first STA (110). Additionally, if the second STA (110) is the AP, the operation of the device indicated as AP is controlled by the processor (121) of the second STA (120), and related signals may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP or the transmission / reception signals of the AP can be stored in the memory (122) of the second STA (110).

[0134] For example, the operation of a device indicated as non-AP (or User-STA) in the following specification may be performed in the STA (110) or the second STA (120). For example, if the second STA (120) is non-AP, the operation of the device indicated as non-AP is controlled by the processor (121) of the second STA (120), and related signals may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). Additionally, control information related to the operation of the non-AP or the transmission / reception signals of the AP may be stored in the memory (122) of the second STA (120). For example, if the first STA (110) is a non-AP, the operation of the device marked as non-AP is controlled by the processor (111) of the first STA (110), and the related signal can be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). Additionally, control information related to the operation of the non-AP or the transmission / reception signal of the AP can be stored in the memory (112) of the first STA (110).

[0135] In the following specification, a device referred to as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, a device indicated without specific drawing symbols as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may also refer to the STA (110, 120) of FIG. 1. For example, in the following example, the operation of various STAs transmitting and receiving signals (e.g., PPDU) may be performed by the transceivers (113, 123) of FIG. 1. Additionally, in the following example, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processors (111, 121) of FIG. 1.For example, an example of an operation to generate a transmission / reception signal or to perform data processing or operations in advance for a transmission / reception signal may include: 1) an operation to determine / acquire / configure / operate / decode / encode bit information of sub-fields (SIG, STF, LTF, Data) included in the PPDU; 2) an operation to determine / configure / acquire time resources or frequency resources (e.g., subcarrier resources) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 3) an operation to determine / configure / acquire specific sequences (e.g., pilot sequence, STF / LTF sequence, extra sequence applied to SIG) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 4) a power control operation and / or power saving operation applied to the STA; and 5) an operation related to determining / acquiring / configuring / operating / decoding / encoding of an ACK signal. In addition, in the following example, various information (e.g., information related to fields, subfields, control fields, parameters, power, etc.) used by various STAs for determining / acquiring / configuring / calculating / decoding / encoding of transmission and reception signals can be stored in the memory (112, 122) of FIG. 1.

[0136] The device / STA of the aforementioned supplementary drawing (a) of FIG. 1 can be modified as shown in supplementary drawing (b) of FIG. 1. Hereinafter, the STA (110, 120) of this specification will be described based on supplementary drawing (b) of FIG. 1.

[0137] For example, the transceiver (113, 123) shown in side drawing (b) of FIG. 1 can perform the same function as the transceiver shown in side drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) shown in side drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122). The processor (111, 121) and the memory (112, 122) shown in side drawing (b) of FIG. 1 can perform the same function as the processor (111, 121) and the memory (112, 122) shown in side drawing (a) of FIG. 1 described above.

[0138] The mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, user, User STA, network, Base Station, Node-B, AP (Access Point), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving Device, transmitting Device, receiving Apparatus, and / or transmitting Apparatus described below may refer to the STA (110, 120) shown in side drawings (a) / (b) of FIG. 1, or the processing chip (114, 124) shown in side drawing (b) of FIG. 1. That is, the technical features of the present specification may be performed in the STA (110, 120) shown in side drawings (a) / (b) of FIG. 1, or only in the processing chip (114, 124) shown in side drawing (b) of FIG. 1. For example, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal generated in the processor (111, 121) shown in side drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) shown in side drawings (a) / (b) of FIG. 1. Alternatively, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal to be transmitted from the processing chip (114, 124) shown in side drawing (b) of FIG. 1 is generated to the transceiver (113, 123).

[0139] For example, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal being received by the transceiver (113, 123) shown in side view (a) of FIG. 1. Alternatively, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal received by the transceiver (113, 123) shown in side view (a) of FIG. 1 being acquired by the processor (111, 121) shown in side view (a) of FIG. 1. Alternatively, the technical feature of the receiving STA receiving a control signal can be understood as the technical feature of the control signal received by the transceiver (113, 123) shown in side view (b) of FIG. 1 being acquired by the processing chip (114, 124) shown in side view (b) of FIG. 1.

[0140] Referring to side view (b) of FIG. 1, software code (115, 125) may be included in memory (112, 122). The software code (115, 125) may include instructions that control the operation of the processor (111, 121). The software code (115, 125) may be included in various programming languages.

[0141] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. The processor may be an application processor (AP). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON™ series processor manufactured by Qualcomm®, an EXYNOSTM series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIO™ series processor manufactured by MediaTek®, an ATOM™ series processor manufactured by INTEL®, or a processor enhanced therefrom.

[0142] In this specification, an uplink may refer to a link for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, etc. may be transmitted through the uplink. Additionally, in this specification, a downlink may refer to a link for communication from an AP STA to a non-AP STA, and downlink PPDUs / packets / signals, etc. may be transmitted through the downlink.

[0143] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).

[0144] The top of Figure 2 shows the structure of the IEEE (Institute of Electrical and Electronic Engineers) 802.11 infrastructure BSS (basic service set).

[0145] The top of Figure 2 shows the structure of the IEEE (Institute of Electrical and Electronic Engineers) 802.11 infrastructure BSS (basic service set).

[0146] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter BSS). The BSS (200, 205) is a set of APs and STAs, such as an AP (access point, 225) and STA1 (Station, 200-1), that can communicate with each other by successfully synchronizing, and is not a concept referring to a specific area. The BSS (205) may include one or more STAs (205-1, 205-2) that can be combined with one AP (230).

[0147] The BSS may include at least one STA, an AP (225, 230) that provides a distribution service, and a distribution system (DS, 210) that connects multiple APs.

[0148] A distributed system (210) can implement an extended service set (ESS, 240) by connecting multiple BSSs (200, 205). The term ESS (240) may be used to refer to a network formed by connecting one or more APs through the distributed system (210). APs included in a single ESS (240) may have the same service set identification (SSID).

[0149] The portal (portal, 220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) with another network (e.g., 802.X).

[0150] In a BSS like the one at the top of Fig. 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented. However, it may also be possible to establish a network between STAs and perform communication without APs (225, 230). A network that establishes a network between STAs and performs communication without APs (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).

[0151] The bottom of Fig. 2 is a conceptual diagram showing IBSS.

[0152] Referring to the bottom of Fig. 2, the IBSS is a BSS that operates in ad-hoc mode. Since the IBSS does not include an AP, there is no centralized management entity that performs management functions centrally. That is, in the IBSS, the STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In the IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and since access to the distributed system is not allowed, they form a self-contained network.

[0153] Figure 3 is a diagram illustrating a general link setup process.

[0154] In the described S310 step, the STA can perform a network discovery operation. The network discovery operation may include the STA's scanning operation. That is, in order for the STA to access a network, it must find a network it can join. Before joining a wireless network, the STA must identify a compatible network, and the process of identifying networks existing in a specific area is called scanning. Scanning methods include active scanning and passive scanning.

[0155] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, the STA performing the scanning moves between channels and transmits a probe request frame to search for nearby APs, and waits for a response. The responder transmits a probe response frame as a response to the probe request frame to the STA that transmitted the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame from the BSS of the channel being scanned. In a BSS, the AP becomes the responder because it transmits the beacon frame, whereas in an IBSS, the responder is not constant because STAs within the IBSS take turns transmitting the beacon frame. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning in the same way (i.e., transmit and receive probe request / response on channel 2).

[0156] Although not shown in the example of Fig. 3, scanning operations may also be performed using a passive scanning method. An STA performing scanning based on passive scanning can wait for a beacon frame while switching between channels. A beacon frame is one of the management frames in IEEE 802.11, which announces the presence of a wireless network and is periodically transmitted to allow a scanning STA to find the wireless network and join it. In a BSS, the AP performs the role of periodically transmitting beacon frames, while in an IBSS, STAs within the IBSS take turns transmitting beacon frames. When a scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and records the beacon frame information in each channel while moving to another channel. An STA that has received a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning in the next channel in the same manner.

[0157] The STA that discovered the network can perform an authentication process through step S320. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described later. The authentication process of S320 may include the STA sending an authentication request frame to the AP, and the AP sending an authentication response frame to the STA in response. The authentication frame used in the authentication request / response corresponds to a management frame.

[0158] The authentication frame may include information regarding the authentication algorithm number, authentication transaction sequence number, status code, challenge text, RSN (Robust Security Network), Finite Cyclic Group, etc.

[0159] The STA can send an authentication request frame to the AP. Based on the information contained in the received authentication request frame, the AP can determine whether to allow authentication for the STA. The AP can provide the result of the authentication process to the STA through an authentication response frame.

[0160] A successfully authenticated STA may perform an association process based on step S330. The association process includes the STA sending an association request frame to the AP, and in response, the AP sending an association response frame to the STA. For example, the association request frame may include information regarding various capabilities, beacon listen interval, service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, Traffic Indication Map Broadcast request, interworking service capabilities, etc. For example, a connection response frame may include information related to various capabilities, status code, AID (Association ID), support rate, EDCA (Enhanced Distributed Channel Access) parameter set, RCPI (Received Channel Power Indicator), RSNI (Received Signal to Noise Indicator), mobility domain, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS map, etc.

[0161] Subsequently, in step S340, the STA may perform a security setup process. The security setup process of step S340 may include, for example, a process of setting up a private key through a 4-way handshake via an EAPOL (Extensible Authentication Protocol over LAN) frame.

[0162] FIG. 4 illustrates an example of a multi-link (ML).

[0163] As illustrated in FIG. 4, multiple multi-link devices (MLDs) can communicate through a multi-link. The MLDs can be classified into an AP MLD containing multiple AP STAs and a non-AP MLD containing multiple non-AP STAs. That is, the AP MLD may include affiliated APs (i.e., AP STAs), and the non-AP MLD may include affiliated STAs (i.e., non-AP STAs, or user-STAs).

[0164] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be assigned to the first and second links. The first and second multilinks may be identified by a link ID of 4 bits (or other n bits). The first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the link may be configured in different bands.

[0165] The AP MLD of FIG. 4 includes three affiliated APs. In one example of FIG. 4, AP1 may operate in the 2.4 GHz band, AP2 may operate in the 5 GHz band, and AP3 may operate in the 6 GHz band. In one example of FIG. 4, the first link in which AP1 and non-AP1 operate may be defined as a channel / subchannel / frequency resource within the 2.4 GHz band. Additionally, in one example of FIG. 4, the second link in which AP2 and non-AP2 operate may be defined as a channel / subchannel / frequency resource within the 5 GHz band. Additionally, in one example of FIG. 4, the third link in which AP3 and non-AP3 operate may be defined as a channel / subchannel / frequency resource within the 6 GHz band.

[0166] In one example of FIG. 4, AP1 can initiate a multilink setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In one example of FIG. 4, non-AP STA1 can transmit an Association Response frame in response to the Association Request frame. Each AP (e.g., AP1 / 2 / 3) shown in FIG. 4 may be the same as the AP shown in FIG. 1 and / or FIG. 2, and each non-AP (e.g., non-AP1 / 2 / 3) shown in FIG. 4 may be the same as the STA shown in FIG. 1 and / or FIG. 2 (i.e., user-STA or non-AP STA).

[0167] The specific features of this specification are not limited to the specific features of FIG. 4. That is, the number of links can be defined in various ways, and multiple links can be defined in various ways within at least one band.

[0168] FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present specification.

[0169] The STAs of this specification (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) can transmit and / or receive the PPDU of FIG. 5. The PPDU described in this specification may have the structure of FIG. 5, for example. Additionally, the PPDU described in this specification, the Ultra High Reliability (UHR) PPDU, may be referred to by various names such as transmit PPDU, receive PPDU, first type or N type PPDU. The PPDU described in this specification may be used in WLAN systems defined according to IEEE 802.11bn and / or next-generation WLAN systems that improve upon IEEE 802.11bn.

[0170] The PPDU of FIG. 5 may be related to various PPDU types used in a UHR system. For example, the example of FIG. 5 may be used for at least one of SU (single-user) mode / type / transmission, MU (multi-user) mode / type / transmission, and NDP (null data packet) mode / type / transmission related to channel sounding. For example, if the example of FIG. 5 is related to NDP, the illustrated Data field may be omitted. If the PPDU of FIG. 5 is used for TB (Trigger-based) mode, the UHR-SIG of FIG. 5 may be omitted. In other words, an STA that receives a Trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU in which the UHR-SIG is omitted in the example of FIG. 5.

[0171] In FIG. 5, L-STF to UHR-LTF can be called a preamble or physical preamble and can be generated / transmitted / received / acquired / decoded at the physical layer (included in the transmitting / receiving STA).

[0172] Each block illustrated in FIG. 5 may be referred to as a field / subfield / signal, etc. As illustrated in FIG. 5, the names of these fields / subfields / signals may be L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.

[0173] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in Fig. 5 can be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields can be set to 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields can be displayed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields can be displayed in units of 78.125 kHz.

[0174] The PPDU of Fig. 5, L-LTF and L-STF, may be the same as conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0175] The L-SIG field of FIG. 5 may contain, for example, 24 bits of bit information. For example, the 24 bits of information may include a 4-bit Rate field, a 1-bit Reserved bit, a 12-bit Length field, a 1-bit Parity bit, and a 6-bit Tail bit. For example, the 12-bit Length field may contain information regarding the length or time duration of the PPDU. For example, the value of the 12-bit Length field may be determined based on the type of the PPDU. For example, if the PPDU is a non-HT (non-High Throughput), HT (High Throughput), VHT (Very High Throughput) PPDU, or an EHT (extremely high throughput) PPDU, or a UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is an HE PPDU, the value of the Length field may be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, for non-HT, HT, VHT PPDU, or EHT PPDU, UHR PPDU, the value of the Length field can be determined as a multiple of 3, and for HE (High-Efficiency) PPDU, the value of the Length field can be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, the Length field in a UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.

[0176] For example, a (non-AP and AP) STA can apply BCC encoding based on a code rate of 1 / 2 to 24 bits of information in the L-SIG field. Subsequently, the transmitting STA can obtain 48 bits of BCC encoding. BPSK modulation can be applied to the 48 bits of encoding to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarrier {subcarrier indices -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. Consequently, the 48 BPSK symbols can be mapped to subcarrier indices -26 to -22, -20 to -8, -6 to -1, +1 to +6, +8 to +20, and +22 to +26. The transmitting STA can additionally map the signal of {-1, -1, -1, 1} to the subcarrier index {-28, -27, +27, +28}. The above signal can be used for channel estimation for the frequency domain corresponding to {-28, -27, +27, +28}.

[0177] For example, the (non-AP and AP) STA can generate an RL-SIG that is identical to the L-SIG. BPSK modulation may be applied to the RL-SIG. The receiving (non-AP and AP) STA can determine that the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of the RL-SIG. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the HE PPDU, EHT PPDU, or UHR PPDU if the RL-SIG is present. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the non-HT PPDU, HT PPDU, or VHT PPDU if the RL-SIG is not present. In other words, the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.

[0178] After the RL-SIG in Fig. 5, a U-SIG (Universal SIG) may be inserted. The U-SIG may be referred to by various names such as the first SIG field, first SIG, first type SIG, control signal, control signal field, first (type) control signal, common control field, and common control signal.

[0179] U-SIG may contain N bits of information and may contain information to identify the type of EHT PPDU. For example, U-SIG may be constructed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol for U-SIG (e.g., OFDM symbol) may have a duration of 4 us. Each symbol of U-SIG may be used to transmit 26 bits of information. For example, each symbol of U-SIG may be transmitted and received based on 52 data tones and 4 pilot tones.

[0180] For example, A bit information (e.g., 52 un-coded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bit information (e.g., 26 un-coded bits) of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bit information (e.g., 26 un-coded bits) of the total A bit information. For example, the transmitting STA can obtain the 26 un-coded bits included in each U-SIG symbol. The transmitting STA can generate 52-coded bits by performing convolutional encoding (i.e., BCC encoding) based on a rate of R=1 / 2 and can perform interleaving on the 52-coded bits. The transmitting STA can generate 52 BPSK symbols assigned to each U-SIG symbol by performing BPSK modulation on the interleaved 52-coded bits. A single U-SIG symbol can be transmitted based on 56 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, excluding DC index 0. 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers), excluding the pilot tones -21, -7, +7, and +21.

[0181] For example, A bit information (e.g., 52 un-coded bits) transmitted by U-SIG may include a CRC field (e.g., a field of 4 bits) and a tail field (e.g., a field of 6 bits). The CRC field and the tail field may be transmitted through a second symbol of U-SIG. The CRC field may be generated based on 26 bits assigned to the first symbol of U-SIG and the remaining 16 bits within the second symbol excluding the CRC / tail field, and may be generated based on a conventional CRC calculation algorithm. Additionally, the tail field may be used to terminate the trellis of a convolutional decoder and may be set, for example, to "000000".

[0182] A bit information (e.g., 52 un-coded bits) transmitted by U-SIG (or U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, the size of the version-independent bits can be fixed or variable. For example, the version-independent bits may be assigned only to the first symbol of U-SIG, or the version-independent bits may be assigned to both the first and second symbols of U-SIG. For example, the version-independent bits and the version-dependent bits may be referred to by various names, such as the first control bit and the second control bit.

[0183] For example, the version-independent bits of U-SIG may include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier may include information related to the PHY version of the transmitted and received PPDU. For example, a first value of the 3-bit PHY version identifier (e.g., a value of 000) may indicate that the transmitted and received PPDU is an EHT PPDU. Additionally, a second value of the 3-bit PHY version identifier (e.g., a value of 001) may indicate that the transmitted and received PPDU is a UHR PPDU.

[0184] In other words, when an (AP / non-AP) STA transmits an EHT PPDU, it can set a 3-bit PHY version identifier to a first value. In other words, a receiving (AP / non-AP) STA can determine that the received PPDU is an EHT PPDU based on the PHY version identifier having the first value, and can determine that the received PPDU is a UHR PPDU based on the PHY version identifier having the second value.

[0185] For example, the version-independent bits of U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field is related to UL communication, and the second value of the UL / DL flag field is related to DL communication.

[0186] For example, the version-independent bits of U-SIG may include information regarding the length of the TXOP (transmission opportunity) and information regarding the BSS color ID.

[0187] For example, if the UHR PPDU is classified into various types (e.g., type related to SU transmission (performed based on UL or DL), type related to DL transmission, type related to NDP transmission, type related to DL non-MU-MIMO, type related to DL MU-MIMO, type related to Multi-AP operation, type related to Co-BF (Coordinated beamforming) and SR (Spatial Reuse), type related to C-OFDMA (Coordinated OFDMA), type related to Co-TDMA (Coordinated TDMA)), information regarding the type of the EHT PPDU (e.g., 2-bit or 3-bit information) may be included in the version-dependent bits of the U-SIG.

[0188] For example, U-SIG may include: 1) a bandwidth field containing information regarding bandwidth; 2) a field containing information regarding the MCS technique applied to UHR-SIG; 3) an indication field containing information regarding whether the dual subcarrier modulation (DCM) technique is applied to UHR-SIG; 4) a field containing information regarding the number of symbols used for UHR-SIG; 5) a field containing information regarding whether UHR-SIG is generated across the entire band; 6) a field containing information regarding the type of UHR-LTF / STF; and 7) information regarding a field indicating the length of UHR-LTF and CP length.

[0189] Preamble puncturing may be applied to the PPDU of Fig. 5. Preamble puncturing means applying puncturing to a portion of the total band of the PPDU (e.g., a secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA applies puncturing to the secondary 20 MHz band within the 80 MHz band and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

[0190] For example, the pattern of preamble puncturing can be pre-set. For example, when a first puncturing pattern is applied, puncturing may be applied only to a secondary 20 MHz band within an 80 MHz band. For example, when a second puncturing pattern is applied, puncturing may be applied only to one of two secondary 20 MHz bands included in a secondary 40 MHz band within an 80 MHz band. For example, when a third puncturing pattern is applied, puncturing may be applied only to a secondary 20 MHz band included in a primary 80 MHz band within a 160 MHz band (or 80+80 MHz band). For example, when the fourth puncturing pattern is applied, within the 160 MHz band (or 80+80 MHz band), the primary 40 MHz band included in the primary 80 MHz band is present, and puncturing may be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band.

[0191] Information regarding preamble puncturing applied to the PPDU may be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information regarding the contiguous bandwidth of the PPDU, and the second field of the U-SIG may include information regarding preamble puncturing applied to the PPDU.

[0192] For example, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. If the bandwidth of the PPDU exceeds 80 MHz, the U-SIG may be configured individually in 80 MHz units. For example, if the bandwidth of the PPDU is 160 MHz, the PPDU may include a first U-SIG for the first 80 MHz band and a second U-SIG for the second 80 MHz band. In this case, the first field of the first U-SIG may include information regarding the 160 MHz bandwidth, and the second field of the first U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding the preamble puncturing pattern). Additionally, the first field of the second U-SIG may include information regarding a 160 MHz bandwidth, and the second field of the second U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern). Meanwhile, the UHR-SIG following the first U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern), and the UHR-SIG following the second U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding a preamble puncturing pattern).

[0193] Additionally or generally, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. U-SIG may include information regarding preamble puncturing for all bands (i.e., information regarding preamble puncturing patterns). That is, UHR-SIG may not include information regarding preamble puncturing, and only U-SIG may include information regarding preamble puncturing (i.e., information regarding preamble puncturing patterns).

[0194] U-SIGs can be configured in 20 MHz units. For example, if an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included within an 80 MHz PPDU. PPDUs exceeding the 80 MHz bandwidth may contain different U-SIGs.

[0195] The UHR-SIG of FIG. 5 may include control information for a receiving STA. The UHR-SIG may be transmitted through at least one symbol, and one symbol may have a length of 4 us. Information regarding the number of symbols used for the UHR-SIG may be included in the U-SIG.

[0196] UHR-SIG provides additional signals to the U-SIG field, enabling the STA to interpret / decode the UHR PPDU. The UHR-SIG field may include U-SIG overflow bits that apply commonly to all users. Additionally, the UHR-SIG field contains resource allocation information, making it possible for the STA to look up resources used in fields containing data fields / UHR-STF / UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).

[0197] The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 5 can be determined based on a RU (resource unit) defined by a plurality of subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of this specification can be transmitted / received through a RU (resource unit) defined by a plurality of subcarriers / tones.

[0198] FIG. 6 is a diagram showing the arrangement of resource units (RUs) used for a 20 MHz PPDU. That is, UHR-LTF, UHR-STF and / or data fields included in the 20 MHz PPDU can be transmitted / received through at least one of the various RUs defined in FIG. 6.

[0199] As shown at the top of Fig. 6, 26 units (i.e., units corresponding to 26 tones) may be arranged. Six tones may be used as a guard band in the leftmost band of the 20 MHz band, and five tones may be used as a guard band in the rightmost band of the 20 MHz band. Additionally, seven DC tones are inserted into the center band, i.e., the DC band, and 26 units corresponding to 13 tones may exist on the left and right sides of the DC band. Furthermore, 26 units, 52 units, and 106 units may be allocated to other bands. Each unit may be allocated for a receiving station, i.e., a user.

[0200] Meanwhile, the RU arrangement of Fig. 6 is utilized not only for situations involving multiple users (MU) but also for situations involving a single user (SU), in which case it is possible to use one 242-unit as shown at the bottom of Fig. 4, and in this case, three DC tones can be inserted.

[0201] In the example of FIG. 6, various sizes of RUs, namely 26-RU, 52-RU, 106-RU, 242-RU, etc., are proposed. Since the specific size of these RUs can be expanded or increased, the present embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones). In this specification, N-RU may be indicated as N-tone RU, etc. For example, 26-RU may be indicated as 26-tone RU.

[0202] Figure 7 is a diagram showing the arrangement of resource units (RU) used for a 40 MHz PPDU.

[0203] Just as various sizes of RUs were used in the example of FIG. 6, 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc., may also be used in the example of FIG. 7. Additionally, 5 DC tones may be inserted at the center frequency, 12 tones may be used as guard bands in the leftmost band of the 40 MHz band, and 11 tones may be used as guard bands in the rightmost band of the 40 MHz band.

[0204] In addition, as described, 484-RU may be used when used for a single user. Meanwhile, the specific number of RUs may be changed, as in the example of FIG. 6.

[0205] FIG. 8 is a diagram showing the arrangement of resource units (RUs) used for an 80 MHz PPDU. The arrangement of resource units (RUs) used in this specification may be varied. For example, the arrangement of resource units (RUs) used in the 80 MHz band may be varied.

[0206] FIG. 9 illustrates the operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can establish a channel connection through contending (i.e., Backoff operation) and transmit a Trigger frame (930). That is, the transmitting STA (e.g., AP) can transmit a PPDU containing the Trigger frame (930). When the PPDU containing the Trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

[0207] TB PPDUs (941, 942) may be transmitted at the same time and may be transmitted from multiple STAs (e.g., User STAs) with AIDs indicated within the Trigger frame (930). The ACK frame (950) for the TB PPDU may be implemented in various forms.

[0208] Figure 10 shows an example of a channel used / supported / defined within the 2.4 GHz band.

[0209] The 2.4 GHz band may be referred to by other names, such as the first band (band). Additionally, the 2.4 GHz band may refer to a frequency range in which channels with a center frequency adjacent to 2.4 GHz (e.g., channels with a center frequency located between 2.4 and 2.5 GHz) are used / supported / defined.

[0210] The 2.4 GHz band may include multiple 20 MHz channels. The 20 MHz channels within the 2.4 GHz band may have multiple channel indices (e.g., indices 1 through 14). For example, the center frequency of a 20 MHz channel assigned to channel index 1 may be 2.412 GHz, the center frequency of a 20 MHz channel assigned to channel index 2 may be 2.417 GHz, and the center frequency of a 20 MHz channel assigned to channel index N may be (2.407 + 0.005*N) GHz. Channel indices may be referred to by various names, such as channel numbers. The specific numerical values ​​of channel indices and center frequencies may change.

[0211] FIG. 10 illustrates four channels within a 2.4 GHz band as an example. The illustrated first frequency range (1010) to fourth frequency range (1040) may each include one channel. For example, the first frequency range (1010) may include channel 1 (a 20 MHz channel having index 1). In this case, the center frequency of channel 1 may be set to 2412 MHz. The second frequency range (1020) may include channel 6. In this case, the center frequency of channel 6 may be set to 2437 MHz. The third frequency range (1030) may include channel 11. In this case, the center frequency of channel 11 may be set to 2462 MHz. The fourth frequency range (1040) may include channel 14. In this case, the center frequency of channel 14 may be set to 2484 MHz.

[0212] FIG. 11 illustrates an example of a channel used / supported / defined within the 5 GHz band.

[0213] The 5 GHz band may be referred to by other names such as the second band / band. The 5 GHz band may refer to a frequency range in which channels with a center frequency of 5 GHz or higher and less than 6 GHz (or less than 5.9 GHz) are used / supported / defined. Alternatively, the 5 GHz band may include multiple channels between 4.5 GHz and 5.5 GHz. The specific figures shown in FIG. 11 may be changed.

[0214] Multiple channels within the 5 GHz band include UNII (Unlicensed National Information Infrastructure)-1, UNII-2, UNII-3, and ISM. UNII-1 may be referred to as UNII Low. UNII-2 may include frequency regions referred to as UNII Mid and UNII-2 Extended. UNII-3 may be referred to as UNII-Upper.

[0215] Multiple channels may be configured within the 5 GHz band, and the bandwidth of each channel may be varied, such as 20 MHz, 40 MHz, 80 MHz, or 160 MHz. For example, the 5170 MHz to 5330 MHz frequency range within UNII-1 and UNII-2 may be divided into eight 20 MHz channels. The 5170 MHz to 5330 MHz frequency range may be divided into four channels through a 40 MHz frequency range. The 5170 MHz to 5330 MHz frequency range may be divided into two channels through an 80 MHz frequency range. Alternatively, the 5170 MHz to 5330 MHz frequency range may be divided into one channel through a 160 MHz frequency range.

[0216] FIG. 12 illustrates an example of a channel used / supported / defined within the 6 GHz band.

[0217] The 6 GHz band may be referred to by other names such as the third band / band. The 6 GHz band may refer to a frequency range in which channels with a center frequency of 5.9 GHz or higher are used / supported / defined. The specific figures shown in FIG. 12 are subject to change.

[0218] For example, the 20 MHz channel of FIG. 12 can be defined starting from 5.940 GHz. Specifically, the leftmost channel among the 20 MHz channels of FIG. 12 may have index 1 (or channel index, channel number, etc.), and the center frequency may be assigned as 5.945 GHz. That is, the center frequency of the index N channel may be determined as (5.940 + 0.005*N) GHz.

[0219] Accordingly, the indices (or channel numbers) of the 20 MHz channel in FIG. 12 are 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, It may be 201, 205, 209, 213, 217, 221, 225, 229, 233. Also, according to the (5.940 + 0.005*N) GHz rule described above, the index of the 40 MHz channel of FIG. 12 may be 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 179, 187, 195, 203, 211, 219, 227.

[0220] FIG. 13 shows a modified example of a transmitting device and / or receiving device of the present specification.

[0221] The device illustrated in FIGS. 1 to 4 (e.g., AP STA, non-AP STA) can be modified as in FIG. 13. The transceiver (630) of FIG. 13 may be identical to the transceiver (113, 123) of FIG. 1. The transceiver (630) of FIG. 13 may include a receiver and a transmitter.

[0222] The processor (610) of FIG. 13 may be the same as the processor (111, 121) of FIG. 1. Or, the processor (610) of FIG. 13 may be the same as the processing chip (114, 124) of FIG. 1.

[0223] The memory (150) of FIG. 13 may be the same as the memory (112, 122) of FIG. 1. Alternatively, the memory (150) of FIG. 13 may be a separate external memory different from the memory (112, 122) of FIG. 1.

[0224] Referring to FIG. 13, a power management module (611) manages power for a processor (610) and / or a transceiver (630). A battery (612) supplies power to the power management module (611). A display (613) outputs results processed by the processor (610). A keypad (614) receives input to be used by the processor (610). The keypad (614) may be displayed on the display (613). A SIM card (615) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and associated keys used to identify and authenticate a subscriber in a mobile device such as a mobile phone and a computer.

[0225] Referring to FIG. 13, the speaker (640) can output sound-related results processed by the processor (610). The microphone (641) can receive sound-related inputs to be used by the processor (610).

[0226] The Multi-AP operation applicable to this specification is described below.

[0227] The above Multi-AP operation refers to a communication technique involving multiple APs in a WLAN. For example, the above Multi-AP operation may refer to an operation in which one or more APs transmit and receive information to one or more STAs. In contrast to the above Multi-AP operation, existing techniques may be expressed using various terms such as STX (Single Transmission). For example, the above STX operation may refer to a method in which a single BSS AP communicates with a single BSS STA. When communication is performed based on the above STX operation, interference may occur with adjacent APs (e.g., APs located in overlapping BSSs). Due to this interference, a problem may arise in which the transmission and reception performance of cell-edge users (e.g., non-AP STAs located at the edge of the BSS) is reduced.

[0228] FIG. 14 illustrates operation according to a conventional STX operation. As illustrated, interference between STA and AP may occur due to AP1 and AP2 being adjacent to each other.

[0229] To improve the above STX operation, the above Multi-AP operation is newly proposed. The above Multi-AP operation may be based on a technique that reduces various interferences, such as Inter-symbol interference (ISI), through coordination with neighboring APs (e.g., APs located in overlapping BSSs).

[0230] In Figure 14, STA1 and AP1 are included in the BSS, and STA2 and AP2 can be included in the OBSS (Overlapping Basic Service Set). That is, STA2 is an un-associated STA to AP1, and STA1 is an un-associated STA to AP2.

[0231] For example, the above Multi-AP operation may be classified into various technologies, types, formats, protocols, etc. For example, the above Multi-AP operation may include Co-TDMA (Coordinated TDMA) which distinguishes wireless resources allocated to multiple APs based on the time axis (time domain). Additionally or generally, the above Multi-AP operation may include C-OFDMA (Coordinated OFDMA) which distinguishes wireless resources allocated to multiple APs based on the frequency axis (time domain). Additionally or generally, the above Multi-AP operation may include Co-SR (Coordinated Spatial Reuse) which applies Spatial Reuse (SR) to at least one AP. Additionally or generally, the above Multi-AP operation may include Coordinated beamforming (CBF) / nulling which transmits by nulling interference occurring from neighbors (e.g., adjacent AP / STA, and / or OBSS AP / OBSS STA). Additionally or generally, the Multi-AP operation may include AP selection in which an AP among adjacent APs with good channel conditions (e.g., at least one AP located within a BSS or OBSS with excellent channel conditions) performs transmission. Additionally or generally, the Multi-AP operation may include Joint Transmission (JTX) or Joint Transmission (JT) in which multiple APs (e.g., multiple APs included in the same BSS / OBSS, or multiple APs included in different BSS / OBSSs) coordinate to perform simultaneous transmission and reception, and the JTX / JT may be implemented based on Joint Beamforming or Joint MU-MIMO.

[0232] FIG. 15 illustrates an example of C-OFDMA (Coordinated OFDMA). The illustrated AP1 can transmit a PPDU / signal to STA1, and AP2 can transmit a PPDU / signal to STA2. Transmission from AP1 and transmission from AP2 can be performed in the same / overlapping time interval. Transmission from AP1 to STA1 can be performed based on a first frequency band, and transmission from AP2 to STA2 can be performed based on a second frequency band different from the second frequency band. For example, in FIG. 15, STA1 and AP1 may be included in BSS, and STA2 and AP2 may be included in OBSS. That is, STA2 may be an un-associated STA to AP1, and STA1 may be an un-associated STA to AP2.

[0233] Although not shown in FIG. 15, an example of Co-TDMA (Coordinated TDMA) is also possible. For example, the acquired TXOP can be divided into specific time units (e.g., slots), and the divided slots can be sequentially assigned to multiple different APs.

[0234] The example of C-OFDMA described above may be further modified as follows. For example, an AP that has acquired a TXOP (e.g., AP1) may share frequency resources with at least one surrounding AP (e.g., AP2 present in BSS / OBSS). For example, the shared frequency resources may be defined in units of resource units (RU) or subchannels, and for example, considering flexibility, frequency resources may be shared by AP1 to AP2 in units of 20 / 40 / 80 MHz subchannels or 242 / 484 / 996-tone RUs.

[0235] AP1, which performs C-OFDMA, can perform the role of a sharing AP or a Master AP. That is, AP1 can request at least one nearby AP (e.g., AP2 in BSS / OBSS) to report information about the channel and / or buffer status. Based on this, AP1 acquires a TXOP and can share a portion of the frequency resources (e.g., a 20 MHz subchannel or a specific size RU) with at least one nearby AP (e.g., AP2 in BSS / OBSS) within all or part of the time interval associated with the TXOP.

[0236] FIG. 16 illustrates an example of Coordinated Beamforming (CBF). The illustrated AP1 can transmit a PPDU / signal to STA1, and AP2 can transmit a PPDU / signal to STA2. Transmission from AP1 and transmission from AP2 can be performed in the same / overlapping time intervals. Transmission from AP1 and transmission from AP2 can be performed through the same / overlapping frequency bands. To reduce interference caused by AP1 to STA2, AP1 can perform nulling / beamforming toward STA2, and to reduce interference caused by AP2 to STA1, AP2 can perform nulling / beamforming toward STA1. For example, such nulling / beamforming can be implemented by positioning a radiation null to a neighboring unassociated STA. The aforementioned nulling / beamforming can make a specific AP invisible to a neighboring unassociated STA. For example, the aforementioned nulling / beamforming can make AP1 (or AP2) invisible to STA2 (or STA1).

[0237] For example, in Fig. 16, STA1 and AP1 may be included in BSS, and STA2 and AP2 may be included in OBSS. That is, STA2 may be an un-associated STA to AP1, and STA1 may be an un-associated STA to AP2.

[0238] Although not shown in FIG. 16, control signals (e.g., coordination frames) for nulling / beamforming between AP1 and STA2 and / or nulling / beamforming between AP2 and STA1 can be transmitted and received through a backhaul link between AP1 and AP2.

[0239] FIG. 17 illustrates an example of AP selection. The illustrated AP2 is determined to have better channel conditions than AP1. AP1 transmits its data / signal to AP2 via a backhaul link, and AP2 can transmit a signal to STA1 instead of AP1. For example, in FIG. 17, STA1 and AP1 may be included in BSS, and STA2 and AP2 may be included in OBSS. That is, STA2 may be an un-associated STA to AP1, and STA1 may be an un-associated STA to AP2.

[0240] FIG. 18 illustrates an example of JTX / JT. The illustrated AP1 can perform transmission to STA1 together with AP2. For example, the PPDU / signal transmitted from AP2 to STA1 may be wholly or partially identical to the PPDU / signal transmitted from AP1 to STA1. For example, the PPDU / signal transmitted from AP2 to STA1 may be transmitted simultaneously through a frequency band that is identical to or overlaps with the PPDU / signal transmitted from AP1 to STA1. For example, the PPDU / signal transmitted from AP2 to STA1 may be a signal transmitted from AP1 via a backhaul link. For example, in FIG. 18, STA1 and AP1 may be included in a BSS, and STA2 and AP2 may be included in an OBSS. That is, STA2 may be an un-associated STA to AP1, and STA1 may be an un-associated STA to AP2.

[0241] More specifically, in FIG. 18, AP1 transmits a coordination request (or various names such as first request, control request, etc.) to AP2 and receives a coordination response (or various names such as first response, control response, etc.) from AP2. Through the exchange of the request / response, information regarding coordination between AP1 and AP2 (e.g., information regarding whether AP1 and AP2 will perform simultaneous transmission to STA1), information regarding the time when coordination begins, information regarding the time when AP1 and AP2 start simultaneous transmission to STA1, and information regarding data shared between AP1 and AP2 can be exchanged. AP1 can share its data with AP2 via a backhaul link. Subsequently, AP1 transmits a coordination trigger frame (or various names such as trigger frame, etc.) to AP2 and can perform simultaneous transmission to STA1 based on the trigger frame.

[0242] <Examples Applicable to the Present Specification>

[0243] Although a large number of APs are installed in close proximity to each other to enable terminals to maintain continuous WLAN connectivity over a wider area, issues such as radio interference and transmission collisions between APs may occur as the BSSs of multiple APs overlap. To resolve these issues, various technologies for coordinating APs in frequency, time, and spatial domains (e.g., RU selection, joint transmission, nulling, etc.) have been proposed, and attention must also be paid to the various issues that may arise during cooperation between APs.

[0244] In EHT (802.11be), a technique was proposed to allocate a portion of the time within the TXOP acquired by the AP to support Peer-to-Peer (P2P) transmission to non-AP STAs. To this end, a new TXOP Sharing Mode subfield was defined within the Common Info field of the existing MU-RTS Trigger frame, and a MU-RTS (Multi User-Request To Send) Trigger frame when this value is non-zero is referred to as a MU-RTS TXOP Sharing (TXS) Trigger frame (TF). If the value of TXOP Sharing mode is 1, the non-AP STA supports one or more (non-TB) PPDU transmissions to the AP, and if the value of TXOP Sharing mode is 2, the non-AP STA supports P2P transmission in addition to (non-TB) PPDU transmission to the AP.

[0245] Figure 19 shows an example of the operation of a MU-RTS TXS trigger frame with a value of 2 in the TXOP Sharing Mode subfield.

[0246] FIG. 19 shows an example of operation when the TXOP Sharing mode value is 2. When the AP transmits a MU-RTS TXS TF containing time allocation information (Time allocated in MU-RTS TXS Trigger Frame in FIG. 19) to non-AP STA 1, Non-AP STA 1 responds to this with a CTS (Clear-To-Send) and can then perform P2P transmission to non-AP STA 2.

[0247] Figure 20 shows an example of coordinated TDMA operation.

[0248] If the existing Triggered TXOP Sharing protocol is utilized for Multi-AP coordination, frame exchange can be performed without affecting each other by dividing transmissions within the BSS of each cooperating AP into time units. That is, FIG. 20 illustrates an example of Coordinated TDMA (Co-TDMA) based on time units among the cooperation methods between cooperating APs. In this case, the AP in the existing Triggered TXS protocol can be replaced with the AP that shares the TXOP in Multi-AP coordination, and the STA in the existing Triggered TXS protocol can be replaced with the AP that receives the shared TXOP in Multi-AP coordination. In this specification, the former is referred to as the Sharing AP (SAP), and the AP that receives the TXOP from the SAP is referred to as the Shared AP (DAP). Here, the designation SAP does not limit the entity sharing the TXOP to only the AP STA, but also includes non-AP STAs that share the TXOP. In addition, the designation DAP does not limit the entity receiving the TXOP sharing to only AP STAs, but also includes non-AP STAs that receive the TXOP (or perform transmission and reception with an AP STA that receives the TXOP). Furthermore, frame exchanges with non-AP STAs or SAPs belonging to the DAP BSS during the time allocated to the DAP are referred to as the DAP's BSS frame exchange (FE). For example, data frame transmissions and block ACK frame responses following RTS / CTS frame exchanges between the DAP and non-AP STAs, UL data frame transmissions by non-AP STAs in response to trigger frames transmitted from the DAP, or data frame transmissions by the DAP in response to trigger frames transmitted from the SAP may be performed.

[0249] Basically, in a Co-TDMA environment, since the SAP allocates time to the DAP, cooperative-based transmission can be triggered by utilizing the existing Triggered TXS protocol. That is, TXOP sharing between APs can be performed by including information for C-TDMA operation and signaling bits in the MU-RTS TXS TF. Meanwhile, Co-BF / SR, one of the Multi-AP cooperative-based technologies, is characterized by the fact that the SAP and DAP must precisely synchronize their timing and transmit simultaneously. Consequently, it is necessary to implement a new Trigger frame or modify an existing Trigger frame to initiate Co-BF transmission. The Trigger frame may also include new information for Co-BF transmission.

[0250] Accordingly, this specification defines the structure and format of a Trigger frame transmitted by an SAP to initiate Co-BF transmission with a DAP and / or to perform a polling procedure targeting one or more cooperating APs. Specifically, this specification utilizes a BSRP Trigger frame to trigger Co-BF transmission and / or perform a polling procedure. Additionally, or alternatively, a MU-RTS TXS Trigger frame is utilized to trigger Co-BF transmission.

[0251] Using the BSRP TF and / or MU-RTS TXS TF presented in this specification, SAP can determine whether to trigger Co-BF transmission to DAPs or to participate in Co-BF transmission from cooperating APs in a polling procedure.

[0252] Meanwhile, Co-SR, one of the foundational technologies for Multi-AP cooperation, is characterized by the fact that the DAP transmits in conjunction with triggering from SAP. Consequently, to initiate Co-SR transmission, it is necessary to implement a new trigger frame that can be delivered from SAP or to modify an existing trigger frame. This trigger frame may also include new information for Co-SR transmission.

[0253] Accordingly, this specification defines the structure and format of a Trigger frame that SAP transmits to initiate Co-SR transmission with a DAP and / or to perform a polling procedure targeting one or more cooperating APs. Specifically, this specification utilizes a BSRP Trigger frame to trigger Co-SR transmission and / or perform a polling procedure. Using the BSRP TF presented in this specification, SAP can trigger Co-SR transmission to the DAP or determine whether to participate in Co-SR transmission from cooperating APs in a polling procedure.

[0254] Specific designations (names) proposed in this specification may be changed and are not limited.

[0255] In addition, the preliminary steps for Multi-AP cooperation are as follows.

[0256] APs with Multi-AP cooperation capabilities can establish Multi-AP cooperation with neighboring APs and perform Multi-AP cooperation-based transmission. Fundamentally, for Multi-AP cooperation-based transmission to occur between two APs, their respective capabilities and requirements must be exchanged in advance (negotiation), and then an agreement must be reached based on the acquired information to enable the execution of Multi-AP cooperation-based technologies (e.g., Co-TDMA, Co-BF, Co-SR, etc.). APs with Multi-AP cooperation capabilities can perform discovery and negotiation / agreement processes to establish Multi-AP cooperation with neighboring APs, thereby forming Multi-AP cooperative relationships or configuring Multi-AP cooperation with them. Subsequently, APs in a Multi-AP cooperative relationship can perform Multi-AP cooperation upon acquiring a TXOP based on the details agreed upon during negotiation. In this specification, an AP that initiates Multi-AP cooperation or triggers Multi-AP cooperation-based transmission is referred to as a Sharing AP (SAP) or Coordinating AP (CAP), and an AP that receives a TXOP from the SAP (or CAP) or triggers Multi-AP cooperation-based transmission is referred to as a shared AP (DAP), Triggered AP (TAP), or Coordinated AP (DAP). Specific designations (names) proposed in this specification may be changed and are not limited.

[0257] To clarify the terminology, the aforementioned cooperative relationship can be referred to as a Multi-AP Coordination (MAPC) relationship or a MAPC agreement. An AP initiating the MAPC (or MAPC negotiation for at least one MAPC technique) can be referred to as a MAPC requesting AP or a coordinating AP. An AP responding to the MAPC requesting AP can be referred to as a MAPC responding AP or a coordinated AP. The coordinating AP is an AP that shares a portion of the TXOP (transmission opportunity) resources by allocating a time portion to the coordinated AP or by allowing simultaneous transmission as part of the MAPC procedure.

[0258] The description of Multi-AP Coordination (MAPC) is as follows.

[0259] MAPC is a framework in which multiple APs cooperate to reduce interference, improve channel utilization efficiency, and enhance reliability and latency; key schemes may include Co-BF (Coordinated Beamforming), Co-SR (Coordinated Spatial Reuse), Co-TDMA (Coordinated TDMA), Co-RTWT (Coordinated Restricted Target Wake Time), and Co-CR (Coordinated Channel Reservation).

[0260] Common procedures for MAPC include the MAPC Discovery procedure and the MAPC Agreement Negotiation procedure. In the MAPC Discovery procedure, an AP can notify other APs of its MAPC capabilities and parameters through the MAPC Discovery Request / Response frame or the management frame. The MAPC Agreement Negotiation procedure may be a process for negotiating, establishing, updating, or terminating an agreement on a specific MAPC scheme among APs. Detailed procedures for the MAPC agreement may include forming the MAPC agreement, assigning an AP ID to identify cooperating APs, updating parameters of the existing MAPC agreement, and terminating the MAPC agreement.

[0261] While the aforementioned discovery and negotiation / agreement processes are procedures that must be performed commonly for various Multi-AP cooperation-based technologies, the procedures required for the individual operations of Multi-AP cooperation-based technologies such as Co-SR, Co-BF, and Co-TDMA may differ. For example, the detailed sequence of procedures required for each Multi-AP scheme may vary, and the information included in the frames transmitted within that sequence may also differ.

[0262] 1. Utilizing BSRP Trigger Frames for Co-BF

[0263] 1) Structure and format of the BSRP Trigger frame for Co-BF

[0264] The structure and format of the BSRP Trigger frame for Co-BF proposed in this section can be defined and designed as presented in the detailed section below.

[0265] Additionally, this specification assumes that SAP transmits a BSRP TF to at least one DAP to trigger a Co-BF transmission or for a polling procedure targeting one or more cooperating APs. In this case, the BSRP TF transmitted for the polling procedure may also be transmitted to a non-AP STA connected to SAP (i.e., the AID12 value for the target non-AP STA may be included in the AID12 field within the User Info field).

[0266] Figure 21 illustrates an example of a BSRP TF-based Co-SR / Co-BF transmission trigger procedure.

[0267] FIG. 21 illustrates an example of a procedure for triggering a Co-SR / Co-BF transmission based on a BSRP TF assumed in this specification. AP 1, acting as the SAP, acquires a TXOP and transmits a BSRP TF acting as an initial control frame (ICF), thereby initiating and triggering the Co-SR / Co-BF transmission. Upon receiving the BSRP TF transmitted from the SAP, the target DAP (AP 2 in FIG. 21) may transmit a response frame (e.g., Management frame, BlockAck frame, etc.) as a confirmation of the start of the Co-SR / Co-BF transmission. Additionally or alternatively, the response frame may be defined and implemented to be unsolicit. For example, in the case of Co-SR / Co-BF, the response frame may be defined to be unsolicit (i.e., not responding with a response frame). Additionally or alternatively, a separate signaling bit / field may indicate no response.

[0268] Additionally or alternatively, the BSRP TF can be used as a trigger frame in a polling (or Multi-AP selection, coordination announcement) procedure that may be performed for the purpose of determining whether one or more cooperating APs will participate in Co-SR / Co-BF transmission. In this case, the BSRP TF can also serve as an ICF. Additionally or alternatively, the BSRP TF in the polling phase and the response frame thereto (e.g., Multi-STA BA) may be performed for the purpose of exchanging preliminary information for Co-SR / Co-BF transmission. FIG. 22 illustrates an example of performing a polling procedure in advance for Co-SR / Co-BF transmission based on the BSRP TF assumed herein.

[0269] FIG. 22 illustrates an example of a Co-SR / Co-BF transmission trigger procedure following a BSRP TF-based polling procedure.

[0270] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the receiving AP's AP ID (ID for Multi-AP cooperation) or the AP's MAC address. Therefore, the Spec may define that an AP receiving a BSRP TF addressed to it transmits a corresponding response frame (e.g., Multi-STA BA frame). In other words, based on definitions regarding the type and format of the ICF and ICR for Multi-AP cooperation operation between APs, each AP can transmit and receive appropriate ICFs and ICRs. For example, a BSRP TF transmitted by an SAP as an ICF is basically sent to a MU, and the receiving STAs (cooperating APs and non-AP STAs) respond by including an appropriate frame in the TB PPDU. At this time, the cooperating AP can respond with a specific frame (e.g., Multi-STA BlockAck) depending on the type and format of the ICR, and the non-AP STA can respond with the existing method (i.e., QoS Data / Null frame including A-Control) or with a specific frame (e.g., Multi-STA BlockAck) defined according to the mode of the non-AP STA (e.g., DPS, NPCA, IDC, Coexistence, etc.).

[0271] Additionally or alternatively, the BSRP TF can be defined and utilized as a new mode or subtype of the BSRP TF based on the existing GI And HE / EHT-LTF Type / TXS Mode field (i.e., B20-B21 within the EHT variant Common Info field). That is, as shown in Table 1, it can be defined for use with the main features of the UHR. When indicating the role of the ICF for the main features of the UHR, a field indicating which feature the corresponding BSRP UHR TF (tentative name) is intended to operate on can be included by utilizing the subsequent Reserved bit. By defining a new subtype of the BSRP TF in this way, the remaining fields, excluding those essential for the operation of each feature, can be defined to contain the information required for each feature (i.e., the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field can be reserved; this may differ from the format of the existing BSRP TF). Exceptions and rules can be additionally defined in this new subtype of the BSRP TF. For example, a BSRP TF with GI And HE / EHT-LTF Type / TXS Mode field = 3 can be classified as a Class 1 frame. Additionally, the remaining fields, excluding those essential for the operation of each feature, can be defined to contain the information required for each feature (i.e., the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field can be reserved, which may differ from the format of the existing BSRP TF).Additionally or alternatively, the reserved range may be utilized to include Common Info for Multi-AP cooperation or Info specific to each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). Additionally or alternatively, a STA receiving the BSRP (UHR) TF may not transmit a response frame under specific conditions / instructions. A separate signaling bit / field may be added for a no response. Additionally or alternatively, a STA receiving the BSRP (UHR) TF may respond with a frame of a different type than a QoS Data / Null frame containing BSR information. Additionally or alternatively, a STA receiving the BSRP (UHR) TF may transmit a non-TB PPDU or non-HT (dup) PPDU instead of a TB PPDU. For example, when the value of the GI And HE / EHT-LTF Type / TXS Mode field of the BSRP TF transmitted by the SAP as an ICF is set to 3, it is transmitted to the SU by default, and the receiving STA (i.e., cooperating AP or non-AP STA) responds by including an appropriate frame in a non-TB PPDU or non-HT (dup) PPDU. Specifically, the cooperating AP may respond by including a specific frame (e.g., Multi-STA BlockAck) in the non-TB PPDU or non-HT (dup) PPDU depending on the type and format of the ICR.

[0272] To trigger Co-SR / BF transmission, a BSRP (UHR) TF based on a new subtype may include common information for Multi-AP cooperation and specific parameters related to each Multi-AP cooperation base technology, and for this purpose, existing fields may be reused or new fields may be defined. The specific designations (names) of the proposed information, fields, and signaling bit(s) may be changed.

[0273] GI And HE / EHT-LF Type / TXS Mode Subfield valueDescription01x HE / EHT-LTF + 1.6us GI12x HE / EHT-LTF + 1.6us GI24x HE / EHT-LTF + 3.2us GI3BSRP serves as the initial control frame for UHR features

[0274] 2) Information and contents for Co-BF transmission

[0275] For example, common information for Multi-AP cooperation and specific information related to Co-BF transmission may be defined as follows. One or more of the information, fields, and signaling bit(s) presented below may be added and defined within the BSRP TF, but are not limited thereto. Additionally, the specific designations (names) of the proposed information, fields, and signaling bit(s) may be changed.

[0276] A. Address: Address information of the DAP that triggers Co-BF transmission (e.g., BSS color, BSSID for Multi-AP, or MAC address)

[0277] B. Multi-AP ID or AP ID: An ID locally assigned to each AP within a configured multi-AP group / set (e.g., 0, 1, 2, ...)

[0278] - For example, the relevant Multi-AP ID or AP ID can be included in the AID12 field within the User Info field of the Trigger frame.

[0279] -> Additionally or alternatively, a Multi-AP ID or AP ID may be included within the AID12 field of the UHR Special User Info field (or Feedback User Info field) that may be newly defined for UHR.

[0280] - For example, the relevant Multi-AP ID or AP ID may be included in the AID11 field within the STA Info field of the UHR NDP Announcement frame.

[0281] C. Operating channel: Information on the operating primary channel and punctured channel

[0282] - For example, channel information that operates commonly to ensure smooth cooperation between APs participating in MAPC

[0283] - For example, primary channel information that APs participating in MAPC can operate in common

[0284] Specifically, a new field that serves as the CCFS0 field within the UHR Operation Information field can be defined to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

[0285] Specifically, a new field that serves as the CCFS0 field within the UHR Operation Information field can be defined to indicate the channel center frequency for the primary 80 MHz channel of the 160 MHz channel or the channel center frequency for the primary 160 MHz channel of the 320 MHz channel.

[0286] In addition, a new field that serves as the CCFS1 field within the UHR Operation Information field can be defined to indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.

[0287] - For example, punctured channel information of APs participating in MAPC

[0288] Specifically, a new field that serves as the Disabled Subchannel Bitmap field within the UHR Operation Information field can be defined to indicate the implemented 20 MHz subchannel using a bitmap.

[0289] Bit value of 0 in the bitmap: Indicates that the corresponding 20 MHz subchannel is not punctured.

[0290] A bit value of 1 in the bitmap indicates that the corresponding 20 MHz subchannel is punctured.

[0291] - The primary channel of DAP can be included within the channel where SAP operates.

[0292] - The primary channel of DAP may be included within the operation channel, excluding the punctured channel of SAP.

[0293] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0294] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0295] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0296] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0297] D. Operating bandwidth: Information on operating bandwidth and maximum bandwidth

[0298] - For example, BW information that operates commonly for smooth cooperation among APs participating in MAPC

[0299] Specifically, the Operating channel and primary channel information described above can be utilized.

[0300] - For example, maximum bandwidth information of APs participating in MAPC

[0301] Specifically, a new field that performs the same role as the Channel Width field within the Control field of the UHR Operation Information field can be defined to indicate the channel width, which is the BSS BW information of each AP.

[0302] Set to 0: 20 MHz bandwidth indication

[0303] Set to 1: 40 MHz bandwidth indication

[0304] Set to 2: 80 MHz bandwidth indication

[0305] Set to 3: 160 / 80+80 MHz bandwidth indication

[0306] Set to 4: 320 / 160+160 MHz bandwidth indication

[0307] The remaining values ​​from 5 to 7 can be set to reserved.

[0308] - For example, BW field information within the SIG-A field

[0309] - For example, UL BW field information included within the Common Info field of the Trigger frame

[0310] - The bandwidth of the DAP may be included within the total bandwidth in which the SAP operates.

[0311] - For example, a new field for bandwidth indication can be added by modifying / redefining the Medium Time field of the QoS Characteristics element to include a new sub-field.

[0312] Specifically, a new field that performs the same role as the Channel Width field within the Control field of the UHR Operation Information field can be defined to indicate the channel width, which is the BSS BW information of each AP.

[0313] Set to 0: 20 MHz bandwidth indication

[0314] Set to 1: 40 MHz bandwidth indication

[0315] Set to 2: 80 MHz bandwidth indication

[0316] Set to 3: 160 / 80+80 MHz bandwidth indication

[0317] Set to 4: 320 / 160+160 MHz bandwidth indication

[0318] The remaining values ​​from 5 to 7 can be set to reserved.

[0319] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0320] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0321] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0322] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0323] E. UHR Feature Type or Control Info Type (Feedback Type): Indicates the feature type of the BSRP (UHR) TF.

[0324] - That is, it indicates the purpose (e.g., Co-BF or MAPC) for which the BSRP (UHR) TF was transmitted.

[0325] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0326] - For example, utilizing EHT Reserved or Reserved in the Common Info field

[0327] Specifically, it can indicate the type for which a BSRP TF, which can be utilized as an ICF in Dynamic Power Saving (DPS), Inter-Device Coexistence (IDC), Non-primary Channel Access (NPCA), Multi-AP Coordination (MAPC), etc., was transmitted. An example of signaling is as follows.

[0328] 0: Indicates that it is a TF for Multi-AP coordination operations

[0329] 1: Indicates that this is a TF for DPS operations

[0330] 2: Designate it as a TF for IDC operations

[0331] 3: Designate it as a TF for NPCA operations

[0332] other bits: reserved

[0333] Specifically, it can indicate the type for which the BSRP TF was transmitted within a specific feature (e.g., MAPC). An example of signaling is as follows.

[0334] 0: Indicates that it has been transmitted to the ICF in the MAPC.

[0335] 1: Indicates that it was transmitted as a Co-Triggering frame in MAPC

[0336] 2: Indicates that it was transmitted to the CRF in the MAPC

[0337] 3: TBD

[0338] ...

[0339] -> Additionally or alternatively, specific types of particular UHR features and / or MAPC schemes can be indicated. An example of signaling is as follows.

[0340] 0: Co-existence

[0341] 1: Co-BF

[0342] 2: Co-SR

[0343] 3: Co-TDMA

[0344] 4: TBD

[0345] ...

[0346] -> Additionally or alternatively, control information regarding the type of a specific UHR feature and / or MAPC scheme and the role for which the corresponding TF was transmitted can be indicated together. An example of signaling is as follows.

[0347] 0: Co-existence

[0348] 1: Reserved

[0349] 2: Reserved

[0350] 3: ICF in Co-TDMA

[0351] 4: Sounding Invite frame in the sounding section at Co-BF

[0352] 5: Co-BF Invite frame in the transmission interval of Co-BF

[0353] 6: Synchronization (i.e., Co-Triggering) frame in Co-BF

[0354] 7: Co-SR Invite frame in the transmission interval of Co-SR

[0355] 8: Synchronization (i.e., Co-Triggering) frame in Co-SR

[0356] ...

[0357] Additionally or alternatively, control and info type information regarding the type of a specific UHR feature and / or MAPC scheme, the role for which the corresponding TF was transmitted, and specifically what type of information it contains can be indicated together. An example of signaling is as follows.

[0358] 0: Co-existence

[0359] 1: Reserved

[0360] 2: Reserved

[0361] 3: ICF in Co-TDMA

[0362] 4: Includes Common information in Co-BF sounding (i.e., Sounding Invite Common Info)

[0363] 5: Includes Per-User information in Co-BF sounding (i.e., Sounding Invite Per-User Info)

[0364] 6: Includes Common information for Invite in Co-BF (i.e., Invite Common Info)

[0365] 7: Includes Per-User information for Invite in Co-BF (i.e., Invite Per-User Info)

[0366] 8: Includes common information for synchronization in Co-BF (i.e., Sync Common Info)

[0367] 9: Includes Per-User information for synchronization in Co-BF (i.e., Sync Per-User Info)

[0368] 10: Includes information for Invite in Co-SR (i.e., Co-SR Invite Info)

[0369] 11: Includes information for synchronization in Co-SR (i.e., Co-SR Sync / Co-TF Info)

[0370] ...

[0371] - Additionally or alternatively, by utilizing Reserved, a UHR Feature field can be assumed for the purpose of soliciting response information for one or more operational purposes, such as DPS, IDC, NPCA, MAPC, etc., without specifying a single specific UHR Feature Type.

[0372] For example, each bit of the 4 bits can indicate a specific feature (e.g., DPS, IDC, NPCA, MAPC, etc.).

[0373] An example of soliciting feature type indications and response information using a combination of each bit (bitmap) is as follows.

[0374] If B56: MAPC, B57: DPS, B58: IDC, B59: NPCA, other bits: reserved, 1100 can solicit instructions and response information for MAPC and DPS operations.

[0375] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0376] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0377] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0378] F. Feedback Information: A field containing Control Information specific to UHR features or MAPC schemes transmitted to the receiving STA via an ICF or CRF (i.e., BSRP TF), such as a Sounding / Co-BF Invite or Sync frame, or a field containing information related to or helpful in providing feedback Information specific to UHR features or MAPC schemes that the transmitting device wishes to receive from the receiving device.

[0379] - For example, Control / Feedback Info corresponding to the feature specified in the Control Info / Feedback Type (e.g., MAPC Info or Co-BF / SR / TDMA Info, etc.)

[0380] For example, feature-specific information that must be transmitted to the receiving STA to operate as IDC, MAPC (or Co-BF / SR / TDMA), DPS, or NPCA

[0381] Specifically, common information regarding the feature

[0382] Specifically, user-specific information regarding the feature

[0383] For example, feature-specific information that must be transmitted to the receiving AP to operate as IDC, MAPC (or Co-BF / SR / TDMA), DPS, or NPCA

[0384] Specifically, common information regarding the feature

[0385] Specifically, user-specific information regarding the feature

[0386] G. Common Control / Feedback Info: Common Control / Feedback Info may contain common information for each feature (i.e., IDC, MAPC, DPS, NPCA, or Co-BF / SR / TDMA).

[0387] H. Per-User Control / Feedback Info: Per-User Control / Feedback Info may include user-specific information (i.e., non-AP STA or AP) for each feature (i.e., IDC, MAPC, DPS, NPCA, or Co-BF / SR / TDMA).

[0388] - Additionally or alternatively, the ICF or CRF may include information that can be included in the existing A-Control field (e.g., BSR) in addition to information related to IDC Info, MAPC (Co-BF / SR / TDMA) Info, DPS Info, NPCA Info, etc. as presented in this specification.

[0389] I. Response Type: Indicates the type of response frame for the transmitted TF or the type of information solicited from the receiving device.

[0390] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0391] - For example, utilizing EHT Reserved or Reserved in the Common Info field

[0392] Specifically, the type of TF that can be utilized as an ICF in DPS, IDC, NPCA, MAPC, etc., can indicate for what purpose it was transmitted and which response frame it solicits, and an example of signaling is as follows.

[0393] 0: No response (unsolicit)

[0394] 1: Instruct the receiving device to respond with a QoS Null / Data frame (including an A-Control field).

[0395] 2: Instruct the receiving device to respond with a BlockAck frame (e.g., Multi-STA BA).

[0396] 3: Instruct the receiving device to respond with an Action frame (including the A-Control field).

[0397] 4: Reserved

[0398] Depending on the solicit type and method, more bits can be used, and bitmaps can be utilized.

[0399] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0400] - Additionally or alternatively, one or more User Info field(s) with the same AID may exist, and additional User Info fields may include bits or fields to indicate the Response type.

[0401] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field that can be newly defined for UHR.

[0402] - Additionally or alternatively, a Response Type field may be assumed for the purpose of soliciting response Info for one or more operational purposes, such as DPS, IDC, NPCA, MAPC, etc., by utilizing Reserved and integrating with the above-mentioned UHR Feature Type field.

[0403] For example, each bit of the 4 bits can indicate a specific feature (e.g., DPS, IDC, NPCA, MAPC, etc.).

[0404] An example of soliciting feature type indications and response information using a combination of each bit (bitmap) is as follows.

[0405] If B56: MAPC, B57: DPS, B58: IDC, B59: NPCA, other bits: reserved, 1100 can solicit instructions and response information for MAPC and DPS operations.

[0406] J. General Response: Allows a General response as a response frame for the transmitted TF.

[0407] - For example, allow the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, or QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields) in response to Basic TF.

[0408] - For example, allow the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, or QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields) in response to a BSRP TF.

[0409] - For example, allows the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields), CTS frames, etc., in response to a MU-RTS (TXS) TF.

[0410] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0411] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field that can be newly defined for UHR.

[0412] K. Multi-AP Coordination (MAPC) Type: Instructions for Multi-AP cooperative transmission techniques such as Co-TDMA, Co-SR, and Co-BF

[0413] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0414] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0415] Specifically, defining a new field to indicate the Multi-AP Coordination Type by utilizing one or more bits corresponding to EHT Reserved (i.e., utilizing 1 to n bits depending on the number of Multi-AP cooperative transmission techniques that can be reflected in the new definition and standard).

[0416] Specifically, defining a new field to indicate the Multi-AP Coordination Type by utilizing one or more bits corresponding to Reserved fields / bits (i.e., utilizing 1 to n bits depending on the number of Multi-AP cooperative transmission techniques that can be reflected in the new definition and standard)

[0417] For example, signaling can be done as follows

[0418] bit 0: None

[0419] bit 1: Co-TDMA

[0420] bit 2: Co-SR

[0421] bit 3: Co-BF

[0422] ...

[0423] For example, signaling can be done as follows

[0424] 0: Co-TDMA

[0425] 1: Co-SR

[0426] 2: Co-BF

[0427] ...

[0428] - Additionally or alternatively, control information regarding the MAPC Type and the role for which the corresponding TF was transmitted can be signaled together.

[0429] For example, signaling can be done as follows based on each bit value

[0430] 0: The role of ICF in Co-TDMA

[0431] 1: The role of TXOP return in Co-TDMA

[0432] 2: ICF (or Invite) role for the transmission section in Co-SR

[0433] 3: The Role of Synchronization / Co-Triggering Frames in Co-SR

[0434] 4: ICF (or Invite) role for the transmission section in Co-BF

[0435] 5: Role of Synchronization / Co-Triggering Frames in Co-BF

[0436] 6: The role of ICF (or Invite) for the sounding section in Co-BF

[0437] 7: Role of a trigger frame for sounding failure recovery in Co-BF

[0438] ...

[0439] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0440] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0441] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0442] L. Coordination Triggering: Indicates that it is a BSRP (UHR) TF transmitted to trigger Multi-AP cooperative-based transmission (e.g., Co-BF).

[0443] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0444] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0445] Specifically, defining a new field to indicate a BSRP (UHR) TF for Coordination Triggering by utilizing one or more bits corresponding to EHT Reserved.

[0446] Specifically, defining a new field to indicate a BSRP (UHR) TF for Coordination Triggering by utilizing one or more bits corresponding to Reserved fields / bits.

[0447] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field that can be newly defined for UHR.

[0448] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0449] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0450] M. BSRP Type (or CoBF Subtype): Separately indicates control information regarding the role for which the corresponding BSRP TF was transmitted.

[0451] - That is, among the embodiments for the MAPC Type field and / or Coordination Triggering described above, control information regarding what role the corresponding TF was transmitted for can be indicated through a separate BSRP Type field.

[0452] For example, signaling can be done as follows based on each bit value

[0453] 0: Role of ICF or Invite Frame in the sounding phase

[0454] 1: Role of ICF or Invite Frame in Transmission Phase

[0455] 2: Role of Synchronization or Co-Triggering Frame in Transmission Phase

[0456] 3: Role of a trigger frame for the purpose of sounding failure recovery

[0457] 4: Role of the Intermediate Control frame during the sounding or transmission phase (e.g., the role of the TXOP return frame in Co-TDMA)

[0458] ...

[0459] -> Additionally or alternatively, signaling can be done with 1 bit as follows

[0460] 0: Role of ICF or Invite Frame in the sounding phase

[0461] 1: Role of ICF or Invite Frame in Transmission Phase

[0462] -> Additionally or alternatively, signaling can be done with 2 bits as follows

[0463] 0: Role of ICF or Invite Frame in the sounding phase

[0464] 1: Role of ICF or Invite Frame in Transmission Phase

[0465] 2: Role of the Sync (Co-Triggering) Frame in the Transmission Phase

[0466] 3: reserved

[0467] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0468] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0469] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0470] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0471] N. Co-BF Info Type: Indicates what specific information the frame includes in the Feedback Information field regarding a particular scheme.

[0472] - In other words, a separate Co-BF Info Type field can be used to indicate whether Common or Per-User information for Co-BF operation is included.

[0473] For example, signaling can be done with 1 bit as follows

[0474] 0: Includes Co-BF Common Info

[0475] 1: Includes Co-BF Per-User Info (i.e., Per-STA Info)

[0476] -> Additionally or alternatively, signaling can be done with 2 or more bits as follows

[0477] 0: Contains Common Info for CoBF operation and indicates the first Common Info.

[0478] 1: Includes Common Info for CoBF operation and points to the second Common Info.

[0479] 2: Includes Common Info for CoBF operation and specifies a third Common Info (additionally or alternatively, if all Common Info can be conveyed via two Common Info fields, specifies including Per-User Info (i.e., STA information) in the Feedback Information field).

[0480] 3: Includes Per-User Info (i.e., STA information) for CoBF operation (may be reserved if the value 2 indicates including Per-User Info in the Feedback Information field.)

[0481] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0482] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0483] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0484] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0485] O. (Scheduled) Coordination Duration or Whole TXOP Duration: The period during which SAP collaborates with DAPs to perform Co-BF-based transfers, or the total coordination TXOP (Whole TXOP) period scheduled for MAPC operations.

[0486] - For example, specify the expected / scheduled coordination duration anticipated by SAP

[0487] - For example, the total cooperation TXOP period during which SAP intends to perform MAPC operations

[0488] - For example, define a new field including Coordination Duration or Whole TXOP Duration to indicate

[0489] Specifically, define a new field tentatively named Coordination or Whole TXOP Duration to indicate the information necessary for MAPC operation and the Coordination or Whole TXOP Duration values.

[0490] - For example, utilizing the Allocation Duration field of the User Info field in the MU-RTS TXS Trigger frame

[0491] Specifically, instruct by including the corresponding period value in the Allocation Duration field.

[0492] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0493] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0494] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0495] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0496] P. Traffic Priority: Priority information of traffic recommended by SAP to DAP, priority information of traffic allowed by SAP to DAP, or priority information of traffic / AC allowed by SAP to DAP

[0497] - For example, TID / AC information regarding traffic allowed to the DAP within the TXOP obtained by SAP

[0498] - For example, Primary AC information for TXOPs obtained by SAP (obtained TXOP)

[0499] Specifically, if traffic for only one of AC_BK, AC_BE, AC_VI, or AC_VO is allowed, the DAP may transmit only traffic corresponding to that AC within the allocated period or cooperation period.

[0500] Specifically, a 2-bit ACI field can be defined to indicate as follows (ACI-to-AC coding)

[0501] AC index (ACI) 0 = AC_BE (best effort)

[0502] AC index (ACI) 1 = AC_BK (background)

[0503] AC index (ACI) 2 = AC_VI (video)

[0504] AC index (ACI) 3 = AC_VO (voice)

[0505] - Additionally or alternatively, SAP may designate a Primary AC for the acquired TXOP, and based on said Primary AC, the CAP (coordinated AP) may transmit traffic corresponding to an AC equal to or greater than said AC within the allocated period or cooperation period.

[0506] Specifically, a new 2-bit field can be defined to indicate as follows (ACI-to-AC coding)

[0507] AC index (ACI) 0 = AC_BE (best effort)

[0508] AC index (ACI) 1 = AC_BK (background)

[0509] AC index (ACI) 2 = AC_VI (video)

[0510] AC index (ACI) 3 = AC_VO (voice)

[0511] - Additionally or alternatively, seven User Priorities (UPs) may be provided as Traffic Categories, and a CAP may transmit only traffic corresponding to an AC that is less than or equal to the UP within the allocated period or cooperation period.

[0512] Specifically, a new 4-bit field can be defined to indicate as follows (UP-to-AC mapping)

[0513] User Priority (UP) 1 = AC_BK

[0514] UP 2 = AC_BK

[0515] UP 0 = AC_BE

[0516] UP 3 = AC_BE

[0517] UP 4 = AC_VI

[0518] UP 5 = AC_VI

[0519] UP 6 = AC_VO

[0520] UP 7 = AC_VO

[0521] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0522] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0523] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0524] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0525] Q. Protection Level: Indicates the protection level for the efficient operation of the currently operating cooperative transmission.

[0526] - For example, in Co-SR / BF operation, this may mean that protection is required until Co-Triggering is performed.

[0527] - For example, utilizing the EHT Reserved (7 bits) or Reserved of the Common Info field

[0528] Specifically, it uses the 2 bits corresponding to EHT / UHR Reserved or Reserved to indicate the protection level of the currently operating cooperative transmission.

[0529] 0: Indicates that it is a cooperative transmission with a protection level of 0 (for example, in Co-TDMA / SR / BF operation, this may mean that separate protection (i.e., long NAV setting) is not required for the transmission / reception of ICF, ICR, and Co-Triggering frames).

[0530] 1: Indicates that it is a cooperative transmission with a protection level of 1 (for example, in Co-TDMA / SR / BF operation, this may mean that separate protection (i.e., NAV setting) is required from the ICF / ICR exchange until the transmission of the Co-Triggering frame).

[0531] 2: Indicates that it is a cooperative transmission with a protection level of 2 (for example, this may mean that separate protection (i.e., long NAV setting) is required when transmitting a Co-Triggering frame to ensure a successful TXOP return in Co-TDMA operation).

[0532] 3: Indicates that it is a cooperative transmission with a protection level of 3 (for example, in Co-TDMA / SR / BF operation, this may mean that all procedures from the transmission and reception of ICF, ICR, and Co-Triggering frames are protected (i.e., long NAV setting)).

[0533] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0534] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0535] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0536] R. Multi-AP Ack Policy Indicator: Indicates the Ack policy during the Co-BF transmission period or the Ack policy that the DAP and the STA connected to the DAP must follow during the coordination duration.

[0537] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0538] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0539] Specifically, it utilizes the 2 bits corresponding to EHT Reserved or Reserved to specify the Ack policy for frame exchanges between cooperating APs during the Co-BF Duration.

[0540] For example, it can be defined similarly to the Ack Policy Indicator field within the QoS Control field.

[0541] Bit 0 = 0 & Bit 1 = 0: Indicates a normal ACK or an implicit BAR.

[0542] Bit 0 = 1 & Bit 1 = 0: Indicates No Ack

[0543] Bit 0 = 0 & Bit 1 = 1: Reserved or indicates HETP Ack

[0544] Bit 0 = 1 & Bit 1 = 1: Indicates Block Ack

[0545] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0546] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0547] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0548] S. In-BSS STA Info: Indicates information about the Target STA on which SAP will perform DL / UL transfer, or information about all connected STAs.

[0549] - For example, the identifiers and capabilities of all STAs connected to SAP

[0550] For example, the AID or MAC addresses of the STAs

[0551] For example, STAs' MIMO and RF capabilities

[0552] - For example, the identifier and capability of the target STA among the STAs connected to SAP that intends to perform DL / UL transmission based on Co-BF

[0553] For example, the AID or MAC address of the Target STA

[0554] For example, the MIMO and RF capabilities of the Target STA

[0555] For example, the PHY version of the Target STA

[0556] - For example, an identifier for an In-BSS STA that you want to include in the Multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation

[0557] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0558] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0559] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0560] T. OBSS STA Info: Indicates information about the OBSS Target STA on which the DAP must perform DL / UL transmission.

[0561] - For example, the identifier and capability of the target OBSS STA among the OBSS STAs connected to the DAP that intends to perform DL / UL transmission based on Co-BF

[0562] For example, the AID or MAC address of the Target OBSS STA

[0563] For example, the MIMO and RF capabilities of the Target OBSS STA

[0564] For example, the PHY version of the Target STA

[0565] - For example, an identifier for an OBSS STA that you want to include in the Multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation

[0566] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0567] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0568] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0569] U. Common L-SIG Info: The Common L-SIG Info field contains L-SIG information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperation transmission period.

[0570] For example, the Length (B5-B16) information of the L-SIG field within a MU PPDU (e.g., EHT, UHR, etc.) may correspond to the Common L-SIG Info field. This can be considered as a value indicating the duration of the DL PPDU transmitted by each AP.

[0571] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0572] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0573] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0574] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0575] V. Common U-SIG Info: One or more of the information presented below may be added to and defined within the Common U-SIG Info field, but is not limited to. The Common U-SIG Info field indicates and includes U-SIG-1 and U-SIG-2 information that must be commonly included in the DL PPDU transmitted by each AP during the relevant cooperation-based transmission period.

[0576] - For example, PHY Version Identifier (B0-B2) information in the U-SIG-1 field within MU PPDU (e.g., EHT, UHR, etc.)

[0577] Specifically, it indicates the PHY version of the DL PPDU transmitted by each AP during the Co-BF transmission period.

[0578] -> Additionally or alternatively, SAP specifies the PHY version of the target STA to which it intends to send the DL PPDU during the Co-BF transmission time.

[0579] - For example, Bandwidth (B3-B5) information of the U-SIG-1 field within MU PPDU (e.g., EHT, UHR, etc.)

[0580] Specifically, it indicates the bandwidth of the DL PPDU transmitted by each AP during the Co-BF transmission period.

[0581] -> Additionally or alternatively, it may be a bandwidth based on the bandwidth of the PPDU containing the ICF or Co-Triggering frame transmitted by the SAP.

[0582] -> Additionally or alternatively, when a response frame (e.g., M-BA, CTS frame) exists for an ICF or Co-Triggering frame transmitted by the SAP, the bandwidth may be based on the bandwidth of the PPDU containing said response frame.

[0583] - For example, UL / DL (B6) information in the U-SIG-1 field within the MU PPDU (e.g., EHT, UHR, etc.)

[0584] Specifically, it indicates whether DL transmission or UL transmission is scheduled to be performed during the relevant Co-BF transmission period.

[0585] - For example, Punctured Channel Information (B3-B7) of the U-SIG-2 field within MU PPDU (e.g., EHT, UHR, etc.)

[0586] -> Additionally or alternatively, PPDUs containing ICFs or Co-Triggering frames transmitted by the SAP may be punctured based on long-term punctured channel info (e.g., all punctured 20 MHz subchannels specified in the TXVECTOR parameter INACTIVE_SUBCHANNELS).

[0587] -> Additionally or alternatively, it can be punctured based on the dynamic puncturing information of each AP

[0588] Additionally or alternatively, it may be a puncturing pattern composed of the union of the two APs' punctured 20 MHz.

[0589] - For example, a UHR-SIG MCS can be defined that performs the same role as the EHT-SIG MCS (B9-B10) of the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.).

[0590] Specifically, the value of UHR-SIG MCS can indicate the following MCS:

[0591] UHR-SIG MCS = 0 indicates UHR-MCS 0.

[0592] UHR-SIG MCS = 1 indicates UHR-MCS 1.

[0593] UHR-SIG MCS = 2 indicates UHR-MCS 3.

[0594] UHR-SIG MCS = 3 indicates UHR-MCS 15.

[0595] -> Additionally or alternatively, it can be set to an MCS value that all STAs serviced by each AP can receive.

[0596] - For example, Number of UHR-SIG Symbols can be defined to serve the same role as Number of EHT-SIG Symbols (B11-B15) in the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.).

[0597] -> Additionally or alternatively, it can be set to an OFDM symbol value configured by considering all user fields for all STAs connected to each AP.

[0598] - For example, a UHR-SIG TXOP can be defined that performs the same role as the TXOP (B13-B19) of the U-SIG field within a MU PPDU (e.g., EHT, UHR, etc.).

[0599] - For example, Spatial Configuration (B16-B19) information within the User field

[0600] Specifically, it specifies the number of spatial streams for each user in MU-MIMO allocation.

[0601] -> Additionally or alternatively, spatial stream allocation information for all STAs connected to each AP can be specified.

[0602] Additionally or alternatively, the Spatial Configuration field can be defined and utilized as 2 or 3 bits.

[0603] - One or more of the information described above may be included in the Common U-SIG Info field, but is not limited to.

[0604] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI and HE / EHT-LTF Type / TXS Mode field

[0605] Additionally, or as an alternative, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0606] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0607] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0608] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0609] W. Non-OFDMA Common Info: Non-OFDMA information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperative-based transmission period.

[0610] - For example, Spatial Reuse (4 bits) information within the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[0611] - For example, GI+LTF Size (B4-B5) information in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[0612] Specifically, it can be set to a GI+LTF value that enables all STAs serviced by each AP to reliably estimate the channel.

[0613] - For example, Number of UHR-LTF Symbols can be defined to serve the same role as Number of EHT-LTF Symbols (B6-B8) in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission.

[0614] Specifically, it can be set as the dimension of the Giant P matrix determined based on the sum of the spatial streams required for each AP.

[0615] -> Additionally or alternatively, it can be set to the larger of the LTF symbol values ​​required for each AP.

[0616] - For example, Number of Non-OFDMA Users (B17-B19) information in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[0617] Specifically, the value of the Number Of Non-OFDMA Users field can represent the sum of the number of Co-BF target users on the SAP side and the number of Co-BF target users on the DAP side.

[0618] Alternatively, the Number Of Non-OFDMA Users field can be defined as 2 bits, with each bit used to indicate the number of Co-BF target users for SAP and DAP.

[0619] For example, B17 indicates the number of SAP users (e.g., 0 is single user, 1 is 2 users)

[0620] For example, B18 indicates the number of DAP users (e.g., 0 is single user, 1 is 2 users)

[0621] - One or more of the information described above may be included in the Non-OFDMA Common Info field, but is not limited to.

[0622] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI and HE / EHT-LTF Type / TXS Mode field

[0623] Additionally, or as an alternative, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0624] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0625] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0626] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0627] X. MU-MIMO User Info: MU-MIMO user field information or user field format information for MU-MIMO allocation that must be included in the DL PPDU transmitted by each AP during the relevant cooperative-based transmission period.

[0628] - For example, STA-ID field (B0-B10) information within the User field

[0629] Specifically, ID information of the STA receiving the DL PPDU transmitted based on Co-BF

[0630] - For example, MCS (B11-B15) information within the User field

[0631] - For example, Spatial Configuration (B16-B19) information within the User field

[0632] Specifically, it specifies the number of spatial streams for each user in MU-MIMO allocation.

[0633] Additionally, or as an alternative, the Spatial Configuration field can be defined and utilized as 3 bits.

[0634] - For example, BSS Color Indication (B21) information can be newly defined.

[0635] Specifically, it is used to indicate which of the two BSSs participating in Co-BF the MU-MIMO User Info field refers to a user existing in.

[0636] - For example, 2xLDPC (B22) information

[0637] - One or more of the information described above may be included in the MU-MIMO User Info field, but is not limited to.

[0638] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI and HE / EHT-LTF Type / TXS Mode field

[0639] Additionally, or as an alternative, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0640] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0641] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0642] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0643] In addition to the contents presented above, some fields included in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission for existing multiple users (e.g., LDPC Extra Symbol Segment, Pre-FEC Padding Factor, PE Disambiguity, Spatial Reuse, etc.) may be included in Common Info or Special User Info or User Info within the BSRP (UHR) Trigger frame proposed in this specification as contents for Co-BF transmission, or (UHR) Special User Info that can be newly defined for UHR.

[0644] a. ICF / ICR Required: Indicates whether an additional sequence is required to transmit the ICF to the associated STA before triggering the Co-BF transmission.

[0645] - For example, it indicates that an ICF / ICR exchange procedure is required to switch an EMLSR (Enhanced Multi-Link Single-Radio) STA among the associated STAs from listening mode to frame exchange mode.

[0646] - For example, it indicates that an ICF / ICR exchange procedure is required to switch a DPS STA among the associated STAs from low capability mode to high capability mode.

[0647] - For example, it indicates that an ICF / ICR exchange procedure is required to switch a DUO STA among the associated STAs.

[0648] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0649] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0650] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0651] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0652] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0653] b. Minimum Number of Data OFDM Symbols (9 bits): Indicates the minimum number of data OFDM symbols that the SAP can transmit.

[0654] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0655] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0656] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0657] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0658] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0659] c. Maximum Number of Data OFDM Symbols (9 bits): Indicates the maximum number of data OFDM symbols that the SAP can transmit.

[0660] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0661] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0662] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0663] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0664] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0665] d. Maximum Total Nss Allowed for shared AP (2 bits): Indicates the maximum number of Total Nss allowed to the DAP for the purpose of the SAP controlling the DAP's Nss value.

[0666] - For example, if the Maximum Total Nss is 4 and SAP is using 1, and you do not want DAP to use 3, set it to 2 or 1 to limit DAP's Nss.

[0667] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0668] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0669] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0670] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0671] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0672] e. Number of CoBF Users in sharing BSS (2 bits): Indicates the number of users to be transmitted in the sharing BSS (1~3).

[0673] f. BSS Color 1 and BSS Color 2 (6 bits each): Indicates the BSS color of SAP and the BSS color of DAP.

[0674] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0675] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0676] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0677] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0678] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0679] g. Number of CoBF Users (3 bits): Indicates the sum of the number of Co-BF users in SAP and DAP

[0680] - Currently, the maximum number of users is defined as 4.

[0681] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[0682] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[0683] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0684] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0685] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0686] h. Sounding Session ID: Indicates the ID for each sounding session. That is, between two APs, there may be one or more sounding sessions, sounding session IDs to identify them, and sounding information. Within the corresponding TXOP, it may indicate which sounding session is to be used as the basis for Co-BF transmission.

[0687] - For example, it can be defined based on 6 bits, like NDPA's Sounding Dialog Token.

[0688] - Additionally or alternatively, it can be defined with a size smaller than 6 bits.

[0689] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0690] - Additionally or alternatively, the information may be included in a Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0691] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0692] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[0693] The AID12 field within the User Info field of the BSRP (UHR) TF proposed in this specification may be replaced with an ID related to Multi-AP cooperation. Specifically, the ID related to Multi-AP cooperation may include, for example, the BSSID, BSS color, or a newly defined Multi-AP group ID (i.e., an ID for a set of APs constituting Multi-AP cooperation) or an AP ID (i.e., an ID assigned by an AP in a cooperative relationship within the constituent Multi-AP group). Additionally or alternatively, the AID12 field may be composed of a combination of the BSSID and BSS color of the target DAP. Additionally or alternatively, the AID12 field may be composed of part or all of the BSS color of the target DAP. Additionally or alternatively, the AID12 field may be composed of part of the BSSID of the target DAP. Additionally or alternatively, the AID12 field may be composed of a combination of the AP ID and BSS color of the target DAP. Alternatively, when targeting a single DAP, the MAC address of the target DAP may be included in the RA field.

[0694] 3) Example of BSRP (UHR) TF format in a polling procedure

[0695] 3-1) Based on existing GI and HE / EHT / UHR-LTF Type / TXS Mode values

[0696] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the AP ID of the receiving AP (i.e., ID for Multi-AP cooperation) or the MAC address of the AP. Therefore, an AP that receives a BSRP TF addressed to it can recognize that the corresponding BSRP TF has been delivered, acting as an ICF in MAPC operation. It is assumed that the BSRP TF can be transmitted for various purposes (e.g., DPS, NPCA, IDC, Coexistence, MAPC). Accordingly, a (UHR) Special User Info field can be defined and utilized to include an indicator of the purpose for which an ICF transmitted for one or more UHR features was sent, and to convey information necessary for Co-BF transmission to cooperating APs.

[0697] To do this, a new UHR Special User Info Field Flag (or UHR Function Control Indication) field can be defined using 1 bit of the Reserved bits of the Common Info field and its value can be set to 1. Additionally, or alternatively, a new UHR Special User Info Field Flag (or Present) field can be defined using 1 bit of the Reserved bits of Special User Info (i.e., AID12 = 2007) and its value can be set to 1.

[0698] Additionally or alternatively, the Reserved (1 bit) within the User Info field can be used to indicate whether there exists a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation (i.e., the UHR Special User Info Field Flag can be defined using the Reserved within the User Info field). This is a field defined and included for the purpose of indicating the presence of a UHR Special User Info field containing additional information. Additionally or alternatively, a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation may be placed before the existing User Info field to include MAPC-related user-specific information and may include a Presence bit indicating that there is an additional User Info field (or UHR Special User Info field) addressed to the corresponding AP.

[0699] To indicate that the corresponding UHR Special User Info field is a new Special User Info field in the UHR, the value of the AID12 field may be Reserved (e.g., one of 2008–2044 or one of 2047–4094). The UHR Special User Info field identified by the new AID12 value may be placed following the Common Info field, the User Info field, or the Special User Info field (i.e., AID12 = 2007) (of the EHT). Additionally, or alternatively, the UHR Special User Info field may be placed before or after the User Info field for the corresponding User.

[0700] Additionally or alternatively, the AID12 field may include a Multi-AP group ID (i.e., an ID for the set of APs that have formed a Multi-AP collaboration) or an AP ID (i.e., an ID assigned by an AP in a collaborative relationship within the formed Multi-AP group). Specifically, the local AP ID value assigned by SAP may be mapped / converted / interpreted as an AID12 value. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's BSSID and BSS color. Additionally or alternatively, the AID12 field may consist of part or all of the target DAP's BSS color. Additionally or alternatively, the AID12 field may consist of part of the target DAP's BSSID. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's AP ID and BSS color.

[0701] Figure 23 illustrates Example-1 of a BSRP TF format based on existing GI values.

[0702] Figure 24 illustrates Example-2 of a BSRP TF format based on existing GI values.

[0703] FIGS. 23 and 24 illustrate examples of BSRP TF that reuse the existing BSRP TF format and include information related to Co-BF transmission that is not included in the Common Info and User Info fields. For example, common information for UHR features and common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-BF transmission' above may be included in one or more (UHR) Special User Info fields (e.g., AID12 = 2008). The location where each piece of information may be included and the type of information are not limited. Additionally, if the presented information is not used, the corresponding field may be reserved.

[0704] Additionally or alternatively, one or more of the (UHR) Special User Info fields presented in FIG. 24 (e.g., Default, Common U-SIG Info, Non-OFDMA Common Info, MU-MIMO User Info-(n)) may be included in the Common Info, User Info, or Special User Info fields within the frame for triggering Co-BF. For example, the BSRP TF in the Polling procedure may include the Default and / or Common U-SIG Info and / or Non-OFDMA Common Info fields, and the MU-MIMO User Info-(n) field(s) may be included in the TF in the Triggering procedure. Alternatively, all of the Common U-SIG Info, Non-OFDMA Common Info, and MU-MIMO User Info-(n) may be included in the TF in the Triggering procedure, and the Polling procedure may be utilized to verify participation from each AP and / or to indicate the purpose of the ICF and the type of MAPC. The locations where each field can be included are not limited.

[0705] Figure 25 illustrates Example-3 of a BSRP TF format based on existing GI values.

[0706] Additionally or alternatively, the information presented above may be divided into common and user-specific (i.e., AP specific) information and included in one or more new (UHR) Special User Info fields. For example, as shown in FIG. 25, information common to UHR features and MAPCs and / or information common to all STAs in Co-BF operations may be included in a Special User Info field (e.g., AID12 = 2008), and information specific to each STA may be separated and included in separate new Special User Info fields. In this case, a Special User Info field Present field / bit may be included within the preceding Special User Info field (e.g., AID12 = 2008) to indicate the existence of a subsequent Special User Info field. For example, if a Per-User Special User Info field follows, the Special User Info field Present field within the Common Special User Info field may be set to 1.

[0707] 3-2) Based on new GI and HE / EHT / UHR-LTF Type / TXS Mode values ​​(i.e., 3)

[0708] Figure 26 illustrates Example-1 of the BSRP (UHR) TF format based on the new GI = 3 value.

[0709] FIG. 26 shows an example of a BSRP (UHR) TF format when the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field are reserved through the indication of a new subtype or mode using the GI And HE / EHT / UHR-LTF Type / TXS Mode field (i.e., 3) of the Common Info field, or when the reserved range is utilized to include Common Info for Multi-AP cooperation or Info for each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). One or more pieces of information described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, User Info field, Special User Info field, or the new (UHR) Special User Info field (e.g., 2008) of the BSRP (UHR) TF, and are not limited to the example presented in FIG. 26. That is, the position of each field and signaling bit, the number of bits, and the names may change. For example, some information not presented may be included in the Common Info field and / or User Info field and / or Special User Info field. For example, Reserved bits at other locations within the Common Info field may be used.

[0710] Additionally or alternatively, the (UHR) Special User Info field (i.e., MU-MIMO User Info-(n)) presented in FIG. 26 may be included within the Common Info, User Info, or Special User Info field within the frame for triggering Co-BF.

[0711] Figure 27 illustrates an example of Common and Special User Info fields of BSRP TF based on a new GI = 3 value.

[0712] Additionally or alternatively, the Co-BF PHY Common information and some additional information contained in the Common Info field of FIG. 26 may be included in the Common Info and Special User Info fields (2007) as in FIG. 27. Specifically, B4-B15 (UL Length) in the Common Info field may be reused to indicate the length of the Co-BF DL PPDU. Also, UL BW (B18 B19) and the PHY Version Identifier (B12-B14) and UL Bandwidth Extension (B15-B16) in the Special User Info field (2007) may be reused. Except for these, the PHY Common information for Co-BF may be included by redesigning unused or reserved fields within the Common Info field and Special User Info field. For example, information such as Minimum Number of Data OFDM Symbols, Maximum Number of Data OFDM Symbols, Maximum Total Nss Allowed for shared AP, Punctured Channel Information, GI+LTF Size, Number of CoBF Users in sharing BSS, and ICF / ICR Required may be included in B22–B53 of the Common Info field or B17–B36 of the Special User Info field. Additionally, a 3-bit MAPC Type field is defined using B56–B58 (DRU / RRU Indication) of the Common Info field to include Co-BF or a specific frame type (i.e.You can specify the type of the MAPC scheme by using Co-BF Sync, or by using the existing reserved bits B38 and B39 in the Special User Info field to include the MAPC Type field (e.g., Co-BF / SR or Co-BF / SR_Mode-1 / SR_Mode-2).

[0713] Figure 28 illustrates Example-2 of the BSRP (UHR) TF format based on the new GI 3 value.

[0714] Additionally or alternatively, as shown in the example of FIG. 28, fields not used in the BSRP GI3 TF can be reserved (UHR), and Co-BF related information can be conveyed using only Special User Info (e.g., AID12 = 2008). In this case, the UL Length field of the Common Info field can be reused to indicate the PPDU length. Also, the User Info field can be reserved, excluding the AID12 field.

[0715] Additionally or alternatively, the User Info field, which may be reserved in the BSRP GI3 TF, may be utilized to include Per-User Info for Co-BF operations, and the remaining information may be included in the Special User Info field (e.g., AID12 = 2008). In this case, the UL Length field of the Common Info field may be reused to indicate the PPDU length. In this case, if the (UHR) Special User Info field (e.g., AID12 = 2008) is placed before the User Info field, a User Info field Present field / bit may be included to indicate the existence of a subsequent User Info field. For example, if a User Info field follows, the User Info field Present field within the (UHR) Special User Info field may be set to 1. Additionally or alternatively, if a User Info field is placed before a (UHR) Special User Info field (e.g., AID12 = 2008), a (UHR) Special User Info field Present field / bit may be included to indicate that a subsequent (UHR) Special User Info field exists within the User Info field.

[0716] FIG. 29 illustrates an example of a method using Special User Info (2007) and Feedback User Info (2008).

[0717] FIG. 30 illustrates an example of a method including Co-BF Per-User information.

[0718] Additionally or alternatively, as shown in FIG. 29, the reserved fields of the Common Info field may not be used, and Co-BF PHY Common information may be included in the Special User Info field (2007) and Feedback Info field (2008). Specifically, B4-B15 (UL Length) within the Common Info field may be reused to indicate the length of the Co-BF DL PPDU. Additionally, UL BW (B18 B19) and the PHY Version Identifier (B12-B14) and UL Bandwidth Extension (B15-B16) within the Special User Info field (2007) may also be reused. The PHY Common information for Co-BF, excluding these, may include relevant information by redesigning the unused or reserved fields within the Special User Info field (2007) and Feedback User Info field (2008), or by classifying the Feedback Type into Co-BF or Co-BF Invite frame. Additionally, the type of MAPC scheme can be indicated by including the MAPC Type field (e.g., Co-BF / SR or Co-BF / SR_Mode-1 / SR_Mode-2) using the existing reserved bits B38 and B39 within the Special User Info field (2007). The Feedback User Info field can be utilized to include additional PHY Common information for Co-BF within the Co-BF Invite frame. If the Feedback Type field of B12-B15 indicates Co-BF (e.g., set to 1 or 4), the subsequent 24 bits may indicate that they contain Co-BF Feedback Info.Alternatively, the Feedback Type can specifically indicate that it is a Co-BF Invite frame (e.g., set to 5). Depending on how the Feedback Type is indicated, the BSRP Type field may or may not exist. If the BSRP Type field exists, the 22 bits following the BSRP Type indication may contain different Co-BF Feedback Info. That is, the information following the sounding Invite / Co-BF Invite / Co-BF Sync indications may differ. The 24 bits (or 22 bits) within the Feedback User Info field may contain additional Co-BF PHY Common information as shown in FIG. 29.

[0719] Figure 31 illustrates an example of a method for including all Co-BF PHY Common information in the Feedback User Info field.

[0720] Figure 32 illustrates an example of a method for including all Co-BF PHY Common information in the User Info field.

[0721] Additionally or alternatively, the information regarding Min. Nbr. of Data OFDM Symbols and Max. Nbr. of Data OFDM Symbols contained within the Special User Info field (2007) of FIG. 29 may be included in an additional Feedback User Info field (2008). That is, the Common Info and Special User Info fields may not contain new information, and all information may be included in the Feedback User Info field. This method can be applied regardless of the GI value of the BSRP TF. In this case, a Present bit (e.g., More User Info or More Feedback Info) indicating the existence of an additional Feedback User Info field may be defined and included in the preceding Feedback User Info field. If the said Present bit is set to 1, it may mean that an additional Feedback User Info field exists. An example of this is shown in FIG. 31.

[0722] Additionally or alternatively, as shown in FIG. 32, Co-BF PHY Common information may be included in one or more User Info fields where the AID12 field is set as the AP ID of the target AP, without using the reserved Common Info and Special User Info fields (2007). In this case, a Present bit (e.g., More User Info field) indicating that an additional User Info field exists may be defined and included in the preceding User Info field. If the said Present bit is set to 1, it may mean that an additional User Info field (AID12 = AP ID) exists. An example of this is shown in FIG. 32.

[0723] To include Per-User information for a Co-BF Invite frame not presented in the examples of FIGS. 27 and 29, the User Info field can be utilized in the manner shown in FIGS. 30 (a), (b), and (c). For example, as shown in FIGS. 30 (a) and (b), the AID12 field can be set to the AP ID of the target coordinated AP or a new AID (e.g., 2009) to include information about the target STA of the Co-BF coordinating AP. In this case, the new AID value may indicate that it is a Co-BF User Info field containing Per-User information of the Co-BF. If the number of target STAs is three, two User Info fields can be utilized as shown in FIG. 30 (a). Alternatively, as shown in FIG. 30 (b), User Info fields containing only one STA information can be provided for each STA (N). Additionally or alternatively, as shown in Fig. 30 (c), the AID12 field can be set as the AID value of the target STA of the Co-BF coordinating AP and can subsequently include information about the Nss and the remaining STAs. In this case, a separate BSRP Type field can be included following the AID12 field, and the structure of the Co-BF User Info field and the method of arranging information can be defined differently depending on the transmission purpose of the TF.

[0724] FIG. 33 illustrates Example-1 of a method including Co-BF Per-User information based on the Feedback Type field.

[0725] FIG. 34 illustrates Example-2 of a method including Co-BF Per-User information based on the Feedback Type field.

[0726] Additionally or alternatively, the same method as FIGS. 31 and 32, which are examples of a method for including Co-BF PHY Common information within a Co-BF Invite frame, can be utilized to include Co-BF Per-User information. That is, Co-BF Per-User information can be included within a User Info field where the AID12 field is set to a new Special AID (e.g., 2008, 2009, etc.) or a corresponding AP ID. An example of this may be as shown in FIG. 33, and the structure and information arrangement method of the Co-BF Per-User User Info field may vary depending on the number of STAs included, but are not limited. That is, if information for only one STA is included, only one Co-BF Per-User User Info field is required, and B28-B39 may be reserved. Also, if information for two STAs is included, only one Co-BF Per-User User Info field may be required. Additionally, or alternatively, if additional information needs to be transmitted together even if it includes information for two STAs, it may be included separately in two Co-BF Per-User User Info fields. For example, as shown in FIG. 34, there may be Co-BF Per-User User Info field(s) corresponding to the number of STAs.

[0727] Additionally or alternatively, the reserved value of the Feedback Type field can be used to indicate that Per-User information from the Co-BF Invite frame is included.

[0728] Figure 35 illustrates Example-1 of a method containing all Co-BF information with two signaling fields.

[0729] Additionally or alternatively, a method to distinguish the included information by adding signaling fields within the Feedback Information field may be considered. That is, when the AID12 field of the User Info field is set to the AP ID and the Feedback Type field is indicated as Co-BF, the subsequent signaling fields can indicate the purpose and included information of the corresponding BSRP TF. Figure 35 illustrates an example of this. If the BSRP Type field within the Feedback Information field, which is indicated as Co-BF through the Feedback Type field, is defined as 1 bit, it can be distinguished whether it is a sounding invite frame or a transmission invite frame using a value of 0 or 1. Additionally or alternatively, if it is defined as a value of 2 bits or more, the distinction for a sync frame can be additionally indicated. In other words, the composition of the subsequent information may vary depending on the value indicated in the BSRP Type field. The Feedback Information field within the User Info field of a Co-BF invite frame may need to contain an amount of information exceeding 23 bits, and as a result, one or more User Info fields may exist. Therefore, an additional signaling field may exist to distinguish the format and included information of each User Info field. The Co-BF Info Type field can be defined as a value of 1 bit or 2 bits or more and is used to specifically distinguish the information included within the corresponding Co-BF Invite Feedback Information field. One or more User Info fields may be used to include common information for Co-BF operation.That is, as shown in FIG. 35, Co-BF Common information can be included in three User Info fields and indicated by the Co-BF Info Type field. Similarly, a separate value (i.e., Co-BF Info Type = Per-User in FIG. 35) can be defined and assigned to indicate that it is a Co-BF Invite Feedback Information field containing Per-User information. If information for only one STA is included, there is only one User Info field where the Co-BF Info Type field is designated as Per-User. Additionally, if information for one or more STAs is included, there may be as many User Info fields designated as Per-User as the number of corresponding STAs. In this case, a Present bit may be separately included to indicate the existence of additional User Info fields designated as Per-User.

[0730] Figure 36 illustrates an example of a BSRP (UHR) Trigger frame that serves as an ICF in the Polling procedure.

[0731] That is, an example of the BSRP (UHR) Trigger frame format for Co-BF transmission proposed herein may be as shown in FIG. 36, but is not limited thereto. For example, Ex 1) in FIG. 36 represents a case where the (UHR) Special User Info field is placed after the Common Info field (or EHT Special User Info field) in an example of a BSRP TF based on the existing GI And HE / EHT / UHR-LTF Type / TXS Mode value. One or more User Info field(s) may exist depending on the number of non-AP STAs addressed in the BSRP TF and / or the number of DAPs intended to perform Co-BF transmission. Additionally, or alternatively, Ex 2) represents an example of a BSRP (UHR) TF based on the new GI And HE / EHT / UHR-LTF Type / TXS Mode value (i.e., 3). In this case, since the BSRP TF is transmitted to the SU, there may be a User Info field that targets only a single AP.

[0732] 3-3) Using Padding

[0733] FIG. 37 illustrates an example of a BSRP (UHR) TF format containing information related to Co-BF transmission within the padding.

[0734] Additionally or alternatively, information for UHR features described and defined in '2) Information and contents for Co-BF transmission' above, common information for Multi-AP cooperation, and key / partial information required for Co-BF transmission may be included in the padding. That is, the information presented above may be included in the padding within the BSRP (UHR) TF as shown in FIG. 37.

[0735] 4) Example of BSRP (UHR) TF format in a triggering procedure

[0736] 4-1) Based on existing GI and HE / EHT / UHR-LTF Type / TXS Mode values

[0737] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the AP ID of the receiving AP (i.e., ID for Multi-AP cooperation) or the MAC address of the AP. Therefore, an AP that receives a BSRP TF addressed to it can recognize that the corresponding BSRP TF has been delivered as an ICF or triggering frame in MAPC operation. It is assumed that the BSRP TF can be transmitted for various purposes (e.g., DPS, NPCA, IDC, Coexistence, MAPC). Accordingly, a (UHR) Special User Info field can be defined and utilized to include an indicator of the purpose for which an ICF transmitted for one or more UHR features was sent, and to convey information necessary for Co-BF transmission to cooperative APs.

[0738] To do this, a new UHR Special User Info Field Flag (or UHR Function Control Indication) field can be defined using 1 bit of the Reserved bits of the Common Info field and its value can be set to 1. Additionally, or alternatively, a new UHR Special User Info Field Flag (or Present) field can be defined using 1 bit of the Reserved bits of Special User Info (i.e., AID12 = 2007) and its value can be set to 1.

[0739] Additionally or alternatively, the Reserved (1 bit) within the User Info field can be used to indicate whether there exists a UHR Special User Info field that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation (i.e., the UHR Special User Info Field Flag can be defined using the Reserved within the User Info field). This is a field defined and included for the purpose of indicating the presence of a UHR Special User Info field containing additional information. Additionally or alternatively, a UHR Special User Info field that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation may be placed before the existing User Info field to include MAPC-related user-specific information and may include a Presence bit indicating that there is an additional User Info field (or UHR Special User Info field) addressed to the corresponding AP.

[0740] To indicate that the corresponding UHR Special User Info field is a new Special User Info field in the UHR, the value of the AID12 field may be Reserved (e.g., one of 2008–2044 or one of 2047–4094). The UHR Special User Info field identified by the new AID12 value may be placed following the Common Info field, the User Info field, or the Special User Info field (i.e., AID12 = 2007) (of the EHT). Additionally, or alternatively, the UHR Special User Info field may be placed before or after the User Info field for the corresponding User.

[0741] Additionally or alternatively, the AID12 field may include a Multi-AP group ID (i.e., an ID for the set of APs that have formed a Multi-AP collaboration) or an AP ID (i.e., an ID assigned by an AP in a collaborative relationship within the formed Multi-AP group). Specifically, the local AP ID value assigned by SAP may be mapped / converted / interpreted as an AID12 value. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's BSSID and BSS color. Additionally or alternatively, the AID12 field may consist of part or all of the target DAP's BSS color. Additionally or alternatively, the AID12 field may consist of part of the target DAP's BSSID. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's AP ID and BSS color.

[0742] Figure 38 illustrates an example of Common / User Info in the BSRP TF format based on existing GI And UHR-LTF Type values.

[0743] FIG. 39 illustrates Example-1 of (UHR) Special User Info in BSRP TF format based on existing GI And UHR-LTF Type values.

[0744] FIG. 40 illustrates Example-2 of (UHR) Special User Info in BSRP TF format based on existing GI And UHR-LTF Type values.

[0745] FIGS. 39 and FIGS. 39 illustrate an example of a BSRP TF that reuses the existing BSRP TF format for the purpose of triggering Co-BF-based transmission and includes information related to Co-BF transmission that is not included in the Common Info and User Info fields. For example, common information for UHR features and common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-BF transmission' above may be included in one or more of the (UHR) Special User Info fields (e.g., AID12 = 2008, 2009, or AP ID). The location where each piece of information may be included and the type of information are not limited. Additionally, if the presented information is not used, the corresponding field may be reserved.

[0746] Specifically, FIG. 38 illustrates examples of Common and User Info fields of a BSRP TF that can be transmitted for the purpose of triggering a Co-BF-based transmission. The UL Length field (B4-B15) within the existing Common Info field can be reused to indicate DL PPDU length information in Co-BF transmission (i.e., can replace the Length field). Additionally, a Present / Flag bit to indicate the existence of a (New) Special User Info field (e.g., AID12 = 2008) can be included within the Common Info field, User Info field, or Special User Info field (i.e., AID12 = 2007). FIG. 39 illustrates an example of including information related to Co-BF operation within the (UHR) Special User Info field (e.g., AID12 = 2008).

[0747] Additionally or alternatively, one or more of the (UHR) Special User Info fields presented in FIG. 39 (e.g., Default, Common U-SIG Info, Non-OFDMA Common Info, MU-MIMO User Info-(n)) may be included in the Common Info, User Info, or (UHR) Special User Info fields within the frame for the Polling procedure. For example, the Default and / or Common U-SIG Info and / or Non-OFDMA Common Info fields may be included within the BSRP TF in the Polling procedure, and the MU-MIMO User Info-(n) field(s) may be included within the TF in the Triggering procedure (i.e., FIG. 40). The locations where each field may be included are not limited. Additionally or alternatively, if UHR Feature Type and / or Multi-AP Coordination Type information is indicated via the TF transmitted from SAP in the Polling procedure, the corresponding fields may be reserved.

[0748] Figure 41 illustrates Example-3 of (UHR) Special User Info in BSRP TF format based on existing GI And UHR-LTF Type values.

[0749] FIG. 42 illustrates an example of utilizing Common reuse, Special User (2007), and new Special User (2008 or later).

[0750] Additionally or alternatively, a BSRP Trigger frame for triggering Co-BF transmission may be defined to include Co-BF information as presented in FIG. 41. There may be one (UHR) Special User Info field (e.g., AID12 = 2008) containing Common Info for Co-BF transmission, and one or more User Info fields (i.e., AID12 = AP ID) containing Per-User Info for Co-BF transmission. In this case, a Per-User field Present field / bit may be included within the preceding User Info field to indicate the existence of additional User Info field(s).

[0751] Additionally or alternatively, as shown in FIG. 42, some information within the Common Info field and Special User Info field (2007) may be reused and some unused fields within the Special User Info field (2007) may be redesigned to include some PHY Common information for Co-BF, and the remaining PHY Common information for Co-BF may be included in a new (UHR) Special User Info field (e.g., Feedback User Info (AID = 2008) or 2009, etc.). Specifically, B4-B15 (UL Length) within the Common Info field may be reused to indicate the length of the Co-BF DL PPDU. Additionally, UL BW (B18 B19) and Number Of UHR-LTF Symbols (B23-B25) may also be reused for the transmission of the Co-BF DL PPDU. Similarly, the PHY Version Identifier (B12-B14) and UL Bandwidth Extension (B15-B16) within the Special User Info field (AID=2007) may also be reused. Excluding these, PHY Common information for Co-BF may be included by redesigning some unused fields (e.g., B17-B36 and B38-B39) within the Special User Info field (2007). For example, information on BSS Color 1, BSS Color 2, and the Number of UHR-SIG Symbols may be included within B17-B36 of the Special User Info field. Additionally, the MAPC Type field (e.g., B38-B39) may be utilized using the existing reserved bits B38-B39.The type of MAPC scheme can be indicated by including Co-BF / SR or Co-BF / SR_Mode-1 / SR_Mode-2. To include additional PHY Common information for Co-BF within the Sync frame, the Feedback User Info field (AID12 = 2008) can be utilized. If the Feedback Type field in B12-B15 indicates Co-BF (e.g., set to 1 or 4), the subsequent 24 bits may indicate that they contain Co-BF Feedback Info. Alternatively, the Feedback Type can specifically indicate that it is a Co-BF Sync frame (e.g., set to 6). Depending on how the Feedback Type is indicated, the BSRP Type field may or may not exist. If the BSRP Type field exists, the subsequent 22 bits may contain different Co-BF Feedback Info according to the BSRP Type indication. That is, the information following the instructions of sounding Invite / Co-BF Invite / Co-BF Sync may differ. Additional Co-BF PHY Common information may be included within the 24 bits (or 22 bits) of the Feedback User Info field as shown in FIG. 42.

[0752] Figure 43 illustrates an example of reusing some information and utilizing reserved information from Common and Special User (2007).

[0753] FIG. 44 illustrates an example of a method including Co-BF Per-User information.

[0754] Additionally or alternatively, as shown in FIG. 43, some information within the Common Info field and Special User Info field (2007) may be reused and some unused fields within the Common Info field and Special User Info field (2007) may be redesigned to include PHY Common information for all Co-BFs. Specifically, B4-B15 (UL Length) within the Common Info field may be reused to indicate the length of the Co-BF DL PPDU. Additionally, UL BW (B18 B19) and Number Of UHR-LTF Symbols (B23-B25) may also be reused for the transmission of the Co-BF DL PPDU. Likewise, the PHY Version Identifier (B12-B14) and UL Bandwidth Extension (B15-B16) within the Special User Info field (AID=2007) may also be reused. Except for this, PHY Common information for Co-BF may be included by redesigning some unused fields within the Common Info field and Special User Info field. For example, information such as TXOP, Punctured Channel Info, and Number of CoBF Users may be included in B37 to B52 (UL Spatial Reuse) of the Common Info field. For example, information such as GI+LTF Size, BSS Color 1, BSS Color 2, and Number of UHR-SIG Symbols may be included in B17 to B36 of the Special User Info field.Additionally, a 3-bit MAPC Type field can be defined using B56~B58 (DRU / RRU Indication) of the Common Info field to indicate Co-BF or a specific frame type (i.e., Co-BF Sync), or the type of the MAPC scheme can be indicated by including the MAPC Type field (e.g., Co-BF / SR or Co-BF / SR_Mode-1 / SR_Mode-2) using B38 B39, which are existing reserved bits in the Special User Info field.

[0755] Additionally or alternatively, the BSS Color 1 / 2 and Number of UHR-SIG Symbols information contained within the Special User Info field (2007) of FIG. 42, or additional Co-BF PHY Common information, may be included in one or more Feedback User Info fields (2008) or one or more User Info fields (AP ID). That is, the Common Info and Special User Info fields may not contain new information, and all information may be included in the Feedback User Info fields or User Info fields. This method may be applied regardless of the GI value of the BSRP TF. In this case, a Present bit (e.g., More User Info or More Feedback Info) indicating the existence of additional Feedback User Info or User Info fields may be defined and included in the preceding Feedback User Info or User Info field. If the said Present bit is set to 1, it may mean that additional Feedback User Info or User Info fields exist. An example of this is shown in FIG. 45.

[0756] FIG. 45 illustrates an example in which all information is included in the Feedback User or User Info field.

[0757] To include Per-User information for Co-BF that is not presented in the examples of FIGS. 42 and 43, the User Info field can be utilized in the manner shown in FIGS. 44 (a), (b), and (c). For example, the AID12 field can be set to the AP ID of the target coordinated AP and can include information about the Co-BF coordinating AP and the target STA of the Co-BF coordinated AP. Additionally or alternatively, the AID12 field can be set to the AID value of the Co-BF coordinating AP and the target STA of the Co-BF coordinated AP and can include related information within the User Info field. Additionally or alternatively, a separate AID value for including Per-User information for Co-BF can be defined (e.g., 2009), and the related information can be included within the Co-BF User Info field where the AID12 field is set to that value. At this time, the structure of the Co-BF User Info field and the arrangement of information can be defined differently depending on the purpose of TF transmission by including a separate BSRP Type field following the AID12 field.

[0758] The structure of the BSRP TF and the method of including Co-BF information presented in FIGS. 42, 43, and 44 can also be applied to the method presented in '4-2) Based on the new GI And HE / EHT / UHR-LTF Type / TXS Mode value (i.e., 3)' below. That is, Common Info, Special User Info, Feedback User Info, and User Info fields such as those in FIGS. 42, 43, and 44 can be configured by utilizing the reserved bits within the Common Info, Special User Info, and User Info fields of the BSRP TF set to GI = 3 (B20 B21 in Common Info field). The Feedback Type presented in FIG. 45 can be designated as Co-BF or defined and set as Co-BF Sync to indicate that it contains information corresponding to a Co-BF Sync frame. Additionally or alternatively, it may be defined and set as Co-BF Sync Common to indicate that it contains Common information for the Co-BF Sync frame.

[0759] FIG. 46 illustrates an example of a method for including Co-BF Sync Per-User information based on a Feedback Type field.

[0760] Additionally or alternatively, the same method as Fig. 45, which is an example of a method for including Co-BF Common information within a Co-BF Sync frame, can be utilized to include Co-BF Per-User information. That is, Co-BF Per-User information can be included within a User Info field where the AID12 field is set to a new Special AID (e.g., 2008, 2009, etc.) or a corresponding AP ID. An example of this may be as shown in Fig. 46, and the structure and information arrangement method of the Co-BF Per-User User Info field may vary depending on the information included, but are not limited thereto. The reserved value of the Feedback Type field can be used to indicate that Co-BF Per-User information is included. Additionally or alternatively, the reserved value of the Feedback Type field can be used to indicate that Per-User information in the Co-BF Sync frame is included. For example, the BSRP Type field and / or Co-BF Info Type field described above in this paper may be included.

[0761] 4-2) Based on new GI and HE / EHT / UHR-LTF Type / TXS Mode values ​​(i.e., 3)

[0762] FIG. 47 illustrates an example of the use of the (UHR) Special User Info field (AID=2008) in the BSRP TF format based on the new GI And UHR-LTF Type value.

[0763] FIG. 48 illustrates an example of the BSRP TF format based on the new GI And UHR-LTF Type value-2: (UHR) Special User Info field (AID=2008) not utilized.

[0764] FIG. 49 illustrates an example-3 of a BSRP TF format based on a new GI And UHR-LTF Type value: an example excluding some information.

[0765] FIGS. 47, 48, and 49 illustrate examples of the BSRP (UHR) TF format when the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field are reserved through the indication of a new subtype or mode using the GI And HE / EHT / UHR-LTF Type / TXS Mode field (i.e., 3) of the Common Info field, or when the reserved range is utilized to include Common Info for Multi-AP cooperation or Info for each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). One or more pieces of information described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, User Info field, or (UHR) Special User Info field of the BSRP (UHR) TF, and are not limited to the examples presented in FIGS. 47, 48, and 49. That is, the location, number, and names of each field and signaling bit may change. For example, some unspecified information may be included in the Common Info field and / or User Info field and / or (UHR) Special User Info field. For example, Reserved bits at different locations within the Common Info field may be used.

[0766] FIG. 47 illustrates an example of utilizing (UHR) Special User Info to include both common information for MAPC and scheme-specific information for Co-BF (e.g., Common U-SIG Info, Non-OFDMA Common Info, and MU-MIMO User Info). Additionally or alternatively, FIG. 48 illustrates an example of including the MU-MIMO User Info contained in the (UHR) Special User Info among the information presented in FIG. 47 within the User Info field, assuming that the receiving DAP does not send a response frame. In this case, after specifying the cooperation period in the Coordination Duration field within the first User Info field, the Coordination Duration field may be reserved for subsequent User Info fields directed toward the same DAP (i.e., having the same AID12 value). Alternatively, UL Length (B4-B15) may replace the Coordination Duration information or the Length field. Additionally or alternatively, if UHR Feature Type and / or Multi-AP Coordination Type information is specified through the TF transmitted from SAP in the Polling procedure, the corresponding field may be reserved.

[0767] Additionally or alternatively, the Common U-SIG Info fields (B29-B48) and Non-OFDMA Common Info information (e.g., GI+LTF Size, Number of UHR-LTF Symbols, Number of Non-OFDMA Users, Spatial Reuse) presented in FIGS. 47 and 48 may be included in the Common Info, User Info, or (UHR) Special User Info fields within the TF transmitted from SAP during the polling procedure. FIG. 49 also illustrates an example in which the MU-MIMO User Info included in the (UHR) Special User Info among the information presented in FIG. 47 is included in the User Info field, assuming the case where the receiving DAP does not send a response frame. In this case, after specifying the cooperation period in the Coordination Duration field within the first User Info field, the Coordination Duration field may be reserved for subsequent User Info fields directed to the same DAP (i.e., having the same AID12 value). Alternatively, UL Length may replace the Coordination Duration information. Additionally or alternatively, if UHR Feature Type and / or Multi-AP Coordination Type information is specified through the TF transmitted from SAP in the Polling procedure, the corresponding field may be reserved.

[0768] Figure 50 illustrates Example 4 of the (UHR) Special User Info field (AID12=2008) in the BSRP TF format based on the new GI 3 value.

[0769] Additionally or alternatively, a BSRP GI3 TF containing the same Co-BF information as the BSRP Trigger frame for triggering Co-BF transmission presented in FIG. 41 may be defined (Fig. 50). That is, in the Common Info field, only the UL Length field (B4-B14) is used to indicate the PPDU length, and the rest may be reserved. One or more (UHR) Special User Info fields (e.g., AID12 = 2008) containing PHY Common Info for Co-BF transmission may exist, and one or more User Info fields (i.e., AID12 = AP ID) containing Per-User Info for Co-BF transmission may exist. In this case, a Per-User field Present field / bit may be included within the preceding User Info field to indicate the existence of additional User Info field(s).

[0770] Additionally or alternatively, the method of FIG. 46 may be utilized. That is, Co-BF Per-User information may be included within the User Info field where the AID12 field is set to a new Special AID (e.g., 2008, 2009, etc.). An example of this may be as shown in FIG. 46, and the structure and arrangement method of the Co-BF Per-User User Info field may vary depending on the information included and are not limited thereto. The reserved value of the Feedback Type field ( FIG. 46) may be used to indicate that Co-BF Per-User information is included. Additionally or alternatively, the reserved value of the Feedback Type field may be used to indicate that Per-User information in the Co-BF Sync frame is included. For example, the BSRP Type field and / or Co-BF Info Type field described above in this section may be included.

[0771] Figure 51 illustrates an example of a BSRP (UHR) Trigger frame in a Triggering procedure.

[0772] That is, an example of a BSRP (UHR) Trigger frame format for triggering Co-BF transmission proposed herein may be as shown in FIG. 51, but is not limited thereto. For example, Ex 1) of FIG. 51 represents a case where one or more (UHR) Special User Info fields are placed after a Common Info field (or EHT Special User Info field). Depending on the amount of information required for Co-BF transmission, one or more (UHR) Special User Info field(s) or User Info field(s) may exist. Additionally or alternatively, Ex 2) represents an example of a BSRP (UHR) TF that does not include a (UHR) Special User Info field. In this case, one or more User Info field(s) having the same AP ID may exist to contain the information required for Co-BF transmission. Additionally or alternatively, one or more User Info field(s) having different AP IDs may exist to contain the information required for Co-BF transmission. Additionally or alternatively, Ex 3) represents the case where a (UHR) Special User Info field (e.g., AID12 = 2008) is placed after the User Info field. Depending on the amount of information required for Co-BF transmission, one or more (UHR) Special User Info field(s) or User Info field(s) may exist.

[0773] 4-3) Utilizing Padding

[0774] FIG. 52 illustrates an example of a BSRP (UHR) TF format containing information related to Co-BF transmission within the padding.

[0775] Additionally or alternatively, common information for UHR features and / or Multi-AP cooperation described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, and major / partial information required for Co-BF transmission may be included in the Padding. That is, as shown in FIG. 52, information related to the Co-BF transmission presented above may be included in the Padding within the BSRP (UHR) TF.

[0776] Additionally or alternatively, some of the Common U-SIG Info, Non-OFDMA Common Info, and MU-MIMO User Info-(n)) presented in FIG. 52 may be included within the Common Info, User Info, or (UHR) Special User Info fields in the frame for the Polling procedure. For example, the Common U-SIG Info and / or Non-OFDMA Common Info fields may be included within the BSRP TF in the Polling procedure, and the MU-MIMO User Info-(n) field(s) may be included within the TF in the Triggering procedure. The locations where each field may be included are not limited.

[0777] 4-4) Utilizing the PHY Version Identifier in the Special User Info field (AID = 2007)

[0778] To transmit information necessary for Co-BF transmission to cooperating APs, the Reserved value of the PHY Version Identifier within the (EHT) Special User Info field (i.e., AID12 = 2007) can be utilized. The PHY Version Identifier field within the existing Special User Info field (2007) is set to 0 to indicate EHT. In 802.11bn, 1 can be used to indicate UHR. That is, the Trigger frame variant and the PHY version of the solicited TB PPDU can be indicated with a value of 0 or 1.

[0779] In the case of Co-BF / SR, since each AP simultaneously transmits a DL PPDU to the target STA following the Triggering frame transmitted from the SAP, there is a difference from the method in which the existing Trigger frame solicits a UL TB PPDU. Therefore, a new type of trigger can be defined to solicit a DL Co-BF (or SR) PPDU by utilizing the reserved value of the PHY Version Identifier field within the Special User Info field (2007). To this end, one reserved value (i.e., PHY Version Identifier = 2) or two reserved values ​​(i.e., PHY Version Identifier = 2 and 3) to individually indicate Co-BF / SR can be utilized. For example, PHY Version Identifier = 2 indicates Co-BF and Co-SR, and the subsequent bits can be used to specifically indicate whether it is Co-BF or SR. That is, a separate Type field may exist to indicate the Scheme. Additionally or alternatively, PHY Version Identifier = 2 can indicate Co-BF and 3 can indicate Co-SR.

[0780] FIG. 53 illustrates an example of a BSRP TF format containing information related to Co-BF transmission using a PHY Version Identifier value.

[0781] If Co-BF or Co-SR is indicated by the PHY Version Identifier field and / or a separate Type field, the subsequent bits within the Special User Info field (2007) may be configured to include information related to the scheme. FIG. 53 shows an example of a BSRP Trigger frame that indicates Co-BF using the PHY Version Identifier and includes Co-BF-related information. In this case, the BSRP TF may be an existing BSRP Trigger frame or a BSRP GI3 Trigger frame. If the PHY Version Identifier within the Special User Info (2007) field indicates Co-BF, the subsequent information within the Special User Info (2007) field and the User Info field may be interpreted as a Co-BF User Info field.

[0782] 2. Utilizing MU-RTS Trigger Frames

[0783] 1) Structure and Format of MU-RTS TXS Trigger Frame for Co-BF / Co-SR

[0784] The structure and format of the MU-RTS TXS Trigger frame for Co-BF proposed in this section can be defined and designed as presented in the detailed section below.

[0785] FIG. 54 illustrates an example of a MU-RTS TXS TF-based Co-BF transmission trigger procedure.

[0786] FIG. 54 illustrates an example of a procedure for triggering a Co-BF transmission based on a MU-RTS TXS TF assumed herein. AP 1, acting as the SAP by acquiring a TXOP, can initiate and trigger a Co-BF transmission by transmitting a MU-RTS TXS TF. A target DAP (i.e., AP 2 in FIG. 54) that receives the MU-RTS TXS TF transmitted from the SAP may transmit a CTS frame as a confirmation of the start of the Co-BF transmission. Additionally, or alternatively, the CTS frame may be defined and implemented to be unsolicit. For example, in the case of C-TDMA, the CTS frame may be defined to be solicit, similar to the Triggered TXS of the existing EHT. On the other hand, in the case of C-SR / C-BF, the CTS frame may be defined to be unsolicit (i.e., may not respond with a CTS frame).

[0787] Basically, the MU-RTS TXS TF proposed in this specification can be defined and utilized based on the existing Triggered TXOP sharing mode (i.e., mode = 1 or 2). In the existing TXS mode = 2, since the STA allocated time is allowed to transmit MPDU(s) to other STAs, it can be extended to allow a DAP to transmit MPDU(s) to STAs within its own BSS.

[0788] In order for a MU-RTS TXS TF based on the existing TXS mode to trigger Co-BF, common information for Multi-AP cooperation and specific parameters related to each Multi-AP cooperation base technology may be included, and for this purpose, existing fields may be reused or new fields may be defined.

[0789] Specific information related to one or more common Multi-AP cooperation and Multi-AP cooperation base technologies described and defined above may be added and defined within the MU-RTS TXS TF, but is not limited thereto. Additionally, the specific designations (names) of the proposed information, fields, and signaling bit(s) may be changed (Reference: 2) Information and contents for Co-BF transmission).

[0790] Additionally or alternatively, when the AP receives a MU-RTS TXS TF in which the RA field is set to its own MAC address or the AID12 field within the User Info field contains an ID addressed to itself, it may recognize that the MU-RTS TXS TF is transmitted for the purpose of triggering a Multi-AP cooperation-based transmission based on the instructions in the Multi-AP Coordination Type field, regardless of the value of the TXS mode, and may decode and obtain additional information.

[0791] Additionally, or alternatively, the encoding method for the TXS mode of a MU-RTS TXS TF addressed to an AP may differ from the existing method. For example, a MU-RTS TXS TF addressed to an AP may be utilized for the purpose of Multi-AP cooperation and may be encoded as shown in Table 2 below. If a separate TXS mode for Multi-AP cooperation is defined as in Table 2, new exceptions and rules may be defined for this purpose. For example, a MU-RTS TXS TF addressed to an AP may be classified as a Class 1 frame. Additionally, or alternatively, a MU-RTS TXS TF in a specific TXS mode (e.g., TXS mode = 1) may differ in format from that of other TXS modes (e.g., 2 and 3). Additionally, or alternatively, an STA receiving a MU-RTS TXS TF in a specific TXS mode may not respond with a CTS frame (i.e., no response) depending on specific conditions or exception rules. Additionally or alternatively, a STA that receives a MU-RTS TXS TF, which is a specific TXS mode, may respond with a frame other than a CTS frame.

[0792] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate Multi-AP coordination.1 (for Co-TDMA)MU-RTS that initiates coordinated TDMA procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA.2 (for Co-SR)MU-RTS that initiates spatial reuse procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA.3 (for Co-BF)MU-RTS that initiates coordinated beamforming procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated STA.

[0793] FIG. 55 illustrates Example-1 of a procedure in which a DAP that receives a MU-RTS TXS TF configures and transmits a Co-BF PPDU.

[0794] Based on an example of the Triggered TXOP Sharing Mode field encoding method for Multi-AP cooperation presented in Table 2, a series of processes in which a DAP reads a MU-RTS TXS TF transmitted from SAP and obtains Co-BF related information can be configured as shown in Fig. 55. The DAP that has obtained Co-BF related information can construct a pre-UHR portion based on the information and transmit a Co-BF PPDU to the target STA.

[0795] Additionally or alternatively, the MU-RTS TXS TF for triggering Co-BF transmission proposed in this specification may be defined and utilized as a new Triggered TXOP sharing mode (i.e., mode = 3). That is, as shown in Table 3, it can be considered as a separate TXS mode for use in a Multi-AP cooperative environment, and new exceptions and rules may be defined for this purpose. For example, a MU-RTS TXS TF with TXS mode = 3 may be classified as a Class 1 frame. Additionally or alternatively, the format of a MU-RTS TXS TF with TXS mode = 3 may differ from that of mode = 1 and 2. That is, when the TXS Mode field is set to 3, values ​​from B22 (Reserved based on EHT variant) to B53 (Reserved based on EHT variant) within the Common Info field of the MU-RTS TXS TF may be reserved. The reserved range may be utilized to include common information for multi-AP cooperation or information specific to each multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). Additionally or alternatively, a STA that receives a MU-RTS TXS TF with TXS mode = 3 may not respond with a CTS frame under specific conditions or exception rules (i.e., no response). Additionally or alternatively, a STA that receives a MU-RTS TXS TF with TXS mode = 3 may respond with a frame other than a CTS frame.

[0796] Triggered TXOP Sharing Mode subfield valueDescription0MU-RTS that does not initiate TXS procedure.1MU-RTS that initiates TXS procedure wherein a scheduled AP can only transmit MPDU(s) addressed to its associated AP.2MU-RTS that initiates TXS procedure wherein a scheduled AP can transmit MPDU(s) addressed to its associated AP or addressed to another STA.3 (for Multi-AP coordination)MU-RTS that initiates coordination triggering procedure for Multi-AP coordination.

[0797] FIG. 56 illustrates Example-2 of a procedure in which a DAP that receives a MU-RTS TXS TF configures and transmits a Co-BF PPDU.

[0798] Based on an example of utilizing the Reserved value of the Triggered TXOP Sharing Mode field for Multi-AP cooperation presented in Table 3, a series of processes in which a DAP reads a MU-RTS TXS TF transmitted from SAP and obtains Co-BF related information can be configured as shown in Fig. 56. The DAP that has obtained Co-BF related information can configure a pre-UHR portion based on the information and transmit a Co-BF PPDU to the target STA.

[0799] 2) An example of the MU-RTS TXS TF format

[0800] 2-1) Utilizing Common / User Info / Special User Info fields

[0801] FIG. 57 illustrates an example-1 of the Common Info field within the MU-RTS TXS TF for triggering Co-BF transmission.

[0802] FIG. 57 illustrates examples of the Common Info field among the MU-RTS TXS Trigger frame formats for triggering Co-BF transmission in Multi-AP cooperation. The value of the TXS mode may be the same or different from the existing one, and may be encoded differently depending on the information included in the MU-RTS TXS TF. One or more pieces of information described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, User Info field, or Special User Info field of the MU-RTS TXS TF, and are not limited to the examples presented in FIG. 57. That is, the position, number, and names of each field and signaling bit may change. For example, the Coordination Triggering field and / or CTS Required field and / or Multi-AP Ack Policy Indicator field, etc., may be included in the User Info field and / or Special User Info field. For example, Reserved bits at different positions within the Common Info field may be used.

[0803] Specifically, FIG. 57 shows an example in which a new TXS mode (i.e., 3) for Multi-AP cooperation is defined and subsequent bits are utilized to include Multi-AP Info.

[0804] Additionally, or alternatively, you can indicate that the response frame is not solicit by omitting the CTS Required field and setting B4-B15 (UL Length -> Reserved) to 0 (or all 1s). Additionally, or alternatively, the Coordination Triggering field and the Multi-AP Ack Policy Indicator field may be omitted.

[0805] Additionally or alternatively, the Common U-SIG Info and Non-OFDMA Common Info related field(s) presented in FIG. 57 may be included within the Common Info, User Info, or (UHR) Special User Info fields in the ICF that may be transmitted from the SAP during the polling procedure. For example, the Common U-SIG Info and / or Non-OFDMA Common Info fields may be included within the ICF in the polling procedure, and the MU-MIMO User Info-(n) field(s) may be included within the TF in the triggering procedure. Alternatively, all of the Common U-SIG Info, Non-OFDMA Common Info, and MU-MIMO User Info-(n) may be included within the TF in the triggering procedure, and the polling procedure may be utilized to verify participation from each AP and / or to indicate the purpose of the ICF and the type of MAPC. The locations where each field may be included are not limited.

[0806] As shown in FIG. 57, when configuring the Common Info field, there is not enough space to include the MU-MIMO User Info field described above. Therefore, the MU-MIMO User Info field and additional information may be included in the Special User Info field or the new (UHR) Special User Info field for UHR.

[0807] FIG. 58 illustrates an example of a User Info field within a MU-RTS TXS TF for triggering Co-BF transmission.

[0808] FIG. 58 shows an example of a User Info field among the examples of the MU-RTS TXS Trigger frame format for coordination triggering in Multi-AP cooperation proposed in this specification. The position, number, and names of each field and signaling bit may change.

[0809] The AID12 field within the User Info field of the MU-RTS TXS TF for triggering Co-BF transmission can be replaced with an ID related to Multi-AP cooperation. For example, the ID related to Multi-AP cooperation may include the BSSID, BSS color, or a newly defined Multi-AP group ID (i.e., an ID for the set of APs that constitute Multi-AP cooperation) or an AP ID (i.e., an ID assigned by an AP in a cooperative relationship within the configured Multi-AP group). Specifically, the local AP ID value assigned by SAP can be mapped / converted / resolved to an AID12 value.

[0810] If the response frame from the MU-RTS TXS TF transmitted from SAP is not solicited, the RU Allocation field may be omitted or reserved. Alternatively, it may be used to include other information.

[0811] Additionally, the Allocation Duration field of the User Info field within the MU-RTS TXS TF may contain different values ​​or have different meanings depending on the Multi-AP cooperation-based technology. For example, in Co-TDMA, it may indicate and signify the time allocated to the cooperating DAP. On the other hand, in Co-SR and Co-BF, it may indicate and signify the period of cooperation with the cooperating DAP. Additionally, or alternatively, it may indicate the length of the PPDU that can be transmitted simultaneously while cooperating via Co-SR and Co-BF. Additionally, or alternatively, it may indicate a period including the length of one or more PPDUs that can be transmitted simultaneously while cooperating via Co-SR and Co-BF, the response frames (e.g., BA) for these PPDUs, and the intervals between them (e.g., SIFS, PIFS).

[0812] The Reserved field (10 bits) may contain separate operational parameters for each Multi-AP cooperation-based technology or user-specific information for each DAP. Additionally or alternatively, some of the information included in the Common Info field presented above may be defined and included by utilizing the Reserved field of the User Info field instead of the Common Info field. Additionally or alternatively, a Present (or flag) field indicating the existence or consecutive placement of a new (UHR) Special User Info field for the UHR may be defined and included by utilizing the Reserved field. Additionally or alternatively, a Present (or flag) field indicating the consecutive placement of additional User Info fields or (UHR) Special User Info fields transmitted to the same receiving STA may be defined and included by utilizing the Reserved field.

[0813] Additionally, or alternatively, a new (UHR) Special User Info field for UHR (or Multi-AP cooperation) may be defined within the MU-RTS TXS TF to include information related to Multi-AP cooperation. By default, in 802.11be, the Special User Info field is identified by the AID12 field value of 2007. Similar to the definition of the Special User Info field in EHT, a separate UHR Special User Info field (e.g., UHR Special User Info field) may be defined to include additional information regarding Multi-AP cooperation.

[0814] To this end, one bit of the Reserved bits in the Common Info field can be used to define a new UHR Special User Info Field Flag (or UHR Function Control Indication) field and set its value to 1. Additionally, or alternatively, the Reserved (1 bit) within the User Info field can be used to indicate whether there exists a UHR Special User Info field that can be newly defined for user-specific UHR or Multi-AP cooperation (i.e., the UHR Special User Info Field Flag can be defined using the Reserved within the User Info field). This is a field defined and included for the purpose of indicating the presence of a UHR Special User Info field containing additional information.

[0815] To indicate that the corresponding UHR Special User Info field is a new (UHR) Special User Info field in UHR, the value of the AID12 field may be Reserved (e.g., one of the values ​​between 2008 and 2044 or one of the values ​​between 2047 and 4094). The UHR Special User Info field identified by the new AID12 value may be placed following the Common Info field, the User Info field, or the (EHT) Special User Info field. Additionally or alternatively, the UHR Special User Info field may be placed before or after the User Info field for the corresponding User. Additionally or alternatively, the Multi-AP group ID (i.e., ID for the set of APs forming a Multi-AP collaboration) or AP ID (i.e., ID assigned by an AP in a collaborative relationship within the formed Multi-AP group) may be included in the AID12 field. Specifically, the local AP ID value assigned by SAP may be mapped / converted / resolved as an AID12 value. Additionally or alternatively, the AID12 field may be composed of a combination of the target DAP's BSSID and BSS color. Additionally or alternatively, the AID12 field may be composed of part or all of the target DAP's BSS color. Additionally or alternatively, the AID12 field may be composed of part of the target DAP's BSSID. Additionally or alternatively, the AID12 field may be composed of a combination of the target DAP's AP ID and BSS color.

[0816] FIG. 59 illustrates an example of the configuration of the UHR Special User Info field-(1).

[0817] FIG. 59 illustrates an example of utilizing the (UHR) Special User Info field to include MU-MIMO User Info fields that are not included within the Common Info field presented in FIG. 57. The UHR Special User Info field presented in FIG. 59 may exist separately for SAP and DAP. That is, there may exist a UHR Special User Info field containing MU-MIMO User Info for the target STA of the SAP-side Co-BF transmission and a UHR Special User Info field containing MU-MIMO User Info for the target STA of the DAP-side Co-BF transmission. These may be arranged consecutively or discontinuously and may have the same AID12 field value (e.g., Special AID or AP ID for DAP).

[0818] FIG. 60 illustrates an example of the configuration of the Common Info field and UHR Special User Info field-(2).

[0819] On the other hand, FIG. 60 illustrates a method of including a portion of Common Info for Multi-AP cooperation by utilizing Reserved in the Common Info field, and including scheme-specific Common Info and User Info in the UHR Special User Info field to trigger Co-BF transmission.

[0820] For example, common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, and major / partial information required for Co-BF transmission may be included in the (UHR) Special User Info field. The locations where each piece of information may be included may vary and are not limited. Additionally, one or more of the presented information may be included and are not limited.

[0821] Additionally or alternatively, one or more of the (UHR) Special User Info fields presented in FIG. 60 (e.g., Common U-SIG Info, Non-OFDMA Common Info, MU-MIMO User Info-(n)) may be included in the Common Info, User Info, or (UHR) Special User Info fields within the ICF that may be transmitted from the SAP during the polling procedure. For example, the ICF in the polling procedure may include Common U-SIG Info and / or Non-OFDMA Common Info fields, and the MU-MIMO User Info-(n) field(s) may be included in the TF in the triggering procedure. Alternatively, Common U-SIG Info, Non-OFDMA Common Info, and MU-MIMO User Info-(n) may all be included in the TF in the triggering procedure, and the polling procedure may be utilized to verify participation from each AP and / or to indicate the purpose of the ICF and the type of MAPC. The locations where each field can be included are not limited.

[0822] Additionally, or alternatively, there may be one or more User Info fields having the same AID12 field value, and subsequent User Info fields having the same AID12 field value arranged consecutively or non-contiguously may additionally contain user-specific information.

[0823] Additionally or alternatively, the method of FIGS. 45 and 46 may be utilized. That is, Co-BF Common and Co-BF Per-User information may be included in the Feedback User Info field where the AID12 field is set to 2008 or in the User Info field where the AP ID is set. An embodiment thereof may be the same as FIGS. 45 and 46, and the structure of the User Info field and the method of arranging information may vary depending on the information included, but are not limited thereto. The reserved value of the Feedback Type field may be used to indicate that Co-BF Common or Per-User information is included. Additionally or alternatively, the reserved value of the Feedback Type field may be used to indicate that Common or Per-User information in the Co-BF Sync, Invite, or Sounding Invite frame is included. For example, the BSRP Type field and / or Co-BF Info Type field described above in this section may be included.

[0824] FIG. 61 illustrates an example of a MU-RTS Trigger frame for triggering Co-BF transmission.

[0825] That is, an example of a MU-RTS Trigger frame format for Co-BF transmission proposed in this specification may be as shown in 61, but is not limited thereto.

[0826] 2-2) Using Padding

[0827] FIG. 62 illustrates an example-1 of a MU-RTS TXS TF format containing Co-BF transmission-related information within the padding.

[0828] Additionally or alternatively, common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, and major / partial information required for Co-BF transmission may be included in the Padding. That is, as shown in FIG. 62, information related to the Co-BF transmission presented above may be included in the Padding within the MU-RTS TF.

[0829] 2-3) When the RA field is set to an individual address (e.g., DAP's MAC address)

[0830] FIG. 63 illustrates an example-1 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0831] When the MU-RTS TXS TF transmitted by SAP is transmitted to a single DAP, that is, when the RA field of the MU-RTS TXS TF is set to the MAC address of the DAP, the design may be different from the format presented above. FIG. 63 shows an example of the Common Info and User Info fields when the RA field is set to the address of the DAP, as an example of the MU-RTS TXS Trigger frame format for triggering Co-BF transmission in Multi-AP cooperation (1). The value of the TXS mode may be the same or different from the existing one, and may be encoded differently depending on the information included in the MU-RTS TXS TF. One or more pieces of information described and defined in '2) Information and contents for Co-BF transmission' above may be included in the Common Info field, User Info field, or (UHR) Special User Info field of the MU-RTS TXS TF, and are not limited to the example presented in FIG. 63. That is, the location, number, and names of each field and signaling bit may change. For example, the Coordination Triggering field and / or CTS Required field and / or Multi-AP Ack Policy Indicator field, etc., may be included in the User Info field and / or (UHR) Special User Info field. For example, Reserved bits at different locations within the Common Info field may be used.

[0832] Specifically, FIG. 63 assumes a case where MU-RTS TXS TFs are individually addressed to the target DAP to trigger Co-BF transmission. A new TXS mode (i.e., 3) for Multi-AP cooperation can be defined and illustrates an example of utilizing the subsequent bits to include Multi-AP Common Info.

[0833] Additionally or alternatively, you can indicate that the response frame is not solicit by omitting the CTS Required field and setting B4-B15 (UL Length -> Reserved) to 0 (or all 1s). Additionally or alternatively, the Coordination Triggering field and the Multi-AP Ack Policy Indicator field may be omitted.

[0834] Additionally or alternatively, the PPDU length may be included and indicated in B4-B15 reserved in the MU-RTS TXS TF to indicate the length of the PPDU to be transmitted by the DAP. For example, in Co-TDMA, this may mean and indicate the time allocated to the cooperating DAP. On the other hand, in Co-SR and Co-BF, this may mean and indicate the period of cooperation with the cooperating DAP. Additionally or alternatively, the length of the PPDU that can be transmitted simultaneously while cooperating with Co-SR and Co-BF may be indicated. Additionally or alternatively, the period including the length of one or more PPDUs that can be transmitted simultaneously while cooperating with Co-SR and Co-BF, the response frames (e.g., BA), and the intervals between them (e.g., SIFS, PIFS), etc. may be indicated.

[0835] When configuring the Common Info field as shown in Fig. 63, there is not enough space to include the MU-MIMO User Info field described above. Therefore, the MU-MIMO User Info field and additional information may be included in the User Info field (i.e., the UHR variant User Info field format for Co-BF in Fig. 37) or in a new (UHR) Special User Info field for UHR. In the User Info field for Co-BF presented in Fig. 63, the AID12 field may be omitted because the MU-RTS TXS TF is addressed individually to a specific DAP. Therefore, it can be redesigned to include user-specific info. To include up to four STA information, there may be one or more User Info fields for Co-BF.

[0836] FIG. 64 illustrates an example-2 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0837] Additionally or alternatively, a format as shown in FIG. 64 can be configured by assuming that the Common Info field of the MU-RTS TXS TF for Co-BF transmission does not contain Info for MAPC and Co-BF transmission. In this case, the remaining bits / fields within the Common Info field of the MU-RTS TXS TF are reserved.

[0838] FIG. 64 shows an example of Common Info and User Info fields when the RA field is set to the address of the DAP in an example of a MU-RTS TXS Trigger frame format for triggering Co-BF transmission in Multi-AP cooperation (2).

[0839] As shown in FIG. 64, if the Common Info field does not include Multi-AP common info and scheme-specific info for Co-BF transmission, the corresponding information may be included in the UHR variant User Info field (or a new (UHR) Special User Info field for UHR). In FIG. 64, since the MU-RTS TXS TF is addressed individually to a specific DAP, the User Info field with the AID12 field omitted and the proposed User Info field for Co-BF can be designed. That is, it can be redesigned to include Multi-AP common info and user-specific info for Co-BF transmission. For example, the first User Info field may include a Multi-AP common info field and a common PHY parameters field, which is common info for Co-BF transmission. Subsequent Co-BF User Info fields may exist one or more times to include user-specific info and may include up to four STA information fields.

[0840] FIG. 65 illustrates an example-3 of an individually addressed MU-RTS TXS TF format for triggering Co-BF transmission.

[0841] Additionally or alternatively, the MU-RTS TXS TF for individually addressed Co-BF transmission may be configured in a format as shown in FIG. 65, assuming a case where it includes a new Co-BF Info field. In this case, the length of the Co-BF Info field of the MU-RTS TXS TF is not limited to 40 bits like the existing User Info field.

[0842] This specification defines the structure and format of a trigger frame that can be transmitted from SAP to DAP to trigger Co-BF transmission in a Multi-AP cooperative environment. Specifically, a BSRP (UHR) TF can be utilized to initiate Co-BF transmission. A new subtype or mode of BSRP (UHR) Trigger Frame can be defined by utilizing the GI and HE / EHT-LTF Type / TXS Mode fields of the BSRP TF. The newly defined BSRP (UHR) TF or an existing BSRP Trigger Frame can be utilized to trigger Co-BF (or Co-SR and Co-TDMA, etc.) transmission in MAPC and Initial Control Frames for various UHR features.

[0843] Additionally or alternatively, the MU-RTS TXS TF of the Triggered TXS procedure can be utilized to initiate Co-BF transmission. The existing TXS mode of the MU-RTS TXS TF can be used as is, or a new mode can be defined. Additionally or alternatively, for the MU-RTS TXS TF transmitted between APs, a separate Triggered TXS mode encoding can be defined.

[0844] 3. Utilizing BSRP Trigger Frames for Co-SR

[0845] 1) Structure and Format of the BSRP Trigger Frame for Co-SR

[0846] This specification defines a Trigger frame for the purpose of initiating and triggering Co-SR transmission. The structure and format of the BSRP Trigger frame for Co-SR proposed in this specification can be defined and designed as presented in the detailed sections below.

[0847] Additionally, this specification assumes that SAP transmits a BSRP TF to at least one DAP to trigger a Co-SR transmission or for a polling procedure targeting one or more cooperating APs. In this case, the BSRP TF transmitted for the polling procedure may also be transmitted to a non-AP STA connected to SAP (i.e., the AID12 value for the target non-AP STA may be included in the AID12 field within the User Info field).

[0848] Figure 21 illustrates an example of a BSRP TF-based Co-SR / Co-BF transmission trigger procedure.

[0849] FIG. 21 illustrates an example of a procedure for triggering a Co-SR / Co-BF transmission based on a BSRP TF assumed in this specification. AP 1, acting as the SAP, acquires a TXOP and transmits a BSRP TF acting as an initial control frame (ICF), thereby initiating and triggering the Co-SR / Co-BF transmission. Upon receiving the BSRP TF transmitted from the SAP, the target DAP (AP 2 in FIG. 28) may transmit a response frame (e.g., Management frame, BlockAck frame, etc.) as a confirmation of the start of the Co-SR / Co-BF transmission. Additionally or alternatively, the response frame may be defined and implemented to be unsolicit. For example, in the case of Co-SR / Co-BF, the response frame may be defined to be unsolicit (i.e., not responding with a response frame). Additionally or alternatively, a separate signaling bit / field may indicate no response.

[0850] Additionally or alternatively, the BSRP TF can be used as a trigger frame in a polling (or Multi-AP selection, coordination announcement) procedure that may be performed for the purpose of determining whether one or more cooperating APs will participate in Co-SR / Co-BF transmission. In this case, the BSRP TF can also serve as an ICF. Additionally or alternatively, the BSRP TF in the polling phase and the response frame thereto (e.g., Multi-STA BA) may be performed for the purpose of exchanging preliminary information for Co-SR / Co-BF transmission. FIG. 22 illustrates an example of performing a polling procedure in advance for Co-SR transmission based on the BSRP TF assumed herein.

[0851] FIG. 22 illustrates an example of a Co-SR / Co-BF transmission trigger procedure following a BSRP TF-based polling procedure.

[0852] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the receiving AP's AP ID (ID for Multi-AP cooperation) or the AP's MAC address. Therefore, the Spec may define that an AP receiving a BSRP TF addressed to it transmits a corresponding response frame (e.g., Multi-STA BA frame). In other words, based on definitions regarding the type and format of the ICF and ICR for Multi-AP cooperation operation between APs, each AP can transmit and receive appropriate ICFs and ICRs. For example, a BSRP TF transmitted by an SAP as an ICF is basically sent to a MU, and the receiving STAs (cooperating APs and non-AP STAs) respond by including an appropriate frame in the TB PPDU. At this time, the cooperating AP can respond with a specific frame (e.g., Multi-STA BlockAck) depending on the type and format of the ICR, and the non-AP STA can respond with the existing method (i.e., QoS Data / Null frame including A-Control) or with a specific frame (e.g., Multi-STA BlockAck) defined according to the mode of the non-AP STA (e.g., DPS, NPCA, IDC, Coexistence, etc.).

[0853] Additionally or alternatively, the BSRP TF can be defined and utilized as a new mode or subtype of the BSRP TF based on the existing GI And HE / EHT-LTF Type / TXS Mode field (i.e., B20-B21 within the EHT variant Common Info field). That is, as shown in Table 1, it can be defined for use with the main features of the UHR. When indicating the role of the ICF for the main features of the UHR, a field indicating which feature the corresponding BSRP UHR TF (tentative name) is intended to operate on can be included by utilizing the subsequent Reserved bit. By defining a new subtype of the BSRP TF in this way, the remaining fields, excluding those essential for the operation of each feature, can be defined to contain the information required for each feature (i.e., the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field can be reserved; this may differ from the format of the existing BSRP TF). Exceptions and rules can be additionally defined in this new subtype of the BSRP TF. For example, a BSRP TF with GI And HE / EHT-LTF Type / TXS Mode field = 3 can be classified as a Class 1 frame. Additionally, the remaining fields, excluding those essential for the operation of each feature, can be defined to contain the information required for each feature (i.e., the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field can be reserved, which may differ from the format of the existing BSRP TF).Additionally or alternatively, the reserved range may be utilized to include Common Info for Multi-AP cooperation or Info specific to each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). Additionally or alternatively, a STA receiving the BSRP (UHR) TF may not transmit a response frame under specific conditions / instructions. A separate signaling bit / field may be added for a no response. Additionally or alternatively, a STA receiving the BSRP (UHR) TF may respond with a frame of a different type than a QoS Data / Null frame containing BSR information. Additionally or alternatively, a STA receiving the BSRP (UHR) TF may transmit a non-TB PPDU or non-HT (dup) PPDU instead of a TB PPDU. For example, when the value of the GI And HE / EHT-LTF Type / TXS Mode field of the BSRP TF transmitted by the SAP as an ICF is set to 3, it is transmitted to the SU by default, and the receiving STA (i.e., cooperating AP or non-AP STA) responds by including an appropriate frame in a non-TB PPDU or non-HT (dup) PPDU. Specifically, the cooperating AP may respond by including a specific frame (e.g., Multi-STA BlockAck) in the non-TB PPDU or non-HT (dup) PPDU depending on the type and format of the ICR.

[0854] To trigger Co-SR / BF transmission, a BSRP (UHR) TF based on a new subtype may include common information for Multi-AP cooperation and specific parameters related to each Multi-AP cooperation base technology, and for this purpose, existing fields may be reused or new fields may be defined. The specific designations (names) of the proposed information, fields, and signaling bit(s) may be changed.

[0855] 2) Information and contents for Co-SR transmission

[0856] For example, common information for Multi-AP cooperation and specific information related to Co-SR / Co-BF transmission may be defined as follows. One or more of the information, fields, and signaling bit(s) presented below may be added and defined within the BSRP TF, but are not limited thereto. Additionally, the specific designations (names) of the proposed information, fields, and signaling bit(s) may be changed.

[0857] A. Address: Address information of the DAP that triggers the Co-SR / BF transmission (e.g., BSS color, BSSID for Multi-AP, or MAC address)

[0858] B. Multi-AP ID or AP ID: An ID locally assigned to each AP within a configured multi-AP group / set (e.g., 0, 1, 2, ...)

[0859] - For example, the relevant Multi-AP ID or AP ID can be included in the AID12 field within the User Info field of the Trigger frame.

[0860] -> Additionally or alternatively, a Multi-AP ID or AP ID may be included within the AID12 field of the UHR Special User Info field, which may be newly defined for UHR.

[0861] - For example, the relevant Multi-AP ID or AP ID may be included in the AID11 field within the STA Info field of the UHR NDP Announcement frame.

[0862] C. Operating channel: Information on the operating primary channel and punctured channel

[0863] - For example, channel information that operates commonly to ensure smooth cooperation between APs participating in MAPC

[0864] - For example, primary channel information that APs participating in MAPC can operate in common

[0865] Specifically, a new field that serves as the CCFS0 field within the UHR Operation Information field can be defined to indicate the channel center frequency index for 20 / 40 / 80 MHz channels.

[0866] Specifically, a new field that serves as the CCFS0 field within the UHR Operation Information field can be defined to indicate the channel center frequency for the primary 80 MHz channel of the 160 MHz channel or the channel center frequency for the primary 160 MHz channel of the 320 MHz channel.

[0867] In addition, a new field that serves as the CCFS1 field within the UHR Operation Information field can be defined to indicate the channel center frequency for a 160 MHz channel or the channel center frequency for a 320 MHz channel.

[0868] - For example, punctured channel information of APs participating in MAPC

[0869] Specifically, a new field that serves as the Disabled Subchannel Bitmap field within the UHR Operation Information field can be defined to indicate a punctured 20 MHz subchannel using a bitmap.

[0870] Bit value of 0 in the bitmap: Indicates that the corresponding 20 MHz subchannel is not punctured.

[0871] A bit value of 1 in the bitmap indicates that the corresponding 20 MHz subchannel is punctured.

[0872] - The primary channel of the coordinated AP may be included within the channel where the SAP operates.

[0873] - The primary channel of the coordinated AP may be included within the operation channel, excluding the punctured channel of the SAP.

[0874] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0875] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0876] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0877] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0878] D. Operating bandwidth: Information on operating bandwidth and maximum bandwidth

[0879] - For example, BW information that operates commonly for smooth cooperation among APs participating in MAPC

[0880] Specifically, the Operating channel and primary channel information described above can be utilized.

[0881] - For example, maximum bandwidth information of APs participating in MAPC

[0882] Specifically, a new field that performs the same role as the Channel Width field within the Control field of the UHR Operation Information field can be defined to indicate the channel width, which is the BSS BW information of each AP.

[0883] Set to 0: 20 MHz bandwidth indication

[0884] Set to 1: 40 MHz bandwidth indication

[0885] Set to 2: 80 MHz bandwidth indication

[0886] Set to 3: 160 / 80+80 MHz bandwidth indication

[0887] Set to 4: 320 / 160+160 MHz bandwidth indication

[0888] The remaining values ​​from 5 to 7 can be set to reserved.

[0889] - For example, BW field information within the SIG-A field

[0890] - For example, UL BW field information included within the Common Info field of the Trigger frame

[0891] - The bandwidth of DAP or CAP may be included within the total bandwidth in which SAP operates.

[0892] - For example, a new field for bandwidth indication can be added by modifying / redefining the Medium Time field of the QoS Characteristics element to include a new sub-field.

[0893] Specifically, a new field that performs the same role as the Channel Width field within the Control field of the UHR Operation Information field can be defined to indicate the channel width, which is the BSS BW information of each AP.

[0894] Set to 0: 20 MHz bandwidth indication

[0895] Set to 1: 40 MHz bandwidth indication

[0896] Set to 2: 80 MHz bandwidth indication

[0897] Set to 3: 160 / 80+80 MHz bandwidth indication

[0898] Set to 4: 320 / 160+160 MHz bandwidth indication

[0899] The remaining values ​​from 5 to 7 can be set to reserved.

[0900] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0901] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0902] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0903] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0904] E. UHR Feature Type (Feedback Type): Indicates the feature type of the BSRP (UHR) TF.

[0905] - That is, it indicates the purpose for which the BSRP (UHR) TF was transmitted (e.g., Co-SR or Co-SR Sync / Invite or MAPC).

[0906] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0907] - For example, utilizing EHT Reserved or Reserved in the Common Info field

[0908] Specifically, it can indicate the type for which a BSRP TF, which can be utilized as an ICF in Dynamic Power Saving (DPS), Inter-Device Coexistence (IDC), Non-primary Channel Access (NPCA), Multi-AP Coordination (MAPC), etc., was transmitted. An example of signaling is as follows.

[0909] bit 0: Indicates that it is a TF for multi-AP coordination operations.

[0910] bit 1: Indicates that it is a TF for DPS operation

[0911] bit 2: Indicates that it is a TF for IDC operations.

[0912] bit 3: Indicates that it is a TF for NPCA operations.

[0913] other bits: reserved

[0914] Specifically, it can indicate the type for which the BSRP TF was transmitted within a specific feature (e.g., MAPC). An example of signaling is as follows.

[0915] 0: Indicates that it has been transmitted to the ICF in the MAPC.

[0916] 1: Indicates that it was transmitted as a Co-Triggering frame in MAPC

[0917] 2: Indicates that it was transmitted to the CRF in the MAPC

[0918] 3: TBD

[0919] ...

[0920] -> Additionally or alternatively, specific types of particular UHR features and / or MAPC schemes can be indicated. An example of signaling is as follows.

[0921] 0: Co-existence

[0922] 1: Co-BF

[0923] 2: Co-SR

[0924] 3: Co-TDMA

[0925] 4: TBD

[0926] ...

[0927] -> Additionally or alternatively, control information regarding the type of a specific UHR feature and / or MAPC scheme and the role for which the corresponding TF was transmitted can be indicated together. An example of signaling is as follows.

[0928] 0: Co-existence

[0929] 1: Reserved

[0930] 2: Reserved

[0931] 3: ICF in Co-TDMA

[0932] 4: Sounding Invite frame in the sounding section at Co-BF

[0933] 5: Co-BF Invite frame in the transmission interval of Co-BF

[0934] 6: Synchronization (i.e., Co-Triggering) frame in Co-BF

[0935] 7: Co-SR Invite frame in the transmission interval of Co-SR

[0936] 8: Synchronization (i.e., Co-Triggering) frame in Co-SR

[0937] ...

[0938] Additionally or alternatively, control and info type information regarding the type of a specific UHR feature and / or MAPC scheme, the role for which the corresponding TF was transmitted, and specifically what type of information it contains can be indicated together. An example of signaling is as follows.

[0939] 0: Co-existence

[0940] 1: Reserved

[0941] 2: Reserved

[0942] 3: ICF in Co-TDMA

[0943] 4: Includes Common information in Co-BF sounding (i.e., Sounding Invite Common Info)

[0944] 5: Includes Per-User information in Co-BF sounding (i.e., Sounding Invite Per-User Info)

[0945] 6: Includes Common information for Invite in Co-BF (i.e., Invite Common Info)

[0946] 7: Includes Per-User information for Invite in Co-BF (i.e., Invite Per-User Info)

[0947] 8: Includes common information for synchronization in Co-BF (i.e., Sync Common Info)

[0948] 9: Includes Per-User information for synchronization in Co-BF (i.e., Sync Per-User Info)

[0949] 10: Includes information for Invite in Co-SR (i.e., Co-SR Invite Info)

[0950] 11: Includes information for synchronization in Co-SR (i.e., Co-SR Sync / Co-TF Info)

[0951] ...

[0952] - Additionally or alternatively, by utilizing Reserved, a UHR Feature field can be assumed for the purpose of soliciting response information for one or more operational purposes, such as DPS, IDC, NPCA, MAPC, etc., without specifying a single specific UHR Feature Type.

[0953] For example, each bit of the 4 bits can indicate a specific feature (e.g., DPS, IDC, NPCA, MAPC, etc.).

[0954] An example of soliciting feature type indications and response information using a combination of each bit (bitmap) is as follows.

[0955] If B56: MAPC, B57: DPS, B58: IDC, B59: NPCA, other bits: reserved, 1100 can solicit instructions and response information for MAPC and DPS operations.

[0956] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0957] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[0958] - Additionally or alternatively, the information may be included by redesigning the reserved bits or parts of the Special User Info field (i.e., AID=2007).

[0959] F. Feedback Information: A field containing Control Information specific to UHR features or MAPC schemes transmitted to the receiving STA via an ICF or CRF (i.e., BSRP TF), such as a Co-SR / BF Invite or Sync frame, or a field containing information related to or helpful in providing feedback information specific to UHR features or MAPC schemes that the transmitting device wishes to receive from the receiving device.

[0960] - For example, Control / Feedback Info corresponding to the feature specified in the Control Info / Feedback Type (e.g., MAPC Info or Co-BF / SR / TDMA Info, etc.)

[0961] For example, feature-specific information that must be transmitted to the receiving STA to operate as IDC, MAPC (or Co-BF / SR / TDMA), DPS, or NPCA

[0962] Specifically, common information regarding the feature

[0963] Specifically, user-specific information regarding the feature

[0964] For example, feature-specific information that must be transmitted to the receiving AP to operate as IDC, MAPC (or Co-BF / SR / TDMA), DPS, or NPCA

[0965] Specifically, common information regarding the feature

[0966] Specifically, user-specific information regarding the feature

[0967] G. Common Control / Feedback Info: Common Control / Feedback Info may contain common information for each feature (i.e., IDC, MAPC, DPS, NPCA, or Co-BF / SR / TDMA).

[0968] H. Per-User Control / Feedback Info: Per-User Control / Feedback Info may include user-specific information (i.e., non-AP STA or AP) for each feature (i.e., IDC, MAPC, DPS, NPCA, or Co-BF / SR / TDMA).

[0969] - Additionally or alternatively, the ICF or CRF may include information that can be included in the existing A-Control field (e.g., BSR) in addition to information related to IDC Info, MAPC (Co-BF / SR / TDMA) Info, DPS Info, NPCA Info, etc. as presented in this specification.

[0970] I. Response Type: Indicates the type of response frame for the transmitted TF or the type of information solicited from the receiving device.

[0971] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0972] - For example, utilizing EHT Reserved or Reserved in the Common Info field

[0973] Specifically, the type of TF that can be utilized as an ICF in DPS, IDC, NPCA, MAPC, etc., can indicate for what purpose it was transmitted and which response frame it solicits, and an example of signaling is as follows.

[0974] bit 0: No response (unsolicited)

[0975] bit 1: Instructs the receiving device to respond with a QoS Null / Data frame (including the A-Control field).

[0976] bit 2: Instructs the receiving device to respond with a BlockAck frame (e.g., Multi-STA BA).

[0977] bit 3: Instructs the receiving device to respond with an Action frame (including the A-Control field).

[0978] bit 4: Reserved

[0979] Depending on the solicit type and method, more bits can be used, and bitmaps can be utilized.

[0980] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0981] - Additionally or alternatively, one or more User Info field(s) with the same AID may exist, and additional User Info fields may include bits or fields to indicate the Response type.

[0982] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field that can be newly defined for UHR.

[0983] - Additionally or alternatively, a Response Type field may be assumed for the purpose of soliciting response Info for one or more operational purposes, such as DPS, IDC, NPCA, MAPC, etc., by utilizing Reserved and integrating with the above-mentioned UHR Feature Type field.

[0984] For example, each bit of the 4 bits can indicate a specific feature (e.g., DPS, IDC, NPCA, MAPC, etc.).

[0985] An example of soliciting feature type indications and response information using a combination of each bit (bitmap) is as follows.

[0986] If B56: MAPC, B57: DPS, B58: IDC, B59: NPCA, other bits: reserved, 1100 can solicit instructions and response information for MAPC and DPS operations.

[0987] J. General Response: Allows a General response as a response frame for the transmitted TF.

[0988] - For example, allow the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, or QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields) in response to Basic TF.

[0989] - For example, allow the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, or QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields) in response to a BSRP TF.

[0990] - For example, allows the transmission of Multi-STA BA (or Compressed BA) frames, Action frames, QoS Null / Data frames (with a new A-Control field or with one or more A-Control fields), CTS frames, etc., in response to a MU-RTS (TXS) TF.

[0991] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[0992] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field that can be newly defined for UHR.

[0993] K. Multi-AP Coordination (MAPC) Type: Instructions for Multi-AP cooperative transmission techniques such as Co-TDMA, Co-SR, and Co-BF

[0994] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[0995] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[0996] Specifically, defining a new field to indicate the Multi-AP Coordination Type by utilizing one or more bits corresponding to EHT Reserved (i.e., utilizing 1 to n bits depending on the number of Multi-AP cooperative transmission techniques that can be reflected in the new definition and standard).

[0997] Specifically, defining a new field to indicate the Multi-AP Coordination Type by utilizing one or more bits corresponding to Reserved fields / bits (i.e., utilizing 1 to n bits depending on the number of Multi-AP cooperative transmission techniques that can be reflected in the new definition and standard)

[0998] For example, signaling can be done as follows

[0999] bit 0: None

[1000] bit 1: Co-TDMA

[1001] bit 2: Co-SR

[1002] bit 3: Co-BF

[1003] ...

[1004] For example, signaling can be done as follows

[1005] 0: Co-TDMA

[1006] 1: Co-SR

[1007] 2: Co-BF

[1008] ...

[1009] Additionally or alternatively, control information regarding the MAPC Type and the role for which the corresponding TF was transmitted can be signaled together.

[1010] For example, signaling can be done as follows based on each bit value.

[1011] 0: The role of ICF in Co-TDMA

[1012] 1: The role of TXOP return in Co-TDMA

[1013] 2: ICF (or Invite) role for the transmission section in Co-SR

[1014] 3: The Role of Synchronization / Co-Triggering Frames in Co-SR

[1015] 4: ICF (or Invite) role for the transmission section in Co-BF

[1016] 5: Role of Synchronization / Co-Triggering Frames in Co-BF

[1017] 6: The role of ICF (or Invite) for the sounding section in Co-BF

[1018] 7: Role of a trigger frame for sounding failure recovery in Co-BF

[1019] ...

[1020] -> Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1021] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1022] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1023] L. Coordination Triggering: Indicates that it is a BSRP (UHR) TF transmitted to trigger a Multi-AP cooperative-based transmission (e.g., Co-SR).

[1024] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[1025] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1026] Specifically, defining a new field to indicate a BSRP (UHR) TF for Coordination Triggering by utilizing one or more bits corresponding to EHT Reserved.

[1027] Specifically, defining a new field to indicate a BSRP (UHR) TF for Coordination Triggering by utilizing one or more bits corresponding to Reserved fields / bits.

[1028] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1029] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1030] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1031] M. BSRP Type (or Co-SR / BF Subtype): Separately indicates control information regarding the role for which the corresponding BSRP TF was transmitted.

[1032] - That is, among the embodiments for the MAPC Type field and / or Coordination Triggering described above, control information regarding what role the corresponding TF was transmitted for can be indicated through a separate BSRP Type field.

[1033] For example, signaling can be done as follows based on each bit value

[1034] 0: Role of ICF or Invite Frame in the sounding phase

[1035] 1: Role of ICF or Invite Frame in Transmission Phase

[1036] 2: Role of Synchronization or Co-Triggering Frame in Transmission Phase

[1037] 3: Role of a trigger frame for the purpose of sounding failure recovery

[1038] 4: Role of the Intermediate Control frame during the sounding or transmission phase (e.g., the role of the TXOP return frame in Co-TDMA)

[1039] ...

[1040] -> Additionally or alternatively, signaling can be done with 1 bit as follows

[1041] 0: Role of ICF or Invite Frame in Transmission Phase

[1042] 1: Role of the Sync (Co-Triggering) frame in the transmission phase

[1043] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1044] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1045] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1046] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1047] N. Co-SR / BF Info Type: Indicates specifically what information the frame includes in the Feedback Information field regarding Co-SR / BF transmission.

[1048] - In other words, a separate Co-SR / BF Info Type field can be used to indicate whether Common or Per-User information for Co-SR / BF operation is included.

[1049] Alternatively, whether to include MAC or PHY information for Co-SR / BF operation can be indicated through a separate Co-SR / BF Info Type field.

[1050] For example, signaling can be done with 1 bit as follows

[1051] 0: Includes Co-SR / BF Common Info

[1052] 1: Includes Co-SR / BF Per-User Info (i.e., Per-STA Info)

[1053] -> Additionally or alternatively, signaling can be done with 1 bit as follows

[1054] 0: Contains Common Info for Co-SR / BF operation and indicates the first Common Info.

[1055] 1: Includes Common Info for Co-SR / BF operation and indicates the second Common Info

[1056] -> Additionally or alternatively, signaling can be done with 2 or more bits as follows

[1057] 0: Contains Common Info for Co-SR / BF operation and indicates the first Common Info.

[1058] 1: Includes Common Info for Co-SR / BF operation and indicates the second Common Info

[1059] 2: Includes Common Info for Co-SR / BF operation and indicates the third Common Info.

[1060] 3: reserved

[1061] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1062] - Additionally or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1063] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1064] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1065] O. (Scheduled) Coordination Duration or Whole TXOP Duration: The period during which SAP collaborates with DAPs to perform Co-SR / BF-based transfers, or the total coordination TXOP (Whole TXOP) period scheduled for MAPC operations.

[1066] - For example, specify the expected / scheduled coordination duration anticipated by SAP

[1067] - For example, the total cooperation TXOP period during which SAP intends to perform MAPC operations

[1068] - For example, define a new field including Coordination Duration or Whole TXOP Duration to indicate

[1069] Specifically, define a new field tentatively named Coordination or Whole TXOP Duration to indicate the information necessary for MAPC operation and the Coordination or Whole TXOP Duration values.

[1070] - For example, utilizing the Allocation Duration field of the User Info field in the MU-RTS TXS Trigger frame

[1071] Specifically, instruct by including the corresponding period value in the Allocation Duration field.

[1072] - The relevant information can be included by utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1073] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1074] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1075] - Additionally or alternatively, the information may be included in the Special User Info field (2007).

[1076] P. Traffic Priority: Priority information of traffic recommended by SAP to DAP, priority information of traffic allowed by SAP to DAP, or priority information of traffic / AC allowed by SAP to DAP

[1077] - For example, TID / AC information regarding traffic allowed to the DAP within the TXOP obtained by SAP

[1078] - For example, Primary AC information for TXOPs obtained by SAP (obtained TXOP)

[1079] Specifically, if traffic for only one of AC_BK, AC_BE, AC_VI, or AC_VO is allowed, the DAP may transmit only traffic corresponding to that AC within the allocated period or cooperation period.

[1080] Specifically, a 2-bit ACI field can be defined to indicate as follows (ACI-to-AC coding)

[1081] AC index (ACI) 0 = AC_BE (best effort)

[1082] AC index (ACI) 1 = AC_BK (background)

[1083] AC index (ACI) 2 = AC_VI (video)

[1084] AC index (ACI) 3 = AC_VO (voice)

[1085] - Additionally or alternatively, SAP may designate a Primary AC for the acquired TXOP, and based on said Primary AC, the CAP (coordinated AP) may transmit traffic corresponding to an AC equal to or greater than said AC within the allocated period or cooperation period.

[1086] Specifically, a new 2-bit field can be defined to indicate as follows (ACI-to-AC coding)

[1087] AC index (ACI) 0 = AC_BE (best effort)

[1088] AC index (ACI) 1 = AC_BK (background)

[1089] AC index (ACI) 2 = AC_VI (video)

[1090] AC index (ACI) 3 = AC_VO (voice)

[1091] - Additionally or alternatively, seven User Priorities (UPs) may be provided as Traffic Categories, and a CAP may transmit only traffic corresponding to an AC that is less than or equal to the UP within the allocated period or cooperation period.

[1092] Specifically, a new 4-bit field can be defined to indicate as follows (UP-to-AC mapping)

[1093] User Priority (UP) 1 = AC_BK

[1094] UP 2 = AC_BK

[1095] UP 0 = AC_BE

[1096] UP 3 = AC_BE

[1097] UP 4 = AC_VI

[1098] UP 5 = AC_VI

[1099] UP 6 = AC_VO

[1100] UP 7 = AC_VO

[1101] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1102] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1103] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1104] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1105] Q. Protection Level: Indicates the protection level for the efficient operation of the currently operating cooperative transmission.

[1106] - For example, in Co-SR / BF operation, this may mean that protection is required until Co-Triggering is performed.

[1107] - For example, utilizing the EHT Reserved (7 bits) or Reserved of the Common Info field

[1108] Specifically, it uses the 2 bits corresponding to EHT / UHR Reserved or Reserved to indicate the protection level of the currently operating cooperative transmission.

[1109] 0: Indicates that it is a cooperative transmission with a protection level of 0 (for example, in Co-TDMA / SR / BF operation, this may mean that separate protection (i.e., long NAV setting) is not required for the transmission / reception of ICF, ICR, and Co-Triggering frames).

[1110] 1: Indicates that it is a cooperative transmission with a protection level of 1 (for example, in Co-TDMA / SR / BF operation, this may mean that separate protection (i.e., NAV setting) is required from the ICF / ICR exchange until the transmission of the Co-Triggering frame).

[1111] 2: Indicates that it is a cooperative transmission with a protection level of 2 (for example, this may mean that separate protection (i.e., long NAV setting) is required when transmitting a Co-Triggering frame to ensure a successful TXOP return in Co-TDMA operation).

[1112] 3: Indicates that it is a cooperative transmission with a protection level of 3 (for example, this may mean that all procedures leading from the transmission and reception of ICF, ICR, and Co-Triggering frames in Co-TDMA / SR / BF operation are protected (i.e., long NAV setting)).

[1113] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1114] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1115] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1116] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1117] R. Recommended Tx Power: Maximum Tx power information recommended by SAP to the DAP triggering the Co-SR transfer.

[1118] - For example, in a scenario where SAP determines the Tx power of a DAP performing Co-SR transmission, SAP can determine the recommended maximum Tx power for the DAP that does not cause interference with its transmission.

[1119] - For example, it can mean the maximum threshold Tx power of the DAP during the Co-SR transmission period.

[1120] In other words, the Recommended Tx Power that SAP conveys to the DAP can refer to an absolute value (e.g., calculated in units of dBm).

[1121] - For example, it can refer to the relative Tx power value allowed to the DAP during the Co-SR transmission period.

[1122] In other words, the Recommended Tx Power that SAP conveys to the DAP can represent a relative value.

[1123] Specifically, the value obtained by subtracting the maximum Tx power recommended to the DAP from SAP's Tx Power (i.e., Tx Power of SAP - Recommended Tx Power of DAP)

[1124] Additionally or alternatively, the value obtained by subtracting SAP's Tx Power from the maximum Tx power recommended to the DAP (i.e., Recommended Tx Power of DAP - Tx Power of SAP)

[1125] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1126] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1127] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1128] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1129] S. Multi-AP Ack Policy Indicator: Indicates the Ack policy during the Co-SR / BF transmission period or the Ack policy that the DAP and the STA connected to the DAP must follow during the coordination duration.

[1130] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[1131] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1132] Specifically, it utilizes the 2 bits corresponding to EHT Reserved or Reserved to instruct the Ack policy for frame exchanges between cooperating APs during the Co-SR Duration.

[1133] For example, it can be defined similarly to the Ack Policy Indicator field within the QoS Control field.

[1134] Bit 0 = 0 & Bit 1 = 0: Indicates a normal ACK or an implicit BAR.

[1135] Bit 0 = 1 & Bit 1 = 0: Indicates No Ack

[1136] Bit 0 = 0 & Bit 1 = 1: Reserved or HETP Ack

[1137] Bit 0 = 1 & Bit 1 = 1: Indicates Block Ack

[1138] For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1139] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1140] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1141] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1142] T. DL / UL Indication: Indicates whether a DL transmission or a UL transmission is scheduled to be performed during the Co-SR / BF transmission period.

[1143] U. Tx Power: SAP's maximum Tx power information

[1144] - For example, DAP can determine an appropriate Tx power that does not cause interference based on the maximum Tx power information transmitted by SAP.

[1145] - For example, utilizing the AP Tx Power field of the Common Info field

[1146] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1147] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1148] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1149] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1150] V. In-BSS STA Info: Indicates information about the Target STA for which SAP will perform DL / UL transfer, or information about all connected STAs.

[1151] - For example, the identifiers and capabilities of all STAs connected to SAP

[1152] For example, the AID or MAC addresses of the STAs

[1153] For example, STAs' MIMO and RF capabilities

[1154] - For example, the identifier and capability of the target STA among the STAs connected to SAP that intends to perform DL / UL transmission based on Co-SR

[1155] For example, the AID or MAC address of the Target STA

[1156] For example, the MIMO and RF capabilities of the Target STA

[1157] For example, the PHY version of the Target STA

[1158] - For example, an identifier for an In-BSS STA that you want to include in the Multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation

[1159] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1160] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1161] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1162] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1163] W. OBSS STA Info: Indicates information about the OBSS Target STA on which the DAP must perform DL / UL transmission.

[1164] - For example, the identifier and capability of the target OBSS STA among the OBSS STAs connected to the DAP that intends to perform DL / UL transmission based on Co-SR

[1165] For example, the AID or MAC address of the Target OBSS STA

[1166] For example, the MIMO and RF capabilities of the Target OBSS STA

[1167] For example, the PHY version of the Target STA

[1168] - For example, an identifier for an OBSS STA that you want to include in the Multi-AP channel sounding (or OBSS channel sounding) process for MAPC operation

[1169] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1170] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1171] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1172] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1173] X. Common L-SIG Info: The Common L-SIG Info field contains L-SIG information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperation (i.e., Co-SR) transmission period.

[1174] - For example, the Length (B5-B16) information of the L-SIG field within a MU PPDU (e.g., EHT, UHR, etc.) may correspond to the Common L-SIG Info field. This can be considered as a value indicating the duration of the DL PPDU transmitted by each AP.

[1175] - For example, utilizing the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field

[1176] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1177] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1178] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1179] Y. Common U-SIG Info: One or more of the information presented below may be added to and defined within the Common U-SIG Info field, but is not limited to. The Common U-SIG Info field indicates and includes U-SIG-1 and U-SIG-2 information that must be commonly included in the DL PPDU transmitted by each AP during the relevant cooperation-based transmission period.

[1180] - For example, PHY Version Identifier (B0-B2) information in the U-SIG-1 field within MU PPDU (e.g., EHT, UHR, etc.)

[1181] Specifically, it indicates the PHY version of the DL PPDU transmitted by each AP during the Co-SR transmission period.

[1182] Additionally or alternatively, SAP specifies the PHY version of the target STA to which it intends to send the DL PPDU during the Co-SR transmission time.

[1183] - For example, Bandwidth (B3-B5) information of the U-SIG-1 field within MU PPDU (e.g., EHT, UHR, etc.)

[1184] Specifically, it indicates the bandwidth of the DL PPDU transmitted by each AP during the Co-SR transmission period.

[1185] -> Additionally or alternatively, it may be a bandwidth based on the bandwidth of the PPDU containing the ICF transmitted by the SAP.

[1186] -> Additionally or alternatively, when a response frame (e.g., M-BA frame) for an ICF transmitted by the SAP exists, it may be a bandwidth based on the bandwidth of the PPDU containing said M-BA frame.

[1187] - For example, UL / DL (B6) information in the U-SIG-1 field within the MU PPDU (e.g., EHT, UHR, etc.)

[1188] Specifically, it indicates whether DL transmission or UL transmission is scheduled to be performed during the relevant Co-SR transmission period.

[1189] - For example, Punctured Channel Information (B3-B7) of the U-SIG-2 field within MU PPDU (e.g., EHT, UHR, etc.)

[1190] Additionally or alternatively, the PPDU containing the ICF transmitted by the SAP may be punctured based on long-term punctured channel info (e.g., all punctured 20 MHz subchannels specified in the TXVECTOR parameter INACTIVE_SUBCHANNELS).

[1191] -> Additionally or alternatively, it can be punctured based on the dynamic puncturing information of each AP

[1192] Additionally or alternatively, it may be a puncturing pattern composed of the union of the two APs' punctured 20 MHz.

[1193] - For example, a UHR-SIG MCS can be defined that performs the same role as the EHT-SIG MCS (B9-B10) of the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.).

[1194] Specifically, the value of UHR-SIG MCS can indicate the following MCS:

[1195] UHR-SIG MCS = 0 indicates UHR-MCS 0.

[1196] UHR-SIG MCS = 1 indicates UHR-MCS 1.

[1197] UHR-SIG MCS = 2 indicates UHR-MCS 3.

[1198] UHR-SIG MCS = 3 indicates UHR-MCS 15.

[1199] - Additionally or alternatively, it can be set to an MCS value that all STAs serviced by each AP can receive.

[1200] - For example, Number of UHR-SIG Symbols can be defined to serve the same role as Number of EHT-SIG Symbols (B11-B15) in the U-SIG-2 field within a MU PPDU (e.g., EHT, UHR, etc.).

[1201] -> Additionally or alternatively, it can be set to an OFDM symbol value configured by considering all user fields for all STAs connected to each AP.

[1202] - For example, a UHR-SIG TXOP can be defined that performs the same role as the TXOP (B13-B19) of the U-SIG field within a MU PPDU (e.g., EHT, UHR, etc.).

[1203] - For example, Spatial Configuration (B16-B19) information within the User field

[1204] Specifically, it specifies the number of spatial streams for each user in MU-MIMO allocation.

[1205] -> Additionally or alternatively, spatial stream allocation information for all STAs connected to each AP can be specified.

[1206] Additionally or alternatively, the Spatial Configuration field can be defined and utilized as 2 or 3 bits.

[1207] - One or more of the information described above may be included in the Common U-SIG Info field, but is not limited to.

[1208] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI and HE / EHT-LTF Type / TXS Mode field

[1209] Additionally, or as an alternative, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1210] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1211] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1212] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1213] Z. Co-SR Mode: Indicates the mode for Co-SR transmission.

[1214] - For example, Mode 1 indicates the case where the target STA for Co-SR transmission is EHT + EHT, EHT + UHR, or UHR + EHT.

[1215] -> Under Mode 1 instructions, Co-SR PPDUs transmitted by two APs during the Co-SR transmission period must have a common L-SIG, but the U-SIG contents may differ.

[1216] - For example, Mode 2 indicates the case where the target STA for Co-SR transmission is UHR+UHR.

[1217] -> The instructions of Mode 2 indicate that the Co-SR PPDU transmitted by the two APs during the Co-SR transmission period must have a common L-SIG and a common U-SIG.

[1218] - For example, the final Co-SR Mode information may be included in the BSRP (GI3) TF in the Triggering procedure (i.e., the TF that solicits the Co-SR PPDU).

[1219] That is, in the BSRP (GI3) TF (e.g., Invite frame or ICF) in the Polling procedure, the Sharing AP can indicate and specify the PHY version of the target STA to which it intends to send the Co-SR PPDU.

[1220] A coordinated AP (i.e., shared AP) that receives a BSRP (GI3) TF in the polling procedure can also indicate the PHY version of the target STA to which it intends to send the Co-SR PPDU.

[1221] - For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI And HE / EHT-LTF Type / TXS Mode field

[1222] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1223] - Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1224] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1225] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1226] a. ICF / ICR Required: Indicates whether an additional sequence is required to transmit the ICF to the associated STA before triggering the Co-SR / BF transmission.

[1227] - For example, it indicates that an ICF / ICR exchange procedure is required to switch the EMLSR STA among the associated STAs from listening mode to frame exchange mode.

[1228] - For example, it indicates that an ICF / ICR exchange procedure is required to switch a DPS STA among the associated STAs from low capability mode to high capability mode.

[1229] - For example, it indicates that an ICF / ICR exchange procedure is required to switch a DUO STA among the associated STAs.

[1230] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[1231] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1232] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1233] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1234] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1235] b. BSS Color 1 and BSS Color 2 (6 bits each): Indicates the BSS color of the SAP and the BSS color of the coordinated AP.

[1236] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[1237] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1238] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1239] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1240] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1241] c. Non-OFDMA Common Info: Non-OFDMA information that must be commonly included in the DL PPDU transmitted by each AP during the corresponding cooperative-based transmission period.

[1242] - For example, Spatial Reuse (4 bits) information within the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[1243] - For example, GI+LTF Size (B4-B5) information in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[1244] Specifically, it can be set to a GI+LTF value that enables all STAs serviced by each AP to reliably estimate the channel.

[1245] - For example, Number of UHR-LTF Symbols can be defined to serve the same role as Number of EHT-LTF Symbols (B6-B8) in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission.

[1246] Specifically, it can be set as the dimension of the Giant P matrix determined based on the sum of the spatial streams required for each AP.

[1247] -> Additionally or alternatively, it can be set to the larger of the LTF symbol values ​​required for each AP.

[1248] - For example, Number of Non-OFDMA Users (B17-B19) information in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission

[1249] Specifically, the value of the Number Of Non-OFDMA Users field can represent the sum of the number of SAP-side Co-SR target users and the number of DAP-side Co-SR target users.

[1250] Alternatively, the Number Of Non-OFDMA Users field can be defined as 2 bits, with each bit used to indicate the number of Co-SR target users for SAP and DAP.

[1251] For example, B17 indicates the number of SAP users (e.g., 0 is single user, 1 is 2 users)

[1252] For example, B18 indicates the number of DAP users (e.g., 0 is single user, 1 is 2 users)

[1253] - One or more of the information described above may be included in the BSRP Trigger frame, but is not limited to.

[1254] For example, utilizing fields / bits reserved in the Common Info field according to a new subtype definition using the GI and HE / EHT-LTF Type / TXS Mode field

[1255] Additionally, or as an alternative, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1256] -> Additionally or alternatively, the information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1257] -> Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1258] -> Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1259] d. ICF / ICR Duration: Indicates the period required to send the ICF to the coordinating AP's associated STA and receive the ICR before triggering the Co-SR / BF transmission.

[1260] - For example, if an ICF / ICR exchange procedure is required to switch an EMLSR STA among the associated STAs from listening mode to frame exchange mode, indicate the estimated period required for this.

[1261] - For example, if an ICF / ICR exchange procedure is required to switch a DPS STA among the associated STAs from low capability mode to high capability mode, indicate the estimated period required for this.

[1262] - For example, if an ICF / ICR exchange procedure is required to switch a DUO STA among the associated STAs, indicate the estimated period required for this.

[1263] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[1264] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1265] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1266] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1267] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1268] e. Co-SR / BF Response Padding: Indicates the padding length required for the response frame transmitted by the coordinated AP receiving the Co-SR / BF Invite frame.

[1269] - For example, an 8-bit padding field can be used for definition and padding.

[1270] - Additionally or alternatively, it can be signaled using 3 bits as follows

[1271] 0: 0 μs / 1: 32 μs / 2: 64 μs / 3: 128 μs / 4: 256 μs / 5-7: Reserved

[1272] - According to the new subtype definition utilizing the GI and HE / EHT-LTF Type / TXS Mode fields, the corresponding information can be included by utilizing fields / bits reserved in the Common Info field.

[1273] - Additionally, or alternatively, utilize the EHT Reserved (7 bits) or Reserved fields / bits of the Common Info field.

[1274] - Additionally, or alternatively, the relevant information may be included in a UHR Special User Info field (i.e., Feedback User Info field, AID >= 2008) that can be newly defined for UHR.

[1275] - Additionally, or as an alternative, you can use the Reserved field of the User Info field.

[1276] - Additionally or alternatively, the relevant information may be included in the Special User Info field (2007).

[1277] In addition to the contents presented above, some fields included in the Common field for SU (e.g., EHT, UHR, etc.) transmission and non-OFDMA transmission for existing multiple users (e.g., LDPC Extra Symbol Segment, Pre-FEC Padding Factor, PE Disambiguity, Spatial Reuse, etc.) may be included in the Common Info or Special User Info within the BSRP (UHR) Trigger frame proposed in this specification as contents for Co-SR / BF transmission, or in the (UHR) Special User Info that can be newly defined for UHR.

[1278] The AID12 field within the User Info field of the BSRP (UHR) TF proposed in this specification may be replaced with an ID related to Multi-AP cooperation. Specifically, the ID related to Multi-AP cooperation may include, for example, the BSSID, BSS color, or a newly defined Multi-AP group ID (i.e., an ID for a set of APs constituting Multi-AP cooperation) or an AP ID (i.e., an ID assigned by an AP in a cooperative relationship within the constituent Multi-AP group). Additionally or alternatively, the AID12 field may be composed of a combination of the BSSID and BSS color of the target DAP. Additionally or alternatively, the AID12 field may be composed of part or all of the BSS color of the target DAP. Additionally or alternatively, the AID12 field may be composed of part of the BSSID of the target DAP. Additionally or alternatively, the AID12 field may be composed of a combination of the AP ID and BSS color of the target DAP. Alternatively, when targeting a single DAP, the MAC address of the target DAP may be included in the RA field.

[1279] 3) Example of BSRP (UHR) TF format in a polling procedure

[1280] 3-1) Based on existing GI and HE / EHT / UHR-LTF Type / TXS Mode values

[1281] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the AP ID of the receiving AP (i.e., ID for Multi-AP cooperation) or the AP's MAC address. Therefore, an AP that receives a BSRP TF addressed to it can recognize that the corresponding BSRP TF has been delivered by acting as an ICF in MAPC operation. In this case, it is assumed that the BSRP TF can be transmitted for various purposes (e.g., DPS, NPCA, IDC, Coexistence, MAPC). Accordingly, a (UHR) Special User Info field can be defined and utilized to include an indicator of the purpose for which an ICF transmitted for one or more UHR features was sent, and to convey information necessary for Co-SR transmission to cooperating APs.

[1282] To do this, a new UHR Special User Info Field Flag (or UHR Function Control Indication) field can be defined using 1 bit of the Reserved bits of the Common Info field and its value can be set to 1. Additionally, or alternatively, a new UHR Special User Info Field Flag (or Present) field can be defined using 1 bit of the Reserved bits of Special User Info (i.e., AID12 = 2007) and its value can be set to 1.

[1283] Additionally or alternatively, the Reserved (1 bit) within the User Info field can be used to indicate whether there exists a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation (i.e., the UHR Special User Info Field Flag can be defined using the Reserved within the User Info field). This is a field defined and included for the purpose of indicating the presence of a UHR Special User Info field containing additional information. Additionally or alternatively, a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined in a user-specific manner for UHR or Multi-AP cooperation may be placed before the existing User Info field to include MAPC-related user-specific information and may include a Presence bit indicating that there is an additional User Info field (or UHR Special User Info field) addressed to the corresponding AP.

[1284] To indicate that the corresponding UHR Special User Info field is a new (UHR) Special User Info field in the UHR, the value of the AID12 field may be Reserved (e.g., one of the values ​​from 2008 to 2044 or one of the values ​​from 2047 to 4094). The UHR Special User Info field identified by the new AID12 value may be placed following the Common Info field, the User Info field, or the (EHT) Special User Info field (i.e., AID12 = 2007). Additionally, or alternatively, the UHR Special User Info field may be placed before or after the User Info field for the corresponding User.

[1285] Additionally or alternatively, the AID12 field may include a Multi-AP group ID (i.e., an ID for the set of APs that have formed a Multi-AP collaboration) or an AP ID (i.e., an ID assigned by an AP in a collaborative relationship within the formed Multi-AP group). Specifically, the local AP ID value assigned by SAP may be mapped / converted / interpreted as an AID12 value. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's BSSID and BSS color. Additionally or alternatively, the AID12 field may consist of part or all of the target DAP's BSS color. Additionally or alternatively, the AID12 field may consist of part of the target DAP's BSSID. Additionally or alternatively, the AID12 field may consist of a combination of the target DAP's AP ID and BSS color.

[1286] Figure 66 illustrates Example-1 of a BSRP TF format based on existing GI And HE / EHT / UHR-LTF Type / TXS Mode values.

[1287] Figure 67 illustrates Example-2 of a BSRP TF format based on existing GI values.

[1288] FIGS. 66 and 67 illustrate examples of BSRP TFs that reuse the existing BSRP TF format and include information related to Co-SR transmission that is not included in the Common Info and User Info fields. For example, common information for UHR features and common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-SR transmission' above may be included in one or more of the (UHR) Special User Info fields (e.g., AID12 = 2008). The locations where each piece of information may be included and the types of information are not limited. Additionally, if the presented information is not used, the corresponding fields may be reserved.

[1289] Figure 68 illustrates Example-3 of a BSRP TF format based on existing GI values.

[1290] Additionally or alternatively, FIG. 68 illustrates an example of a method in which some information (e.g., UL Length, UL BW, Number of UHR-LTF Symbols, AP Tx Power) within the Common Info field of an existing BSRP TF is reused, and information necessary for Co-SR transmission is included in the Special User Info field (2007). The PHY Version Identifier and UL Bandwidth Extension fields within the Special User Info field may be reused. In this case, to indicate the purpose for which the BSRP TF was transmitted, the Reserved (B38-B39) within the Special User Info field may be defined as the MAPC Type. The Special User Info field may include one or more pieces of information for Co-SR and common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-SR transmission' above.

[1291] Figure 69 illustrates Example-4 of a BSRP TF format based on existing GI values.

[1292] Additionally or alternatively, FIG. 69 illustrates an example of a method in which some information (e.g., UL Length, UL BW, Number of UHR-LTF Symbols, AP Tx Power) within the Common Info field of an existing BSRP TF is reused, and information necessary for Co-SR transmission is included in the Feedback User Info field (2008). The PHY Version Identifier and UL Bandwidth Extension fields within the Special User Info field may be reused. In this case, Reserved (B38-B39) within the Special User Info field may optionally be defined as the MAPC Type to indicate the purpose for which the BSRP TF was transmitted. Alternatively, the Feedback Type field within the Feedback User Info field may replace the MAPC Type. If the MAPC Type field only distinguishes the MAPC scheme (i.e., indicates Co-SR), a separate BSRP Type field may indicate the specific purpose of the BSRP TF. In the case of Co-SR, the BSRP Type is defined as 1 bit and can indicate Co-SR Invite or Co-SR Sync. The corresponding Feedback User Info field may contain one or more pieces of information for Co-SR and common information for Multi-AP cooperation described and defined in '2) Information and contents for Co-SR transmission' above. Additionally, or alternatively, a separate AID12 value for Co-SR may be defined (e.g., 2009 or 2010) to be designed to include Co-SR-related information in B12-B39.

[1293] 3-2) Based on new GI and HE / EHT / UHR-LTF Type / TXS Mode values ​​(i.e., 3)

[1294] FIG. 70 illustrates an example of a BSRP TF format based on new GI3 values: an example using Common Info and User Info.

[1295] FIG. 70 illustrates an example of a BSRP (UHR) TF format when the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field are reserved by indicating a new subtype or mode using the GI And HE / EHT / UHR-LTF Type / TXS Mode field (i.e., 3) of the Common Info field, or when the reserved range is utilized to include Common Info for Multi-AP cooperation or Info for each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). One or more pieces of information described and defined in '2) Information and contents for Co-SR transmission' above may be included in the Common Info field, User Info field, or Special User Info field of the BSRP (UHR) TF, and are not limited to the example presented in FIG. 70. That is, the position of each field and signaling bit, the number of bits, and the names may change. For example, some information not presented may be included in the Common Info field and / or User Info field and / or Special User Info field. For example, Reserved bits at other locations within the Common Info field may be used.

[1296] FIG. 71 illustrates an example of a BSRP TF format based on a new GI3 value, Example-2(a): using Common Info.

[1297] Figure 71 shows an example of a BSRP (UHR) TF format in which the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field are reserved through the indication of a new subtype or mode using GI = 3 in the Common Info field, or the reserved range is utilized to include Common Info for Multi-AP cooperation or Info for each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.). While Figure 70 utilizes the User Info field, the example in Figure 71 utilizes only the Common Info field to convey relevant information. Here, the Control Info Type may refer to the UHR Feature Type.

[1298] FIG. 72 illustrates an example of a BSRP TF format based on a new GI3 value, Example-2(b): using Common Info.

[1299] Additionally or alternatively, the example of FIG. 71, which includes information for Co-SR only in the Common Info field, can be configured as in FIG. 72. Some information within the Common and Special User Info fields (2007) may be reused. The MAPC Type field may indicate the type of MAPC scheme and the specific purpose of the BSRP TF (i.e., Invite or Sync).

[1300] FIG. 73 illustrates an example of using Special User Info in the BSRP TF format based on the new GI3 value, Example-2(c): Special User Info.

[1301] Additionally or alternatively, Co-SR related information may be included only in the Special User Info field (2007) of the BSRP TF based on the GI3 value. As shown in FIG. 73, some information within the Common and Special User Info fields (2007) may be reused, and one or more pieces of information described and defined in '2) Information and contents for Co-SR transmission' may be included in the Special User Info field (2007). The MAPC Type field may be defined using the Reserved bits of the Common Info field or the Special User Info field, and depending on the number of bits, it may simply indicate the type of the MAPC scheme or indicate the type of the MAPC scheme and the specific purpose of the BSRP TF (i.e., Invite or Sync).

[1302] FIG. 74 illustrates an example of a BSRP TF format based on a new GI3 value, Example 3(a): using a new (UHR) Special User Info field.

[1303] FIG. 74 shows an example of the BSRP (UHR) TF format in which the remaining fields following the GI And HE / EHT-LTF Type / TXS Mode field are reserved through the indication of a new subtype or mode using GI = 3 in the Common Info field, and Common Info for Multi-AP cooperation or Info for each Multi-AP cooperation scheme (e.g., Co-SR, Co-BF, Co-TDMA, etc.) is included in the (UHR) Special User Info field (e.g., AID12 = 2008) that can be newly defined in UHR. In FIG. 74, fields that are not used in the Common Info field and User Info field are reserved, and relevant information is transmitted using only the (UHR) Special User Info field. To this end, 1 bit of the Reserved bits in the Common Info field can be used to newly define the UHR Special User Info Field Flag (or Present) field and set its value to 1. Additionally or alternatively, one bit of the Reserved bits of Special User Info (i.e., AID12 = 2007) can be used to define a new UHR Special User Info Field Flag (or Present) field and set its value to 1.

[1304] Additionally or alternatively, the Reserved (1 bit) within the User Info field can be used to indicate the existence of a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined user-specifically for UHR or Multi-AP cooperation (i.e., the UHR Special User Info Field Flag can be defined using the Reserved within the User Info field). This is a field defined and included for the purpose of indicating the presence of a UHR Special User Info field containing additional information. Additionally or alternatively, a UHR Special User Info field (i.e., AID12 = 2008) that can be newly defined user-specifically for UHR or Multi-AP cooperation may be placed before the existing User Info field to contain MAPC-related user-specific information, and may include a Presence bit indicating the existence of an additional User Info field (or UHR Special User Info field) addressed to the corresponding AP. Here, Control Info Type may refer to the UHR Feature Type.

[1305] FIG. 75 illustrates an example of using Feedback User Info in the BSRP TF format based on the new GI3 value, Example-3(b): Feedback User Info.

[1306] Additionally or alternatively, FIG. 74 may have a structure like FIG. 75 based on the Feedback User Info field (2008). Some information within the Common and Special User Info fields (2007) may be reused, and one or more pieces of information described and defined in '2) Information and contents for Co-SR transmission' may be included in the Feedback User Info field (2008). The MAPC Type field within the Special User Info field (2007) may indicate the type of MAPC scheme. Additionally or alternatively, if the Feedback Type indicates Co-SR, it may replace the MAPC Type field. If the Feedback Type simply indicates the MAPC scheme, a separate BSRP Type field may exist, and that field may indicate the purpose (e.g., Co-SR Invite / Sync) for which the BSRP TF was transmitted. Additionally or alternatively, the Feedback Type field can specify the MAPC scheme and the specific TF type together (e.g., Co-SR Invite or Co-SR Sync).

[1307] FIG. 76 illustrates an example of a BSRP TF format containing one or more User Info fields (AID12 = AP ID): using a Co-SR Info Type.

[1308] Figure 77 illustrates an example of a BSRP (UHR) Trigger frame that serves as an ICF in the Polling procedure.

[1309] That is, an example of the BSRP (UHR) Trigger frame format for Co-SR transmission proposed in this specification may be as shown in FIG. 77, but is not limited thereto. For example, Ex 1) in FIG. 77 represents a case where the (UHR) Special User Info field is placed after the User Info field in an example of a BSRP TF based on the existing GI And HE / EHT / UHR-LTF Type / TXS Mode value. One or more User Info field(s) may exist depending on the number of non-AP STAs addressed in the BSRP TF and / or the number of DAPs to perform Co-SR transmission. Additionally or alternatively, Ex 2) represents an example of a BSRP (UHR) TF based on the new GI And HE / EHT / UHR-LTF Type / TXS Mode value (i.e., 3). In this case, since the BSRP TF is transmitted to a SU, a User Info field targeting only a single AP may exist. Additionally or alternatively, Ex 3) shows an example where a (UHR or New) Special User Info field (e.g., AID12 = 2008) is placed following a Special User Info field (ie, AID12 = 2007). Within the (UHR) Special User Info field (e.g., AID12 = 2008), a Present bit may be defined to indicate the existence of a User Info field containing MAPC-related AP / user-specific information.

[1310] Additionally or alternatively, a method for including Co-SR information when it is necessary to transmit an amount of Co-SR information exceeding the length (i.e., 24 bits) of the Control Info field (or Feedback Information field) presented in FIG. 74 may be considered. To this end, one or more User Info fields may exist in which the AID12 field is set as the AP ID of the target AP, without using the reserved fields of Common Info and Special User Info (2007). In this case, a Present bit (e.g., More User Info field) indicating the existence of additional User Info fields may be defined and included in the preceding User Info field. If the Present bit is set to 1, it may mean that additional User Info fields (AID12 = AP ID) exist. Depending on the value of the Present bit, the format of the User Info field may vary (i.e., may contain different information). As an alternative to the Present bit, a Co-SR Info Type field may be included to indicate the existence of one or more User Info fields and to distinguish them. An example of this is shown in FIG. 76.

[1311] 3-3) Using Padding

[1312] FIG. 78 illustrates an example of a BSRP (UHR) TF format containing information related to Co-SR transmission within the padding.

[1313] Additionally or alternatively, information for UHR features described and defined in '2) Information and contents for Co-SR transmission' above, common information for Multi-AP cooperation, and key / partial information required for Co-SR transmission may be included in the padding. That is, the information presented above may be included in the padding within the BSRP (UHR) TF as shown in FIG. 78.

[1314] 4) Example of BSRP (UHR) TF format in a triggering procedure

[1315] 4-1) Based on existing GI and HE / EHT / UHR-LTF Type / TXS Mode values

[1316] Basically, the AID12 field or RA field within the User Info field of a BSRP TF transmitted between APs may contain the AP ID of the receiving AP (i.e., ID for Multi-AP cooperation) or the MAC address of the AP. Therefore, an AP that receives a BSRP TF addressed to it can recognize that the corresponding BSRP TF has been delivered as an ICF...

Claims

1. In a wireless LAN system, A step in which the first AP (access point) transmits a cooperation invitation frame to the second AP; The first AP receives a cooperation response frame from the second AP; and The above first AP includes the step of transmitting a cooperation trigger frame to the above second AP, wherein The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 method.

2. In Paragraph 1, The above feedback user information field includes the above first AID12 field, control type field, and control information field, and The above control information field includes at least one of information regarding the MAPC type, information regarding the PHY version identifier, information regarding the bandwidth, information regarding the punctured channel, information regarding the GI+LTF size, information regarding the minimum number of data OFDMA (Orthogonal Frequency Division Multiple Access) symbols, information regarding the maximum number of data OFDMA symbols, information regarding the maximum number of spatial streams allowed in the cooperative AP, information regarding the number of Co-BF (Coordinated beamforming) users in the BSS (Basic Service Set) of the cooperative AP, and information regarding the existence of the user information field. The above user information field includes a second AID12 field, information about the STA (station) ID (Identifier), and information about the number of space streams, and The value of the above second AID12 field is set as the ID of the above second AP. method.

3. In Paragraph 2, Information regarding the above MAPC type is related to information regarding the type of the above MAPC transmission and the role of the trigger frame for the above MAPC transmission, and Information regarding the minimum number of data OFDMA symbols is related to information regarding the minimum number of data OFDMA symbols that the cooperative AP can transmit, and Information regarding the maximum number of data OFDMA symbols is related to information regarding the maximum number of data OFDMA symbols that the cooperative AP can transmit, and Information regarding the maximum number of space streams allowed in the aforementioned cooperative AP is related to information regarding the maximum number of space streams allowed in the aforementioned cooperative AP for the cooperative AP to control the aforementioned cooperative AP, and Information regarding the number of Co-BF users in the BSS of the above-mentioned cooperative AP is related to information regarding the number of users who are the transmission targets in the BSS of the above-mentioned cooperative AP. method.

4. In Paragraph 1, The above user information field includes at least one of a second AID12 field, information on the feedback type, information on the BSRP (Buffer Status Report Poll) type, information on more user information, information on the minimum number of data OFDMA symbols, information on the maximum number of data OFDMA symbols, information on the number of Co-BF users in the BSS of the cooperative AP, information on whether the exchange of ICF (Initial Control Frame) and ICR (Initial Control Response) frames is required, information on the maximum number of spatial streams allowed in the cooperative AP, information on punctured channels, and information on the GI+LTF size. The value of the above second AID12 field is set to the ID of the above second AP, and The trigger frame for the above MAPC transmission further includes a special user information field, and The above special user information field further includes information regarding the third AID12 field and MAPC type, and The value of the above 3rd AID12 field is set to 2007 method.

5. In Paragraph 4, Information regarding the above feedback type is related to information regarding the type of the above MAPC transmission and the role of the trigger frame for the above MAPC transmission, and Information regarding the above BSRP type is related to control information for the trigger frame for the above MAPC transmission, and Information regarding whether the exchange of the above ICF and ICR frames is required is related to the information regarding whether the exchange of the above ICF and ICR frames is required to the associated non-AP STA before triggering Co-BF transmission. method.

6. In Paragraph 4, The above user information field further includes user information specific to Co-BF users, and The above Co-BF user-specific user information includes the fourth AID12 field, information on the feedback type, information on the STA ID, and information on the number of spatial streams, and The value of the above 4th AID12 field is set to 2008, 2009, or the ID of the above 2nd AP method.

7. In Paragraph 6, The above feedback user information field, the above user information field, or the above special user information field includes at least one of information on Co-BF information types, information on traffic priority, and information on Multi-AP Ack policies, and Information regarding the above Co-BF information type is related to information regarding whether information for Co-BF operation is included in the above common information field or the above Co-BF user-specific user information, and The information regarding the above traffic priority relates to the information regarding the priority of traffic that the above-mentioned cooperating AP recommends or allows to the above-mentioned cooperating AP, and The information regarding the above Multi-AP Ack policy relates to the information regarding the Ack policy for the cooperative AP and the non-AP STA connected to the cooperative AP during the transmission interval of Co-BF. method.

8. In Paragraph 1, The step of the first AP transmitting a negotiation request frame to the second AP; The first AP receives a negotiation response frame from the second AP; and The above first AP further includes the step of forming a MAPC agreement with the above second AP regarding Co-SR or Co-BF, wherein The above-mentioned first AP is a MAPC requesting AP that initiates negotiations for the above-mentioned MAPC agreement, and The above second AP is a MAPC responding AP that responds to the above MAPC request AP. method.

9. In Paragraph 8, Based on the MAPC consensus formed regarding the above Co-BF, The step of the first AP transmitting a first PPDU to a first non-AP STA (station) after the cooperation trigger frame is transmitted; and The above second AP further includes the step of transmitting a second PPDU to a second non-AP STA after the cooperation trigger frame is received, The first and second PPDUs are each transmitted concurrently through multiple transmit chains, and The above first non-AP STA is a non-AP STA associated with the above first AP, and The above second non-AP STA is a non-AP STA connected to the above second AP. method.

10. In a wireless LAN system, the first AP (access point) is, Memory; transceiver; and The processor comprises the memory and the transceiver, operably coupled thereto, wherein the processor comprises: Send a cooperation invitation frame to the 2nd AP; Receive a cooperation response frame from the above-mentioned second AP; and Transmit a cooperation trigger frame to the above-mentioned second AP, The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 1st AP.

11. In wireless LAN systems, A step in which the second AP (access point) receives a cooperation invitation frame from the first AP; The step of the second AP transmitting a cooperation response frame to the first AP; and The above second AP includes the step of receiving a cooperation trigger frame from the first AP, wherein The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 method.

12. In Paragraph 11, The above feedback user information field includes the above first AID12 field, control type field, and control information field, and The above control information field includes at least one of information regarding the MAPC type, information regarding the PHY version identifier, information regarding the bandwidth, information regarding the punctured channel, information regarding the GI+LTF size, information regarding the minimum number of data OFDMA (Orthogonal Frequency Division Multiple Access) symbols, information regarding the maximum number of data OFDMA symbols, information regarding the maximum number of spatial streams allowed in the cooperative AP, information regarding the number of Co-BF (Coordinated beamforming) users in the BSS (Basic Service Set) of the cooperative AP, and information regarding the existence of the user information field. The above user information field includes a second AID12 field, information about the STA (station) ID (Identifier), and information about the number of space streams, and The value of the above second AID12 field is set as the ID of the above second AP. method.

13. In Paragraph 12, Information regarding the above MAPC type is related to information regarding the type of the above MAPC transmission and the role of the trigger frame for the above MAPC transmission, and Information regarding the minimum number of data OFDMA symbols is related to information regarding the minimum number of data OFDMA symbols that the cooperative AP can transmit, and Information regarding the maximum number of data OFDMA symbols is related to information regarding the maximum number of data OFDMA symbols that the cooperative AP can transmit, and Information regarding the maximum number of space streams allowed in the aforementioned cooperative AP is related to information regarding the maximum number of space streams allowed in the aforementioned cooperative AP for the cooperative AP to control the aforementioned cooperative AP, and Information regarding the number of Co-BF users in the BSS of the above-mentioned cooperative AP is related to information regarding the number of users who are the transmission targets in the BSS of the above-mentioned cooperative AP. method.

14. In Paragraph 11, The above user information field includes at least one of a second AID12 field, information on the feedback type, information on the BSRP (Buffer Status Report Poll) type, information on more user information, information on the minimum number of data OFDMA symbols, information on the maximum number of data OFDMA symbols, information on the number of Co-BF users in the BSS of the cooperative AP, information on whether the exchange of ICF (Initial Control Frame) and ICR (Initial Control Response) frames is required, information on the maximum number of spatial streams allowed in the cooperative AP, information on punctured channels, and information on the GI+LTF size. The value of the above second AID12 field is set to the ID of the above second AP, and The trigger frame for the above MAPC transmission further includes a special user information field, and The above special user information field further includes information regarding the third AID12 field and MAPC type, and The value of the above 3rd AID12 field is set to 2007 method.

15. In Paragraph 14, Information regarding the above feedback type is related to information regarding the type of the above MAPC transmission and the role of the trigger frame for the above MAPC transmission, and Information regarding the above BSRP type is related to control information for the trigger frame for the above MAPC transmission, and Information regarding whether the exchange of the above ICF and ICR frames is required is related to the information regarding whether the exchange of the above ICF and ICR frames is required to the associated non-AP STA before triggering Co-BF transmission. method.

16. In Paragraph 14, The above user information field further includes user information specific to Co-BF users, and The above Co-BF user-specific user information includes the fourth AID12 field, information on the feedback type, information on the STA ID, and information on the number of spatial streams, and The value of the above 4th AID12 field is set to 2008, 2009, or the ID of the above 2nd AP method.

17. In Paragraph 16, The above feedback user information field, the above user information field, or the above special user information field includes at least one of information on Co-BF information types, information on traffic priority, and information on Multi-AP Ack policies, and Information regarding the above Co-BF information type is related to information regarding whether information for Co-BF operation is included in the above common information field or the above Co-BF user-specific user information, and The information regarding the above traffic priority relates to the information regarding the priority of traffic that the above-mentioned cooperating AP recommends or allows to the above-mentioned cooperating AP, and The information regarding the above Multi-AP Ack policy relates to the information regarding the Ack policy for the cooperative AP and the non-AP STA connected to the cooperative AP during the transmission interval of Co-BF. method.

18. In a wireless LAN system, the second AP (access point) is, Memory; transceiver; and The processor comprises the memory and the transceiver, operably coupled thereto, wherein the processor comprises: Receive a cooperation invitation frame from the 1st AP; Transmitting a cooperation response frame to the above-mentioned first AP; and Receive a cooperation trigger frame from the above-mentioned first AP, The first AP above is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 2nd AP.

19. At least one computer-readable medium comprising an instruction based on execution by at least one processor, A step of transmitting a cooperation invitation frame to the second AP (access point); The step of receiving a cooperation response frame from the second AP; and The method includes the step of transmitting a cooperation trigger frame to the second AP, The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 Recording media.

20. In a device in a wireless LAN system, Memory; and The processor comprises the above memory and operablely coupled thereto, wherein the processor is: Send a cooperation invitation frame to the second AP (access point); Receive a cooperation response frame from the above-mentioned second AP; and Transmit a cooperation trigger frame to the above-mentioned second AP, The first AP is a coordinating AP that acquires a TXOP (transmission opportunity) and initiates MAPC (Multi-AP Coordination) transmission with the second AP, and The above second AP is a coordinated AP participating in the above MAPC transmission, and The above cooperation invitation frame is defined as a trigger frame for the above MAPC transmission, and The trigger frame for the above MAPC transmission includes a common information field, a feedback user field, and a user information field, and The value of the GI (Guard Interval) And UHR (Ultra-High Reliability)-LTF (Long Training Field) type field of the above common information field is set to 3, and The value of the first AID12 field of the above feedback user information field is set to 2008 device.

Images